Support rules are boring until the first difficult message arrives. For a solo digital product, boring is the goal. The customer needs to know what help is available. The operator needs a boundary that still feels fair when there are invoices, travel days, client work, and product maintenance waiting in the same week.
Two references help keep the boundary honest. The EU explains baseline consumer guarantee rights, and Stripe documents how payment disputes work on its platform. Those pages do not write your support policy, but they are a useful reminder that refunds, disputes, and legal rights are not the same thing as ordinary product help.
Start With What The Product Actually Promises
A useful support rule begins with the product promise. If the product is a template, support might cover download access, missing files, obvious errors, and setup notes already included in the documentation. It probably does not cover custom strategy, third-party tool configuration, or rebuilding a customer project.
For example, a customer who cannot download a purchased file needs fast help. A customer who wants the template adapted to a special business model may need a paid service, a documented limitation, or a polite no. Both messages deserve respect, but they do not belong in the same support lane.
Write The Reply Window You Can Keep
A one-person business should not promise the reply speed of a staffed help desk. A clear window such as “I usually reply within two business days” is better than pretending to be constantly available. The rule should also say what happens during travel, weekends, launches, or planned breaks.
The private operating note can be even simpler: access issues first, payment receipt issues second, product bugs third, custom advice last. That order keeps urgent friction from hiding behind interesting but less urgent requests.
Separate Support From Policy Decisions
Support answers product questions. Policy handles refunds, misuse, account sharing, chargebacks, and exceptions. Mixing them creates messy inbox conversations because every reply becomes a negotiation. Write the policy once, then let support point to it calmly.
Sample reply: “I can help with access to the files and any broken links in the product. Custom implementation is outside the included support, but here is the relevant setup note. If you are asking about a refund, the policy is here and I will handle that separately.” The wording is plain, not defensive.
Keep A Small Support Log
Support rules improve when the pattern is visible. Pair this with a content maintenance day and the broader solo site operating model. If three customers ask the same thing, the product probably needs better documentation, clearer sales copy, or a small fix.
The final rule is capacity. A support promise that requires heroic energy will fail at the worst time. A support rule that names what is covered, how quickly replies happen, and where policy decisions live can feel modest, but modest rules are the ones a solo operator can keep.
Solo product support rule note
The copyable version can be blunt in the private note and warmer on the public page. Private note: access problems first, broken product files second, unclear instructions third, custom work outside support. Public note: I help with access, files, and product errors; custom setup and business-specific advice are separate from included support.
Review the rule after every awkward message. If the same confusion returns, the support rule is not the only thing to fix. The sales page, onboarding email, documentation, or product structure may be creating the inbox problem. Good support rules protect time, but they also point back to product improvements.