How we handle an incomplete client brief
Across roughly 140 inbound project inquiries, almost none arrived with a full brief. Here is exactly what's usually missing, and the intake process that turns a half-formed message into a workable scope.
Almost every brief that reaches us is missing something, and that is not a complaint. Looking back across roughly 140 distinct inbound project inquiries, the pattern is consistent enough to plan around: clients rarely volunteer a budget range up front, and most leave out at least one of platform access, brand guidelines, section content, a clear line around scope, or a straight answer on how their data should be handled. A first message describes a problem, not a project. Someone still has to turn it into one, and that someone is a project manager, on nearly every inquiry that comes in.
What's usually missing from a first message
The gaps repeat often enough that a new PM here learns to expect them rather than treat each one as a surprise. The most common categories, in roughly the order they surface:
| What's missing | What that looks like |
|---|---|
| Budget range | A description of the work with no number attached, sometimes deliberately, sometimes because the client has not priced it out yet |
| Platform access | No Shopify staff account, no DNS or Namecheap login, no GitHub repo access, because the brief was written before anyone thought about handing credentials to a stranger |
| Brand guidelines | No logo files, no colour or type spec, sometimes not even a settled name for the product |
| Content for key sections | Copy and imagery for the pages that matter most are the pages nobody has written yet |
| Scope boundary | A phrase like "we also want a portal" with no answer to whether that is inside the quoted build or a separate piece of work |
| Data-handling expectations | No mention of where customer data should live, who can see it, or what happens to it if the engagement ends |
None of this means the client is disorganised. It means the brief was written by someone who knows their business and does not yet know what a build like this needs to run. That is the normal starting point, and it is the reason intake is a distinct step here rather than something folded into the first call.
Why we don't treat this as a red flag
A brief with gaps in it is the default, not the exception, so we do not read a missing budget or a vague scope line as a sign the project is a bad fit. What we do read as a signal is how a client responds once we ask. Someone who answers a direct question about access or budget, even with "we don't know yet, here's why," is easy to build with. Someone who gets evasive about who controls the Shopify account or dodges a straight question about data is telling us something worth hearing before we sign anything.
The actual intake process
This is the sequence a PM runs on a new inquiry, not a template we hand to clients and hope gets filled in correctly.
- Read the brief for what it actually asks for, separate from what it says. "We want a website" and "we want a website that replaces three spreadsheets" are different projects wearing the same sentence.
- List the gaps against the categories above, before the first call. Walking into a call with a specific list of what's missing gets a faster, more useful answer than asking "tell us more about your project."
- Ask for access early and narrowly. A staff account, not an owner login. A DNS record added for us, not the registrar password. Scoped GitHub access, not the whole org. Most clients have simply never been asked this way before, so being specific about what we need and why shortens the back-and-forth considerably.
- Draw the scope line out loud. If a brief mentions a portal alongside a lead-generation site, we say directly whether that is one build or two, and what changes about timeline and price if it's the latter. Leaving that ambiguous is how change requests turn into disputes later.
- Confirm data handling before anything is built, not after. Where records live, who has access, what happens at offboarding. This is a short conversation up front and an expensive one to have retroactively.
- Write the working brief back to the client. Not the client's words returned unchanged, but our understanding of the project, gaps closed, in a form they can correct if we got something wrong.
Where the judgement actually sits
None of the steps above are hard to write down. What takes practice is knowing which gaps to close before quoting and which can wait until after the contract, because chasing every open question up front turns a two-day intake into a two-week one and loses the client. A junior PM tends to ask for everything at once. Someone who has done this for a while asks for what changes the quote, and lets the rest surface naturally once the project has started and the relationship has some trust in it.
That judgement call, more than the checklist, is what the role actually is.