Turn a capability into a service by naming a specific starting situation, the work you will undertake and the artifact a client receives. Explain required inputs, boundaries and completion criteria. Test the description against a realistic brief before presenting it as an offer someone can request.
Find a bounded starting problem
A capability describes something you can do; a service describes a piece of work someone can understand and commission. Begin with a situation rather than a skill list. Instead of “research and strategy,” identify a task such as reviewing an existing interview plan before recruitment begins. Specify who faces that situation and what prevents progress. The narrower description lets you consider whether you can deliver something useful with the evidence and access likely to be available.
Write the conditions at the start of the engagement. Does the client already have a draft, access to relevant colleagues or permission to share material? A service built around reviewing an existing document will not fit a client who needs the document created from nothing. Record these differences before choosing a name. If several starting conditions require substantially different work, they may need separate offers or an initial scoping conversation.
Describe work and a reviewable output
List the activities required to move from the starting condition to a useful handover. Connect each activity to something the client can inspect: a marked-up document, an issue register, a facilitated decision record or a prioritized recommendation list. Distinguish the activity from its intended benefit. Reviewing a process can produce a clearer account of its problems; it cannot promise that an organization will implement every recommendation or achieve a particular commercial outcome.
Define what completion means. It may mean delivery of an agreed report and one discussion of its findings, rather than unlimited work until every stakeholder is satisfied. Include a review step with a stated purpose, such as checking factual accuracy or discussing the implications. If the output requires specialist approval before use, identify who supplies that approval. A service remains useful when responsibility for the next stage is clear instead of silently absorbed into the promise.
Test the boundary with a sample brief
Create a plausible enquiry and walk it through the proposed offer. Note every point where you need more information, different permissions or additional effort. Revise the public description to include the conditions most likely to affect fit. Keep detailed negotiation terms in an appropriate proposal, but do not hide an essential dependency until after someone has committed time. A reader should understand the shape of the service before being asked to discuss a project.
Choose a plain name that reflects the output or task, then add a short suitability statement. Avoid naming the service after an ambitious business result that your work cannot control. Revisit the definition after genuine engagements reveal recurring exceptions. Changes should improve accuracy rather than retroactively redefine what earlier clients received. Keep a dated description of each offer so the profile, enquiry response and eventual scope document remain aligned.
Fictional example: from analysis skills to a review
A fictional analyst, Imani, advertises “data, operations and business intelligence.” She wants a more understandable offer and drafts a monthly-report review for teams that already produce an internal report. The client supplies one reporting pack, its intended audience and a list of decisions it should support. Imani reviews structure and definitions, then returns annotated pages and a prioritized question list.
The offer includes a discussion of the review and a corrected factual version. It excludes building dashboards, validating financial statements and running the reporting process. A trial brief reveals that the client must identify an internal owner for unresolved definitions, so Imani adds that prerequisite. The example defines the work without suggesting that the review automatically changes business performance.
A checklist for your next step
- Name the starting situation.
- Specify required client inputs.
- Connect activities to inspectable outputs.
- Define completion and review.
- Test a realistic sample enquiry.
Common questions
Can one capability support several services?
Yes. Separate them when starting conditions, outputs or responsibilities differ enough to confuse a single description.
Should the public description include every contract term?
No. It should disclose the conditions material to fit. A proposal can explain detailed terms for the particular engagement.
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.