Why your automation project brief isn't working — and what to write instead

Most automation projects do not fail during the build. They fail before it starts.

The brief was vague. The scope drifted. The provider built something technically correct that did not solve the actual problem. Three months later, nobody is using it, and the post-mortem conversation is uncomfortable for everyone.

This is not usually a capability problem. It is a brief problem.

What most project briefs get wrong

Search for an automation project brief template and you will find documents that ask for budget, timeline, stakeholders and objectives. Most of them are adapted from generic project management frameworks that were built for internal teams, not for briefing an external specialist you have not worked with before.

They tend to produce briefs that describe what you want to build rather than what you need to solve.

That distinction matters more than it sounds. A brief organised around a solution — "we want to automate our invoice processing using OCR and a workflow tool" — locks the provider into an approach before they have understood the problem. You get someone executing a specification rather than someone applying capability to a situation.

The best briefs describe the problem clearly and leave room for the provider to bring their experience to bear on how it gets solved.

What a capability brief includes instead

A capability brief is not a project specification. It is a structured description of the work that needs doing, written to help relevant providers understand whether they can help and how.

It has five components:

• The problem. What is happening now that should not be, or not happening that should be? Be specific. "Our onboarding process takes too long" is not a problem statement. "New clients currently wait an average of four days to receive their welcome pack and account credentials because the process involves three manual handoffs between two teams using different systems" is.
• The current state. What does the process look like today? What tools are involved? Where does it break or slow down? Who touches it and when? A provider cannot assess scope without understanding what they are walking into. The more honest this section is, the more accurate the response you will get.
• The desired outcome. Not the solution — the outcome. What should be true when this is done? What does good look like in concrete terms? "Faster onboarding" is an aspiration. "New clients receive all onboarding materials within four hours of contract signature, without manual intervention from the ops team" is an outcome.
• The constraints. Timeline, budget range, existing tools you are committed to, internal bandwidth for the engagement, any compliance or data considerations. Constraints are not weaknesses. They are scope. A provider who cannot work within your constraints should tell you that upfront. A brief that omits them will produce proposals that do not survive contact with reality.
• The timeline. When does this need to be done, and why? If there is a hard deadline, say so and explain it. If there is flexibility, say that too. Timeline shapes how a provider thinks about resourcing and approach. Leaving it vague produces vague proposals.

A worked example

Here is the same brief written two ways.

Before

We are looking for an automation consultant to help streamline our sales reporting process. We currently use HubSpot and export data manually to build weekly reports. We would like this to be automated. Budget is flexible. Timeline is ASAP.

After

Our sales team currently spends around three hours each Monday manually pulling data from HubSpot, formatting it in Excel, and distributing a weekly performance report to six stakeholders. The process is error-prone and the report is often late, which delays our Monday planning meeting.

We want this fully automated so that the report is generated and distributed by 08:00 every Monday without manual input. We use HubSpot, Google Sheets and Slack. We are open to additional tooling if it is justified.

We need this live within six weeks. Our ops manager can give two to three hours per week to support the build. Budget is in the range of £3,000 to £5,000 for a fixed-scope engagement.

The second brief will attract different providers, produce more accurate proposals, and result in a better first conversation. Nothing in it required more information — it just required the information to be organised around the problem rather than the solution.

Why a clearer brief gets you better providers

A vague brief does not attract fewer responses. It often attracts more, because the scope is undefined and anyone can claim to be relevant.

A specific brief filters naturally. Providers who have not solved this class of problem will self-select out. Providers who have done exactly this — or something close enough to have a view — will respond with more useful proposals, sharper questions, and a clearer sense of what the engagement should look like.

That is not a recruitment filter. It is a capability signal. The quality of the response tells you something about the quality of the provider.

A human-reviewed shortlist works the same way. When the brief is clear, fit indicators are easier to assess. When the brief is vague, everything looks like a potential match and nothing is easy to compare.

Start with a clear brief. Everything downstream gets easier.

If you have automation, AI, product or engineering work that needs doing in the next 30 to 60 days, submit your first capability brief. The platform guides you through each section so you arrive at something specific enough to get a useful response.

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