Present an add-on as optional only when the core service remains useful without it. Explain the extra work, required inputs and effects on timing or handover. Identify genuine prerequisites separately, and discuss dependent requests before a client commits to an option that cannot stand on its own.
Distinguish optional work from a prerequisite
Draw the core service as a short sequence from inputs to handover. Identify what must happen for that sequence to work. If an activity is essential to delivering the advertised result, it is a prerequisite or part of the core scope, not a surprise optional extra. An implementation workshop might be optional after a review report, while access to the source documents is necessary to perform the review. Naming the distinction prevents an incomplete offer from appearing cheaper or simpler.
Ask what the client can reasonably do if they decline the add-on. They should still receive the promised core artifact in a usable state. If the report cannot be interpreted without buying a separate explanation session, reconsider whether the handover is adequate. Optional work can extend value, provide convenience or address a different task. It should not quietly contain information or access needed to understand the item the client already agreed to receive.
Describe dependencies and additional responsibilities
For each option, state what it adds and what it depends on. A training session may require an agreed guide, available participants and a suitable meeting platform. A second-language version may require translation expertise and review by someone qualified to check meaning. Explain which inputs the client supplies and which you arrange. Do not imply that an option is always available simply because it appears beside the service; availability may depend on scope and relevant collaborators.
Explain how the option changes the engagement. It may add a review stage, create different licensing needs or move the completion date. If the client can choose it later, identify the decision point before which it can fit the existing schedule. Keep the added deliverable distinct from the core artifact so a future handover can show what was actually commissioned. Ambiguous bundles become difficult to maintain when different clients select different combinations.
Help someone choose without pressure
Use a suitability statement based on the task the option supports. An editable template may help a team that maintains similar documents regularly; it may add little for a one-time review. Describe that difference without presenting the larger package as automatically superior. If you display a comparison, use consistent categories for inclusions and dependencies. The reader should be able to see why they might reasonably decline an option rather than feeling that the core service is deliberately inadequate.
Reconfirm optional work in the proposal and whenever the scope changes. A request mentioned casually in a meeting should not become an assumed purchase or an unpaid commitment. Record the decision, relevant inputs and effect on delivery before starting it. Review the public description when an option repeatedly becomes necessary; the core service may need to change. Accurate packaging follows the work as it exists rather than preserving a tidy sales structure that no longer matches delivery.
Fictional example: a maintenance workshop after a review
A fictional content specialist, Felix, offers a review report with an explanatory handover discussion. He also offers an optional maintenance workshop for teams that will continue updating the material. The workshop requires nominated editors, access to the agreed document structure and a separate agenda. Declining it does not remove the explanation needed to understand the review report.
In an invented enquiry, the client asks to add a workshop after inviting a large new stakeholder group. Felix checks whether the purpose and participant needs still match the option before confirming scope and timing. The fictional example shows the difference between an optional extension and a hidden dependency; it does not imply that every team needs training or that the workshop guarantees better maintenance.
A checklist for your next step
- Map the core handover.
- Identify genuine prerequisites.
- Explain each option’s extra artifact.
- State effects on timing and inputs.
- Record selection before starting work.
Common questions
Can an add-on require another service first?
Yes, when the dependency is explicit. Explain why it is needed and whether the client can meet it another way.
Should every client buy the full bundle?
No. Describe suitability by task and constraints so someone can choose a smaller scope when it meets their needs.
Further reading
These primary resources provide related background. They do not validate the illustrative example or endorse AliveProfile.
AI-assisted drafting and automated technical checks. Examples are illustrative; no independent expert review or real-world outcome validation is claimed. Read our editorial policy.