Check the promise before declining the request
When a buyer asks for help beyond your product's scope, first check whether the request reveals a broken promise, unclear instructions, or a genuinely new job. Fix problems with what you sold. For additional work, explain the boundary and offer a useful next step without implying that the buyer must purchase consulting to make the original product usable.
A low price is not a reason to dismiss a reader. The relevant question is what you promised. A paid companion can offer a complete, bounded application of your book's method while excluding personal review, bespoke adaptation, and implementation.
Read the request against the promise
Suppose fictional author Hana sells a companion to her book on organizing a small archive. The product helps a reader prepare a basic inventory and choose consistent descriptive fields. It includes guidance for using the workflow, but no personal inspection of collections or custom database design.
A buyer asks, “Could you set this up for our whole organization?” That sounds like additional work. But before declining, Hana checks the offer. If her sales page implied a complete organizational setup, she has an expectation problem to resolve, not a boundary to enforce retroactively.
Use this routing table with the actual description the buyer saw. These are invented requests, not customer records.
| Request | Initial classification | Fair next step |
|---|---|---|
| The promised example cannot be opened | Possible defect or access problem | Investigate and help restore the promised material |
| I do not understand what belongs in this field | Guidance on using the product | Explain the step and improve unclear instructions |
| Please choose the final categories for our collection | Individual judgment | Explain the self-service limit and available alternatives |
| Please rebuild this for our existing database | Custom adaptation | Decline or discuss a separately scoped service |
| Could you add an example for this unusual material? | Improvement suggestion | Record the need without promising delivery |
Some requests contain more than one issue. You can resolve a broken example and decline database implementation in the same conversation. Do not label everything in a long email “out of scope” because one part is additional work.
Avoid creating a promise by accident
An author may say yes to a small favor because refusing feels unfriendly. The reader may reasonably interpret that help as part of the purchase, especially if the distinction was never explained.
In a public customer-success discussion, a platform employee described “creating an expectation with them that we will custom fit the entire platform to their needs”. Their situation involved a large software customer, not a book companion. The relevant lesson is about expectations: repeated exceptions can make the actual offer difficult to understand. Original post by u/Silly-CSM-9677.
If you choose to make an exception, name it and limit it. Do not imply that every later request receives the same treatment. Also consider whether the exception exposes a missing piece that should be available to all buyers.
Five replies you can adapt
These are original sample responses for Hana's fictional product. They are communication examples, not contract terms or messages sent to anyone.
1. A defect in the promised experience
Thanks for flagging the missing example. That example is included in your purchase, so I will investigate the problem. Please send the name of the step and the error you see, without including private collection records. I will confirm the next step once I have checked it.
This reply accepts responsibility for the promised material. It does not make an unsupported repair-time promise or ask the buyer to upgrade for a fix.
2. Help with a confusing instruction
The “source” field is intended to record where the item came from, using the information you already have. The worked example shows the level of detail. I can clarify how that step works; choosing or verifying the facts for your collection remains with you. Your question also shows me where the instruction could be clearer.
Adapt the explanation to your own method. A useful answer addresses the immediate confusion rather than merely repeating the support policy.
3. Personal review that is not included
I understand you want reassurance before adopting these categories. The companion helps you prepare a draft, but it does not include my personal review or approval. You can use the review questions in the final step to inspect your choices. If you need a person to assess the collection, you will need a separate review arrangement.
Only mention a paid review by you if you actually offer it and have capacity. A clear no can be more useful than an invitation to a service that does not exist.
4. A custom implementation request
Setting this up in your organization's database is a separate implementation project. It is not included in the companion, and I cannot take that work on. The inventory brief can help you explain your requirements to whoever manages that system. I can still help if a step in the purchased workflow is not functioning as described.
This response preserves the original support commitment. It also gives the buyer something useful to take forward without promising that another provider will accept the work.
5. A suggestion for a future version
Thank you for explaining the material you are working with. I have recorded the request for another example, but I am not committing to adding it or to a release date. For now, the product covers the examples shown in the current description. Please tell me if those examples fail to support something the offer said you could do.
Recording a request is different from accepting it. The last sentence also leaves room to discover that the problem is a gap in the existing promise.
Agree on extra work before doing it
If you do offer a separate service, specify its output, price, timing, and limits before starting. Let the buyer decide. Do not surprise them with an invoice for help they reasonably understood as included.
A freelance designer explained the benefit from the client's side: “By telling them beforehand their options and the price tag, they get to decide before they owe you for it.” This is a practitioner's perspective on scope discussions, not a legal rule. Original comment by u/Original-Fondant-328.
If the same request returns repeatedly, revisit the offer description and the product itself. You may need clearer guidance, a narrower promise, or a genuinely separate service. Better wording cannot compensate for a product that fails to deliver its stated outcome; use skill testing to examine that separately.
To explore a paid application of your book with a clear boundary around personal work, visit Skillfully and choose Book onboarding. Bring the reader task and the requests you want the product to handle. A useful scope begins with what buyers can complete, not just what you intend to decline.