Sixty percent of digital transformation failures trace back to the absence of a clear problem definition in the procurement brief. Not the wrong technology. Not the wrong partner. The wrong starting point.
I find that stat from BCG's 2024 research genuinely striking - because it means the engagement was compromised before anyone wrote a line of code, opened Figma, or scheduled a kickoff meeting. The brief - that document most firms knock together in an afternoon - is doing more heavy lifting than almost anyone gives it credit for.
And look, I get it. You've written briefs before. You know what you want. You just need quotes. We've done this plenty of times. Let's not overthink it.
But from the other side of the table, the briefs that produce the best engagements almost never look like the ones firms think are good. The best briefs don't specify solutions. They describe problems. They don't hide the budget. They share it. And they don't read like a procurement exercise - they read like an honest conversation between two people trying to figure out if they should work together.
So let me share what I'd tell a friend who was about to go to market for a digital partner. Including the bits that don't flatter my own industry.
A good brief covers seven things, and none of them need to be long. One to two pages is plenty. If your brief is longer than that, you've probably started solving the problem before you've finished describing it.
Business context. Not your company history. Not a Wikipedia summary. Just enough that a partner can understand the decision they're being asked to help with. Who you are, what you do, and the commercial moment you're in. "We're a 200-person consulting firm that's grown 40% through acquisition in the last two years and our digital presence doesn't reflect the business we've become" - that's context. A three-paragraph origin story isn't.
Problem statement. This is where most briefs fall down. "We need a new website" is not a problem statement. "Our website receives 25,000 visits a month but generates fewer than five enquiries, and we believe the issue is the journey from homepage to contact" - that's a problem statement. The difference matters enormously, because one invites a partner to diagnose, and the other asks them to quote on a prescription you've already written.
Desired outcomes. Three specific, measurable changes the investment should produce. Not "improve our digital presence" but "increase qualified enquiries by 30%, reduce content publishing time from two weeks to same-day, and give the marketing team full editorial independence." If you can't articulate three clear outcomes, you might not be ready to brief a partner yet. That's not a criticism - it's useful information.
Constraints. Budget, timeline, internal technical environment, governance requirements, compliance considerations. I'll come back to budget in a moment, because this is where most firms get it wrong. But the rest matters too - a partner needs to know whether you're running Salesforce or Dynamics, whether you're in a regulated sector, whether the board needs to approve the final recommendation. This is the information that determines whether they can actually help.
Evaluation criteria. How you'll assess responses, and what matters most. Be honest. If price is the primary factor, say so. If cultural fit matters more than cost, say that instead. Partners can handle the truth; what they can't handle is guessing.
Timeline. When you need to start, when key milestones fall, and when you'll make a decision. That last one is surprisingly important - I've seen firms leave partners hanging for months after a pitch, which is a great way to ensure the senior team you met in the presentation has moved on to other work by the time you sign.
Budget indication. Yes, really. I know. I'll explain.
This is the one that makes people uncomfortable. The instinct is understandable: If I tell them the budget, they'll just price to the maximum. It feels like a negotiating position. Withholding the number feels like leverage.
But think about what actually happens when a partner doesn't know the budget. They guess. And they guess wrong in one of two directions.
If they guess too high, you get a proposal you can't afford, and both of you have wasted your time. If they guess too low, they undersell the opportunity, and you get a proposal that sounds cheap but won't actually solve the problem. Or - and this is the ironic bit - they guess the maximum they think you can absorb, which is exactly the behaviour you were trying to avoid by withholding the number in the first place.
A partner who knows the budget range can do something genuinely useful: tell you what is and isn't achievable within it. That's information that protects you. "For £80k we can do X and Y. Z is out of scope at that level but could be phased in later." That's an honest answer. It's also the kind of answer you'll only get from a partner who's being straight with you - which, conveniently, is the kind of partner you want.
Share a range, not a fixed figure. Add a note that you're open to discussion about how the scope maps to the budget. And watch how much more useful the responses become.
I've seen hundreds of briefs over the years - literally hundreds - and the bad ones tend to fall into three categories. Each of them is a signal to a good partner that the engagement might not be worth their time.
The feature list with no context. "Needs CMS, blog functionality, contact form, client portal, analytics integration, SEO optimisation." No explanation of what problem these features solve. No indication of how success will be measured. We got one of these last year from a professional services firm - a proper laundry list, two pages long, not a single mention of what they were actually trying to achieve commercially. We went back and asked. Turns out they'd had a failed project eighteen months earlier and the brief was basically a reconstruction of what they thought had gone wrong, translated into feature requirements. The actual problem - a broken enquiry-to-onboarding handoff - wasn't in the brief at all. A good partner will look at a feature list and think: this client has already decided the solution, they just want someone to build it. Which means the most valuable thing we can offer - a better framing of the problem - isn't wanted.
The 50-page RFP. You know the one. Exhaustive documentation requirements, dozens of compliance questions, mandatory formatting for the response, word limits on each section. It signals that the relationship will be bureaucratic from day one. I remember one that arrived in our inbox a few years back - fourteen pages of mandatory appendices before you even got to the actual brief. Required font size specified. Honestly, it was an absolute state. The best partners I know will often decline these outright. Not because they can't fill in the forms, but because they've learned that firms who procure this way tend to manage the engagement the same way. And that's not an environment where good creative or strategic work happens.
The solution specification disguised as a question. This one's subtler. The brief specifies the technology ("must be built on Umbraco"), the approach ("three phases over nine months"), and the team structure ("we need a PM, two developers, and a designer"). There's nothing wrong with having preferences. But when the brief is this prescriptive, the partner isn't being asked to bring expertise to a problem - they're being asked to quote on a plan that's already been made. And if the plan is wrong, which respectfully it sometimes is, nobody's in a position to say so.
Projects with clear problem definition before vendor selection show 3-5x higher success rates, according to Standish Group and McKinsey research. That's a staggering multiplier. And it comes from getting the brief right, not from specifying the solution more precisely.
The proposal document is the least predictive part of the evaluation. Honestly. Some of the worst engagements I've seen started with beautifully produced proposals - one springs to mind, a sixty-page document with custom illustrations and a branded cover, from a firm that then missed every single milestone in the first sprint. Some of the best started with a five-page PDF and a phone call.
What actually predicts a good engagement:
The questions they ask before submitting. Did they seek to understand the brief more deeply, or did they go straight to proposing? A partner who comes back with thoughtful questions - "You mentioned conversion is the problem, but have you looked at whether traffic quality is part of the issue?" - is a partner who's thinking about your problem, not just their proposal. A partner who submits without asking anything either didn't read carefully or is telling you what you want to hear.
How they handle pushback. During the pitch, challenge something. Disagree with a recommendation. See what happens. A good partner will argue their corner respectfully, explain their reasoning, and maybe concede if your point is valid. A partner who folds immediately will fold throughout the engagement - and you'll end up with the project you described, not the project you needed.
Who's actually in the room. This is a bit of an industry secret, and it slightly pains me to say it. In some firms, the people who present in the pitch are not the people who deliver the work. Ask directly: "Will the people in this room be working on our project?" And watch the body language when they answer. I've written about why this matters in a separate piece on hourly billing and the wrong incentives in digital projects - worth a read if you're evaluating partner models.
Communication quality during the process. Are they responsive? Clear? Do they meet their own deadlines? The pitch process is the best version of a partner's behaviour. If they're slow or disorganised now, it doesn't get better after you sign.
Right, this is the part where I'm probably going to annoy a few people in my own industry.
They agreed to everything without pushback. Every brief has at least one assumption worth challenging. A partner who nods along to everything is either not reading carefully or telling you what you want to hear to win the work. Either way, not a good sign for when the project gets complicated - and it will get complicated.
They asked no substantive questions. If a partner didn't seek to understand the brief more deeply before proposing, they don't have enough information to be making credible commitments. Full stop. They're guessing, and they're packaging those guesses in confident language.
Their timeline is wildly shorter than everyone else's. If four partners say six months and one says eight weeks, the one saying eight weeks is wrong. Wrong about the timeline, or wrong about the quality of what they'll deliver within it. Neither option ends well for you.
Their price is materially below the field. A price significantly below market rate is not a bargain. I know that's a frustrating thing to hear when budgets are tight. But it almost always means one of three things: they've misunderstood the scope, they'll cut corners you can't see yet, or the pricing will change once the engagement has begun and you're committed. I've seen this pattern so many times it's almost predictable. The cheapest proposal becomes the most expensive project. Every. Single. Time.
None of this means every partner who's slightly cheaper or slightly faster is automatically suspect. Use your judgement. But when one response is a dramatic outlier, treat it as a question to investigate, not an answer to celebrate.
I should be honest about the limits of all this. A brilliant brief significantly reduces the risk of a poor engagement. It attracts better partners, produces more useful proposals, and gives you a much clearer basis for comparison. But it doesn't eliminate risk entirely. The brief is the start of a due diligence process, not the end of one.
The type of brief matters too. A brief for a website redesign is different from a brief for a platform migration, which is different again from a brief for an AI readiness assessment. The seven elements I've described apply across all of them, but the weight you give each one shifts depending on the nature of the work. A platform migration brief needs much more detail on constraints and technical environment. An AI readiness brief needs more emphasis on desired outcomes and less on solution specificity, because the whole point is that you're asking the partner to help you figure out what's feasible.
If your last digital project didn't deliver what you expected - and I've written separately about the most common reasons that happens - there's a decent chance the brief was part of the problem. Not the only part. But a contributing factor that's fixable before you go to market again.
If you want a structured template covering the seven elements of a well-written digital brief - formatted for sending to partners directly - [download it here]. It's not a 30-page procurement document. It's a one-to-two page framework with guidance notes for each section. The kind of thing you can fill in over a coffee and send out by end of day.
And if you're preparing to go to market and want a 30-minute conversation about how to structure the brief for your specific situation, [book a pre-brief consultation]. It's free, and it will save you time on the other side. We'll talk through what belongs in the brief, what doesn't, and whether the scope you're imagining matches the budget you have in mind. That last bit alone is usually worth the call.
The brief is the first signal a potential partner receives about how the engagement will work. Make it a good one.