Tiny Shop Customer Promise Map — 22 Service Rules for Solo Digital Sellers
A concise operating guide for turning vague digital-product support promises into clear rules buyers and sellers can understand.
1. The Promise Map in 20 minutes
A tiny shop does not need a corporate service manual. It needs a visible promise map: what you sell, what happens after purchase, what you will fix, what you will not promise, and when a human steps in. The map reduces refunds because customers see clear limits before they feel confused. It also reduces owner panic because every awkward support moment has a default answer.
2. The six promise zones
Use six zones: product fit, delivery, setup, support, updates, and refunds. Product fit says who the download is for and not for. Delivery says where files arrive and what format they use. Setup says what software is needed. Support says what you answer. Updates say whether buyers receive future changes. Refunds say the rule before emotion takes over.
3. Rule 01: Name the buyer situation
Write one sentence beginning: This is for a buyer who already has __ and wants __ without __. If you cannot finish it, the listing is not ready. Example: This is for a solo digital seller who already has products and wants calmer customer replies without writing policies from scratch.
4. Rule 02: State the non-fit kindly
A good promise includes a respectful no. Use: This is not designed for buyers who need __. That line protects the customer from disappointment and protects you from support that should never have been sold.
5. Rule 03: Make delivery boring
List file types, approximate file size, whether the download is a ZIP, and whether it opens offline. Boring delivery language creates trust. Fancy delivery language creates mystery, and mystery creates emails.
6. Rule 04: One first-open instruction
Every product needs one obvious first action. Not five. Put it in the listing, buyer README, and first screen of the product. Example: Open START-HERE.html first, then choose the checklist for your shop size.
7. Rule 05: The 24-hour support window
Choose a support window you can keep on a bad week. A calm default is: I usually reply within 1–2 business days. Do not promise instant help unless you have a staffed desk.
8. Rule 06: Define file-access support
Digital sellers should support access problems: broken downloads, missing files, corrupt ZIPs, unclear first-open steps. These are reasonable promises and easy to verify.
9. Rule 07: Exclude custom implementation
If you do not sell consulting, say so. Example: This download includes templates and instructions, but it does not include custom setup, account configuration, legal review, or one-to-one coaching.
10. Rule 08: Screenshots are previews, not guarantees
Screenshots show the product experience. They should not imply revenue, ranking, platform approval, dating success, medical outcomes, or legal certainty. Keep claims about the file, not the buyer’s future.
11. Rule 09: Version your products
Put a visible version in the README and listing package. Versioning makes updates less chaotic and gives support a reference point: Please check that your copy says v1.0 in the footer.
12. Rule 10: Create a refund lane before anger
Use a simple lane: file-access issue, duplicate purchase, mistaken expectation, buyer changed mind, product defect. Decide your response for each before the first complaint arrives.
13. Rule 11: The duplicate purchase rule
A generous default is to refund accidental duplicate purchases when the platform/payment setup allows it. If payments are not enabled, record the intended rule in the listing pack for later activation.
14. Rule 12: The defect rule
If the download is materially broken, fix it or replace it. A promise map is not a shield against genuine defects; it is a way to handle them fast and fairly.
15. Rule 13: The expectation mismatch rule
When a buyer expected something not promised, reply with empathy, point to the listing language, and offer the closest helpful pointer. Then improve the listing if their confusion was reasonable.
16. Rule 14: The update promise
Choose one of three update promises: no planned updates, minor fixes included, or major updates may be sold separately. Avoid vague lifetime promises. They sound generous and become a liability.
17. Rule 15: Keep AI claims modest
If AI helped create a template, the customer still buys the finished product, not magic. Say what the buyer receives. Do not claim the product replaces professional judgement or platform compliance review.
18. Rule 16: Add a calm escalation line
For tricky support, use: I want to handle this fairly. I’m checking the original listing, download files, and your specific issue before I answer properly. That sentence buys time without sounding evasive.
19. Rule 17: Use the same nouns everywhere
If the listing says workbook, the ZIP should not say guide and the README should not say toolkit. Consistent nouns reduce buyer confusion. Pick one product noun and use it across every asset.
20. Rule 18: Put boundaries near benefits
Do not hide boundaries in tiny policy text. Put the key boundary beside the benefit. Example: Includes editable reply scripts; does not include custom legal or platform-policy advice.
21. Rule 19: The five-minute audit
Before publishing, ask: Can the buyer identify the fit, files, first step, support scope, and refund lane in five minutes? If not, the promise map is not clear enough.
22. Rule 20: Save a support snippet bank
For every product, keep at least five snippets: download help, opening ZIPs, what is included, what is not included, and refund boundary. Support snippets turn future stress into copy-paste calm.
23. Rule 21: Review after three signals
Update the promise map after three real signals: repeated buyer question, repeated support issue, or repeated non-fit visitor. Do not rewrite everything after one unusual message.
24. Rule 22: Make the promise easy to keep
The best customer promise is not the most generous one. It is the one a solo seller can keep consistently while still treating buyers with respect. Under-promise on response speed; over-deliver on clarity.
25. Copy-ready promise map template
Use this template: For: __. Not for: __. Includes: __. Does not include: __. Opens with: __. Support covers: __. Support does not cover: __. Reply window: __. Updates: __. Refund lane: __. Version: __.
26. Final checklist
Before publishing: product title matches files; gallery shows file type; README has first-open instruction; listing states file types; support/refund note is included; disclaimer avoids guaranteed outcomes; outer ZIP contains only buyer and listing ZIPs.
For: __ · Not for: __ · Includes: __ · Does not include: __ · Opens with: __ · Support covers: __ · Reply window: __ · Updates: __ · Refund lane: __ · Version: __.