Explain suitability by the client’s situation, readiness and ability to use the handover. State required inputs and responsibilities, and describe cases where another route may be more appropriate. Avoid broad personality labels or guarantees; help readers recognize whether the service matches the task they need to complete.
Describe a situation rather than an ideal personality
Begin with the practical condition the service addresses. A documentation review might suit a team with an existing guide that wants to identify contradictions before editing. This tells a reader more than calling the offer suitable for ambitious innovators. Personality labels are difficult to assess and rarely explain the work. Describe the artifact, decision or obstacle involved, then identify the people who need to participate for the engagement to be useful.
Include context only when it affects delivery. Organization size may matter if a service assumes one decision owner and a limited review group. Industry may matter when specialist knowledge or approval is necessary. Do not use these categories as substitutes for explaining the actual dependency. A small organization can still have complex approval needs, while a large one can commission a tightly bounded project. Conditions help the reader evaluate their own situation instead of guessing from a broad label.
Explain readiness and client responsibilities
List what must already exist and what the client must be able to provide. This might be approved source material, access to a relevant colleague or internal capacity to implement recommendations. Distinguish a helpful preparation from a necessary prerequisite. If a missing input can be developed through separate work, explain that possibility without suggesting it is automatically included. A reader should understand whether the next step is an enquiry, internal preparation or a different service.
Describe how the handover will be used. A recommendation report suits a team that can make decisions and assign follow-up work; it may be insufficient for someone seeking outsourced implementation. A template may need ongoing ownership. A facilitated discussion may require participants willing and authorized to resolve questions. These are practical responsibilities, not tests of whether a client is worthy of your service. Write them respectfully and avoid framing normal constraints as a lack of ambition or commitment.
Make unsuitable situations useful to recognize
Name a few adjacent situations where the service would be incomplete or inappropriate. Someone who needs approved legal wording should not mistake a general editorial review for specialist advice. Someone without an agreed problem may need exploratory work before commissioning a fixed output. Explain the reason for the boundary and the kind of clarification needed. Avoid recommending a particular external provider unless you have a basis for doing so and can describe the relationship accurately.
Review suitability against actual enquiries and engagements over time. If repeated questions reveal a missing condition, update the page and preparation materials. Keep the description focused on the current offer rather than accumulating every exception you have encountered. Test whether someone can explain both when to consider the service and when to pause. An effective suitability statement supports a better initial conversation without claiming that following the conditions guarantees a successful project or commercial outcome.
Fictional example: a team ready to use recommendations
A fictional reporting advisor, Lin, offers a review of an existing monthly pack. Her suitability section says the service is intended for teams with an established report and a named owner who can resolve questions about definitions. It provides observations and recommendations, with implementation remaining internal. The example avoids describing a particular company size as automatically ready.
An invented enquirer has no current report and wants a reporting system built. Lin’s description directs them toward a scoping discussion rather than treating the review as a complete fit. Another fictional team has a pack and an available owner, so the next step is to discuss the document set. These scenarios clarify readiness without inventing client experience or promising that either route produces a guaranteed outcome.
A checklist for your next step
- Name the relevant starting situation.
- Identify necessary client inputs.
- Explain how the handover is used.
- State unsuitable adjacent cases.
- Review recurring enquiry confusion.
Common questions
Should I list every unsuitable client type?
No. Focus on situations that materially change fit, including missing inputs, approval needs and implementation expectations.
Can a service suit several organization sizes?
Yes. Explain the operational conditions that matter rather than using size as a shortcut for readiness or complexity.
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.