How To Write A Capability Brief

Most teams know what is broken. They are less clear on how to describe it in a way that actually helps a specialist respond.

The usual instinct is to write something that looks like a job description: a list of requirements, a set of desired skills, maybe a vague reference to the kind of experience they are looking for. Then they wonder why the responses are either too generic or completely off the mark.

A capability brief is not a job description. It is a description of work that needs to happen, written in a way that makes it possible for the right provider to say: yes, I can deploy that.

Here is how to write one.

Start with outcome, not role

The single most useful thing you can do before writing anything else is finish this sentence:

*When this work is done, we will have \\\\.*

Not "we will have hired someone." Not "we will have a process for." A concrete outcome.

Examples:

• "When this work is done, we will have automated the customer onboarding workflow from form submission to account activation, with no manual steps."
• "When this work is done, we will have an internal reporting tool that pulls from our CRM and gives the sales team a live view of pipeline without exporting spreadsheets."
• "When this work is done, we will have a working AI triage layer that routes inbound support tickets to the right team before a human reviews them."

The outcome is the anchor. Everything else in the brief should follow from it.

Describe the current problem

Providers need to understand what is actually blocked or broken, not just what you want to exist.

Good capability briefs answer:

• What is currently manual, slow or failing?
• Who feels the pain most directly?
• What has been tried already?
• What is the cost of leaving it as it is?

This matters because a specialist reading the brief needs to assess whether they have solved this kind of problem before. The more concrete you are about the current state, the faster they can make that judgement.

You do not need to diagnose it perfectly. "We are not sure exactly where the bottleneck is" is useful information. What is not useful is describing the problem so vaguely that any automation consultant with a website could claim to solve it.

Name the type of capability you need

You may not know the exact technical solution. That is fine. But you should be able to indicate the type of capability the work requires.

Is this:

• AI implementation — building or connecting a model, prompt layer or AI workflow into an existing system?
• Workflow automation — removing manual steps from a repeatable process using tools like Zapier, Make, n8n or custom code?
• Product engineering — building or extending a product, service or internal tool?
• Data and integration — connecting systems, building pipelines, surfacing data where it needs to be?
• No-code or internal tools — Notion, Airtable, Retool, Glide or similar?
• Fractional product or engineering leadership — strategic input and direction without a full-time hire?
• Not sure yet — you know the outcome but not the method?

"Not sure yet" is a legitimate answer. It signals that the brief may need a diagnosis phase first. That is useful for providers to know.

Define the scope

What is in scope for this engagement and what is not?

The scope does not need to be perfectly drawn. But it should indicate what phases of work the brief covers.

Common scope phases to consider:

• Diagnose — assess the current state and identify the approach.
• Design — map the solution, define the architecture or workflow.
• Build — implement the solution.
• Integrate — connect to existing tools, data sources or systems.
• Test — verify it works under real conditions.
• Document — produce handover documentation or operational guides.
• Support rollout — assist with adoption, training or phased deployment.

You may want all of these. You may want just the first two. Being clear about what you expect to commission avoids the most common misalignment in early conversations.

Be clear about requirements

Separate what you must have from what would be useful.

Must-haves might include:

• Specific tools or stack compatibility (we run on AWS, we use HubSpot, we are a Notion shop).
• Data security or compliance requirements.
• Time zone or working hours overlap.
• Evidence of similar work completed — case studies, portfolio, client references.

Nice-to-haves are the things that would help but are not deal-breakers.

Conflating must-haves and nice-to-haves makes it harder for providers to quickly assess fit. A provider who cannot meet a must-have should know that early. A provider who covers all must-haves should not be filtered out because of a nice-to-have they lack.

Give enough signal on timeline and budget

You do not have to commit to a precise number. But you do have to give enough signal for a provider to know whether the conversation is worth having.

Useful timeline signals:

• "We need this completed within 8 weeks."
• "We would like to start in the next two to three weeks."
• "Timeline is flexible if the provider is the right fit."

Useful budget signals:

• "Budget is in the range of £X–£Y."
• "We are looking for a fixed-fee scope."
• "Day rate or project rate both work; open to discuss."
• "Budget not yet confirmed, but the business case is in progress."

"No idea yet" is less useful than it sounds. Even a rough range helps a provider calibrate whether your expectations and their rates are in the same territory before anyone spends time on a conversation.

Describe what good looks like at the end

Success criteria make a brief significantly more useful.

What does handover look like? Does the work need to be documented? Does someone internal need to be able to maintain it? Does it need to be adopted by a team that had no input into building it?

A provider who understands what success looks like at the end can design their approach around it from the start. A provider who finds out at the end that there was an unstated adoption requirement is a provider who will have a difficult final conversation.

Common mistakes to avoid

Writing a permanent job description instead of a brief. If your document says "the ideal candidate will have five or more years of experience and a track record of leading teams," you have written a job advert. Reframe it around the work.

Asking for everything at once. A brief that includes full implementation, maintenance, training, documentation, strategic advisory and ongoing support is not a brief, it is a wish list. Scope it.

Hiding budget or timeline. Providers will work this out eventually. The only thing hiding it achieves is wasting everyone's first two conversations.

Overclaiming the AI element. Not everything that is inefficient needs AI. If the actual solution is a well-configured automation or a cleaner data pipeline, say that. Providers who specialise in the right thing will self-select in.

Not having an internal owner. Someone needs to own the brief, the relationship and the handover. If nobody in your organisation is responsible for making this work land, the best provider in the world will not save the engagement.

How Deployed Works helps

You do not need a perfect brief to start.

Deployed Works helps buyers shape briefs through a guided structure. Assistive drafting can help you find the right language for what you need — you stay in control of what is saved and submitted.

Once your brief is in, a human-reviewed early matching process turns it into a shortlist of relevant providers. You review the shortlist, you choose who to speak with, you start the conversation.

The brief does not commit you to anything. It starts a better first conversation than a job advert does.

Submit your first capability brief for Cohort 1: https://www.deployed.works/launch/cohort-1