Start with the outcome the core service must deliver
A core service is the smallest complete offer that solves the problem you promise to solve. It should not be a stripped-down package that leaves the client unable to use the result. For example, if you offer a website content review, the core might include a review of an agreed number of pages, a prioritized list of issues, and a meeting to explain the recommendations. Rewriting every page could be optional, but telling the client what needs attention is part of the promised review.
Write the core service as a sequence: what you need from the client, what work you will do, and what the client receives. Name the deliverables in terms a client can recognize, such as a draft, a report, or a configured tool. Then state the limits that make the work manageable: the number of items covered, the number of feedback rounds, and the point at which the service is complete. These details define the offer more clearly than a long list of activities.
Use a simple test for potential add-ons
An add-on is work a client may value but does not need in order to receive the core outcome. Ask whether the service still fulfills its promise without the extra item. If removing it makes the core result unusable, it belongs in the core. If it adds depth, speed, convenience, or continued support, it may be a good add-on.
Common add-on types include extra volume, a different format, implementation help, or support after handover. A designer might include one finished presentation template in the core service and offer additional slide layouts as an add-on. A project consultant might include a workflow plan and offer team training separately. These distinctions work best when the extra work can be described and estimated without redefining the entire project.
Avoid turning every task into an add-on. If clients repeatedly need the same extra item to get a useful result, reconsider the core offer. Likewise, an option that only makes sense for one unusual client may be better handled as a custom request rather than a permanent menu item.
Describe the boundary in concrete terms
Clients should not have to infer what phrases such as “basic support” or “full setup” mean. For each service, describe the included work, the deliverable, and any important exclusions. You might say, “Includes a draft of up to five onboarding emails and one consolidated revision round; uploading the emails to your platform is available as an add-on.” This gives the client a clear choice without implying that the core draft is incomplete.
Pay particular attention to work that often hides between steps. Who gathers source material? Who approves the draft? Does implementation include testing? What happens if the client changes direction after approval? State the answer where it affects scope. You do not need a rule for every possible situation, but the most likely points of confusion should be visible before work begins.
Keep the language neutral. An exclusion is not a warning about what you refuse to do; it is a way to identify work that requires a separate decision. A short comparison of the core service and each add-on can make that decision easier than a dense description of everything you could provide.
Make each add-on easy to choose and deliver
A useful add-on has a clear trigger, output, and place in the project. “Additional review of up to three pages” is easier to evaluate than “more strategic input.” If an add-on depends on the core work being finished first, say so. If it must be selected before work starts, explain that timing too. This helps you plan capacity and helps the client understand when a choice is needed.
Present the price or method for estimating an add-on separately from the core service. The aim is not to push clients toward the largest package; it is to let them see the effect of each choice on the work, schedule, and cost. Where the amount of work cannot be known in advance, describe what you will review before providing an estimate. Avoid offering an open-ended extra under a fixed label unless its limits are clear.
During a project, a new request can be checked against the agreed core and add-ons. If it falls outside both, explain the additional work and ask for approval before starting it. A calm scope conversation is easier when the original offer already shows how optional work is handled.
Review the offer after real projects
Your first boundary will not be perfect. After each project, note which tasks took unexpected effort, which options clients understood, and which questions came up repeatedly. Look for patterns rather than changing the offer after a single unusual request. If an add-on is selected almost every time because it is necessary to complete the promised outcome, it may belong in the core. If clients rarely need it but appreciate having the choice, it may be well placed as an option.
The goal is a service that is complete on its own and flexible where flexibility genuinely helps. A defined core gives clients a dependable starting point. Well-scoped add-ons let them adapt that starting point without making the responsibilities on either side unclear.
