The Client Requirements Template That Actually Gets Filled In

Most requirements templates fail for the same reason: they are a form built for the agency's convenience, sent to someone who has never written a brief before and has no idea what a good answer looks like. You get back a document with every field technically filled and nothing in it you can quote against.

Why the template you send comes back empty

A blank field is an exam question. The client does not know whether "scope" wants two words or two pages, so they write a sentence that commits to nothing, and both of you move on. Three weeks later that sentence turns out to have meant something different to each of you, and the difference is billable hours somebody has to absorb.

The fix is not a shorter form. It is a form where every question carries its own example, so the client can see the shape of a useful answer before they write one. That single change does more for completion rates than any amount of chasing.

This is the intake, not the brief

Worth separating two documents that often get conflated. The brief is what you produce: a structured statement of goals, scope, deliverables and constraints that the work is quoted and built against. The intake is what you send to get the raw material for it. If you want the output document, the project brief template covers that field by field. What follows is the other half: the questions that fill it in.

The question set, ready to copy

Send these as they are. Every one has a worked example in brackets, and the examples are doing most of the work: delete them and completion quality drops immediately.

1. 1What are we making? Describe it as if explaining to someone outside your company. Example: "A five-page marketing site for our new B2B product, plus a pricing page that can be edited without a developer."
2. 2What has to be true for this to be a success six months from now? Example: "Sales stops sending PDFs because prospects can self-serve the pricing."
3. 3Who is the audience, and what do they believe before they arrive? Example: "Procurement managers who assume our whole category is identical, and price on that assumption."
4. 4What already exists that we should reuse, and what should we not touch? Example: "Keep the current logo and colours. The blog lives on a separate platform and stays there."
5. 5What is explicitly out of scope? Example: "No CRM integration, no second language, no migration of old blog posts."
6. 6Who gives final approval, and who else must see it first? Example: "Marketing lead approves. Legal reviews any pricing wording before it goes live."
7. 7What is the deadline, and what is driving it? Example: "Trade show on 14 March, so the pricing page has to be live a week before."
8. 8What budget range are you working within? Example: "Between eight and twelve thousand; above that needs another sign-off."
9. 9What will you supply, and by when? Example: "Product copy from me by the 3rd. Photography does not exist yet."
10. 10Which technical constraints are non-negotiable? Example: "Must run on our existing hosting, and the form has to post into HubSpot."
11. 11Show us two things you like and say why. Then one you dislike, and why. Example: "Linear for its clarity, Stripe for its docs. Dislike our competitor's site because every image is a stock photo."
12. 12What has gone wrong on projects like this before? Example: "The last agency delivered something we could not edit ourselves."
13. 13What decision are you still unsure about? Example: "Whether to keep the case studies or drop them entirely."
14. 14Is there anything we have not asked that you think matters? Example: "Our head of sales has strong opinions and has not been in any of these conversations."

How you send it decides whether it comes back

Three things change completion rates more than the questions do. Send it before the proposal, not after: a client answering questions to help you price the work is motivated, while a client answering after signing feels audited. Tell them how long it takes and be honest about it, because "ten minutes" that turns out to be forty is the last form of yours they fill in. And never send it as an attachment they have to download, edit and email back, since every one of those steps is somewhere the process dies.

Question 14 is the one people cut, and it is the one that most often saves a project. It gives the client permission to volunteer the thing they assumed was obvious. If you would rather not maintain a form at all, comparing an interview-based intake against a form-based one sets out the tradeoff: forms are cheaper to send, and they cannot ask a follow-up when an answer is thin.

Cut it down to the work you actually do

Fourteen questions is the full set, not the right set for every job. A one-page landing build does not need question 4, and a retainer does not need question 7 in the form written above. The version you keep should be the one where every question has earned its place by catching something on a previous project, which means the template gets shorter over time rather than longer.

Two adaptations worth making deliberately. For technical work, split question 10 into what must integrate and who owns each system, because "must post into HubSpot" hides the question of who has admin access. For design-led work, weight question 11 heavily and ask for three references rather than two, since taste is the requirement most likely to be discovered late and the most expensive to get wrong.

Resist the temptation to add a question every time a project surprises you. That is how a fourteen-question intake becomes a forty-question one that nobody finishes, and an unfinished long form tells you less than a finished short one. If a surprise was genuinely unforeseeable, no question would have caught it; if it was foreseeable, one of the existing fourteen probably should have, and the fix is a better example rather than a new field.

What to do with a vague answer

Assume you will get some. "Modern and clean" and "the usual pages" are not failures of the client, they are the natural output of asking someone to specify work they have never specified before. The mistake is accepting them and quoting anyway.

Two moves work. Reflect the answer back as a number: "modern and clean, so a single-column layout with no carousel and no stock photography, correct?" gives them something concrete to disagree with, and disagreement is what you want at this stage. Or offer two options and let them reject one, since choosing is far easier than describing.

If more than two or three answers come back thin, that is the signal to stop writing emails and get on a call. A structured discovery call will resolve in forty minutes what another round of form-filling will not resolve at all.

Bottom line

A requirements template is not a formality you clear before the real work. It is the only point where the scope is still cheap to change. Every ambiguity you leave in it gets priced at zero and delivered at cost, and it is always your cost, because the client has no way of knowing the sentence was ambiguous.

So spend the effort on the examples, send it before you quote, and treat a vague answer as unfinished rather than as an answer. The questions above are a starting point, not scripture: cut the ones that do not apply to your work and keep the ones that have caught something before.

Frequently asked questions