What a Good Technical Consultancy Brief Looks Like

A good technical consultancy brief is a single document that tells an external team everything they need to make a real assessment of your problem: the context, the constraint, the outcome you're aiming for, and the decisions that are already fixed. It's not a spec. It's not a wishlist. It's the information transfer that makes the difference between getting a sharp, relevant response from a consultancy and getting a generic holding reply while they try to figure out what you actually need.

Why most briefs fail before the first call

When a brief arrives at a consultancy, the first question anyone asks is: can we actually help here? Not in a gatekeeping way, but practically. Without enough context, the honest answer is always "maybe", and "maybe" leads to a long discovery process that burns everyone's time before anything useful happens. The briefs that work are the ones that let the consultancy arrive at the first call already thinking about the real problem, not still asking basic scoping questions.

The most common failure mode is describing the solution rather than the problem. A brief that says "we need a mobile app with these twelve features" has already closed off the conversation. A brief that says "we have field engineers who currently manage scheduling via WhatsApp and it's costing us about a day a week in coordination overhead" leaves the consultancy room to bring real thinking. That distinction matters more than anything else in this guide.

The structure: walk through it in the order it actually matters

1. Who you are and what the business actually does

Not a pitch. One or two sentences that orient the consultancy to your world: the industry you're in, roughly how many people are involved, whether you're pre-revenue or trading, and whether you have any technical people in-house. That last point is critical. A consultancy advising a solo founder with no developers needs to calibrate completely differently to one working alongside an existing engineering team.

2. The problem, in plain language

Describe what is actually going wrong, or what opportunity you're trying to capture, and why it matters now. Be specific about the pain. "Our reporting process takes three people four hours every Monday morning and the output is still wrong half the time" is useful. "We need better data" is not. If there's a business cost you can point to, name it. Consultancies think in terms of impact, and the clearer you are about the cost of the problem, the better they can help you prioritise what to actually fix.

3. What you've already tried

This is the section most briefs skip entirely, and it's one of the most valuable. If you've already bought a tool that didn't work, tried to hire for the role, or had a previous agency take a run at it, say so. Not to complain, but because it tells the consultancy where the real friction is. A lot of problems that look like technology problems are actually process or organisational problems in disguise. Knowing what's already been attempted changes the diagnosis.

4. Your existing technical landscape

List what you're already running: your core platforms, databases, any APIs you're integrated with, your hosting setup if you have one. You don't need to be technical to do this. Screenshots of your stack from a tool like StackShare, or even a rough list of the software your team uses daily, is enough to start. What you're communicating is the integration surface the consultancy will need to work around. If you're on a specific cloud provider, or if there's a system that absolutely cannot be touched, say so explicitly.

5. Constraints that are actually fixed

Separate real constraints from preferences. Real constraints are things like: a regulatory deadline, a budget ceiling, a system that legally can't store data outside the UK, or a launch that has to happen before a specific event. Preferences are things like "we'd prefer React" or "we like the look of this tool". Good consultancies will work with preferences but will push back on them if there's a better fit. Real constraints shape the entire engagement, so they need to be visible from the start.

6. The outcome you're measuring against

What does success look like at the end of the engagement? Not in terms of deliverables, but in terms of the thing that changes in the business. "The field engineers can schedule their own work without the office team" is an outcome. "A scheduling module with calendar sync" is a deliverable. Deliverables are a means to an end. If you tell the consultancy the outcome you're actually after, they can tell you whether the deliverable you've imagined is the right one, or whether there's a shorter path.

7. Your timeline and budget range

You don't need to know the exact figure. But withholding budget entirely is a pattern that wastes everyone's time. A consultancy that works in the £5,000–£20,000 range and one that works in the £100,000+ range will give you completely different answers, and both could be perfectly competent. Giving a range, even a rough one, lets the consultancy tell you honestly whether they're a fit or not before you've spent two weeks in discovery calls. The same applies to timeline: if you have a hard date, say so.

What people consistently get wrong

• Treating the brief as a negotiating position. Hiding your real budget or deadline because you think it'll push the price up. It doesn't. It just creates a first engagement built on incomplete information, which is the fastest way to a bad outcome.
• Writing the spec instead of the problem. Every constraint you bake into the brief before the consultancy has weighed in is a decision you've made without their input. Sometimes that's right. Often it closes off better solutions.
• Skipping the context about internal capability. Whether you have a technical co-founder, a single developer, or no one at all shapes almost every recommendation the consultancy can make. Leaving it out forces them to assume.
• Making it too long. A ten-page brief full of background reading is harder to act on than a two-page brief with the seven things above covered clearly. Depth is good. Verbosity is not depth.
• No clarity on who makes decisions. If there are multiple stakeholders who need to sign off, say so. A consultancy that quotes for a clean two-person engagement and then discovers there's a board and a legal team in the loop will end up re-scoping everything. Put the decision-making structure in the brief.

A simple template to work from

The practical takeaway

The point of a good brief is not to impress anyone. It's to make the first real conversation as productive as possible. A consultancy that's read a clear brief has already done some thinking before they get on the call. They'll ask better questions, they'll push back on the right things, and they'll give you an honest view on whether the engagement makes sense, rather than just telling you what you want to hear because they haven't fully understood the situation yet.

If you're preparing to engage an external technical team and you write down the seven sections above, you're already ahead of the majority of briefs that arrive at most consultancies. Not because the bar is low, but because most people underestimate how much useful information they're sitting on and overestimate how much specification they need to provide. The problem and the context, clearly written, is usually enough to get the engagement started properly.