How to Write a Service Brief That Gets You Better Proposals
A provider cannot give you a sharp proposal if your opening message reads like a shrug. Buyers often ask for a quote with a line such as “we need help with our website” or “can someone do our marketing”. That may feel efficient, but it forces the freelancer to price uncertainty instead of work. The result is familiar: one vague estimate, one over-scoped proposal, one under-scoped proposal, and a pile of follow-up questions that could have been answered in the first brief.
A strong brief is not a formal tender document. It is a practical note that helps the provider understand the problem, the current situation, the constraints, and what good would look like if the work went well. Good providers do not need ten pages of theatre. They need enough context to decide whether the project suits them, whether the budget feels realistic, and what shape of scope of work should be proposed.
If you write the brief well, the proposal stage becomes more useful immediately. Providers can challenge assumptions, recommend a route, price sensibly, and prepare for a more productive discovery call. That is the real goal. The brief is not there to sound impressive. It is there to remove guesswork.
Brief-writing in one page
Write the brief so a capable provider can understand the business problem, the desired result, the constraints, and the inputs they will need before they ever quote.
- Start with the business problem before you mention the output you think you need.
- State timing, budget range, stakeholders, and any fixed constraints honestly.
- List the files, systems, logins, or source material the provider will depend on.
- Define what success should look like in practical terms rather than taste-based language.
- Use the brief to invite a better proposal, not to lock the provider into your first guess.
Start with the problem statement, not the shopping list
The brief should open by answering one simple question: what is happening that has made this work necessary? If leads have stalled, if a launch date is approaching, if your site no longer reflects your offer, or if the current system is causing expensive manual work, say that first. Providers read the opening lines to understand pressure, purpose, and urgency. When the problem is visible, they can judge whether the output you requested is actually the right route.
Buyers often do the opposite. They start with a list of tasks because that feels more concrete. “We need three landing pages, some email copy, and PPC support” sounds decisive, but it may hide the real issue. A provider may spot that the weak point is the value proposition, poor page structure, or broken tracking. If the brief begins with the business problem, the provider has permission to improve the route rather than merely price the task list.
A useful opening paragraph therefore sounds less like a procurement note and more like a situation report. Explain what has changed, what outcome matters, and why now. That alone can improve proposal quality because the provider stops guessing at the commercial context.
Use a practical brief template that real providers can work from
A reliable brief template is short and boring in the best sense. Include: project background, the problem to solve, the intended outcome, the assets or pages involved, current tools or platforms, deadline reality, budget range if known, who approves the work, and what materials already exist. This is enough for most marketplace projects. You can add category-specific details later, but the core document should already tell the provider how the job sits inside the business.
Here is a usable structure in plain English: “We are [business type]. We need help with [problem]. We believe the likely deliverable is [output], but we are open to challenge. The work affects [pages, systems, channels, or assets]. Success would look like [specific outcome]. Timing is [fixed date or preferred window]. Decision-makers are [names or roles]. Existing materials include [files, examples, analytics, brand guidelines, account access]. Constraints include [budget, legal review, platform limits, internal sign-off].”
That template works because it tells the provider what they need in order to think. It also exposes gaps. If you cannot describe the outcome, you may need a scoping session first. If you do not know which assets are involved, you may need an audit before a full quote. A brief that reveals uncertainty early is still a good brief.
Poor versus strong brief examples
A poor brief for copywriting might say: “Need website copy for a professional services company. Looking for somebody experienced. Please quote.” A provider reading that has no idea whether the issue is positioning, tone, conversion, SEO, product explanation, or simply a rushed rewrite before launch. They cannot price revisions or estimate workload sensibly because the problem is invisible.
A stronger version could say: “We are a two-director HR consultancy relaunching our site in June. Our current pages sound generic and do not explain our retained support service well. We need homepage and three service pages rewritten. We already have rough wireframes and stakeholder notes. Success would mean clearer differentiation, stronger enquiry quality, and copy that can be signed off internally without another rewrite cycle.” The second version creates a much better basis for a proposal because the provider can see the business setting, the assets involved, and the desired result.
The same principle applies across categories. A poor design brief says “need a logo urgently”. A stronger one explains whether the job is a stand-alone deliverable, a wider rebrand, or an interim update before another phase. Strong briefs are not stronger because they are longer. They are stronger because they reduce hidden assumptions.
How to mention budget and timeline without boxing the provider in
Buyers often avoid budget because they fear being overcharged. In practice, no budget signal usually creates worse outcomes. Providers either guess too low to stay in the conversation or pad the quote to protect themselves from unknowns. A sensible budget range helps both sides. It tells the provider whether this is a rapid tactical task, a more strategic piece of work, or something that may need staging through milestones.
You do not need to declare a perfect number. Phrases like “We have set aside around £1,500 to £2,500 if the scope is realistic” or “We can fund discovery first, then approve implementation once the route is agreed” are far more useful than silence. They tell the provider how to shape the response. They also reduce the chance that everyone wastes time discussing work that was never commercially aligned.
Treat timing the same way. There is a difference between “must be live before our 15 July event” and “we would prefer to start this month if the proposal is right”. When the deadline is false urgency, providers cannot plan sensibly. When the deadline is real, the provider can decide whether pace is part of the job and price the risk accordingly.
Success criteria should be observable, not decorative
A brief improves dramatically when success criteria move beyond taste. “Make it more premium” or “make it pop” does not help a provider quote responsibly because those phrases do not describe what the buyer needs to see, measure, or approve. Better success criteria explain the change you expect after delivery. That might be clearer product explanation, faster internal sign-off, fewer support questions, stronger conversion from a campaign page, or cleaner handover to another team.
Success criteria do not have to be numeric, although sometimes they should be. The useful test is whether a third party could read the brief and understand what “done well” means. If the job involves a landing page, perhaps the target is message clarity and readiness for paid traffic. If the job involves a proposal document, perhaps the target is a reusable template that sales staff can update without design help. These are concrete, assessable outcomes.
Good success criteria also improve proposals because providers can explain how they intend to reach them. Instead of responding with generic enthusiasm, they can discuss process, risk, review rounds, and dependencies in relation to a visible goal.
Include files, access, and dependencies before they become hidden blockers
Many projects slow down not because the provider worked poorly but because the buyer forgot to mention dependencies. If the freelancer needs analytics access, a CMS login, existing design files, legal wording, product data, or a subject-matter reviewer, the brief should flag that. Providers can then decide whether the job is ready to quote or whether some preparatory work is needed first.
This is especially important where multiple people hold information. A web developer may need access to hosting, repository credentials, API documentation, and whoever controls the domain. A copywriter may need product notes, recorded sales calls, and a decision-maker who can explain the offer clearly. Listing those inputs in the brief does not make you look disorganised. It shows that you understand how delivery actually happens.
If some items are not ready yet, say that too. A note such as “brand files exist but need to be gathered” or “analytics access can be provided once a provider is selected” is perfectly workable. What matters is that the provider can see the dependency map before they price the job.
Checklist before sending a service brief
Use this as a final discipline check before you request proposals.
- Can somebody unfamiliar with the project understand the problem in the first paragraph?
- Have you listed the assets, systems, or channels affected by the work?
- Have you explained what success should look like when the job is complete?
- Have you named the budget range or funding approach honestly?
- Have you separated hard deadlines from preferred timing?
- Have you listed files, logins, reviewers, or access dependencies?
- Have you left room for the provider to challenge the route if a better answer exists?
Where to go after the brief is written
The next useful subjects are first-time hiring discipline, running a sharper discovery call, and writing service pages from the provider side.
Related reading
Relevant marketplace services
