Turning a vague request into a clear brief (with the template)

A vague request becomes a clear brief when you replace "something with AI" with one repeated task, trace it as trigger, information, action and exception, choose the single number you'll measure before and after, and write down what is not included. That fits on one page and takes one conversation. Build from the brief, not from the request, and most scope arguments never happen. Below are the questions that get you there and the template to fill in.

Why do vague requests turn into bad projects?

Because both sides fill the gaps with different assumptions. The owner imagines a system; you imagine a workflow. Three weeks later the owner asks where the dashboard is. The brief is where the two pictures are forced to match, in writing, before money and time are spent.

Step 1: find the task behind the request

Ask about the day, not about AI. "Walk me through what happens when a new customer contacts you." Listen for the sentence with a sigh in it. That sentence is the task. If several come up, pick the one with the clearest before-and-after; the others go on a list for later, which itself reassures the client that you heard them.

Step 2: trace the flow in four parts

Write each answer as a sentence the owner would say. If the exception line is blank, the brief isn't done.

Step 3: pick the number

One measurement, taken the same way before and after, by a named method: "First reply time from the CRM timestamps, averaged over two weeks." Agree who reads it and when. Without this line the project ends in opinions.

Step 4: write what's out

The most protective paragraph in the document: "Not included: replies to existing customers, Instagram messages, any change to the website form, reporting dashboards." Specific exclusions, not "anything else". This is where scope creep is prevented, not negotiated.

Step 5: the one-page brief

Note Template · Task: one sentence. · Trigger: … · Information: … · Action: … · Exception: … · We measure: what, how, who, when. · Done means: runs on real inputs for five working days without manual fixes. · Not included: … · Needs from you: access to …, decisions on … · Timing: two weeks from access. · Price and schedule: … · Approved by / date.

Send it as a PDF or a shared doc and ask for a one-line reply: "Approved." That reply is your contract's backbone, and the guided builds on AgeBridge start from exactly this shape.

Handling the follow-up asks

When the owner says "can it also…" during the build, the answer is "Yes, as an add-on" plus two lines: what it does and what it costs and adds to the timeline. Not "no", not a silent "sure". The brief makes this a normal conversation instead of a confrontation.

Best fit and not a good fit

Best fit: any project with a business that hasn't bought automation before. Not a good fit: a client who wants exploratory work without an outcome; offer a paid audit and write the brief at its end instead.

What to do this week

Take the last request you received, however vague, and fill the template from memory. Where you can't fill a line, that's the question you should have asked. Ask it on the next call.