Turn a first conversation into a useful brief
The questions that reveal scope, urgency, and who actually makes the decision.
Confirm the approver. Separate deliverables from hoped-for revenue.
Understand the current situation
Ask what prompted the conversation and how the business handles the issue today. Listen for concrete friction: missed inquiries, slow delivery, repeated manual work, or confusing handoffs. Avoid jumping to a solution before you understand the workflow. A new website cannot fix a business that never answers incoming requests.
Define a visible outcome
Ask what would be different if the project went well. Translate broad requests into observable outcomes, such as a clear service menu and a working inquiry form. Separate outcomes you can deliver from business results that also depend on pricing, demand, or the client’s follow-up.
Surface constraints early
Confirm who approves the work, the decision timeline, available materials, and a realistic budget range. Ask about existing systems and access requirements. If a dependency is missing, record who owns it and when it will be ready rather than silently absorbing it into your schedule.
Send a short recap
Summarize the problem, deliverables, exclusions, open questions, and next step. Ask the client to correct misunderstandings before you produce a detailed proposal. The recap becomes a shared reference and helps prevent two people from remembering the same call differently.
A brief for a service website
Illustrative example—not a reported client result.
| Input or decision | Illustrative application |
|---|---|
| Current friction | Customers ask basic service questions before booking |
| Deliverable | Clear service pages and a working inquiry flow |
| Client input | Approved services, images, and business contact details |
| Acceptance | Approved copy, tested form, and agreed mobile layouts |
Turn an ambiguous request into a decision record
Illustrative working example, not a reported client result.
A prospective client says, “We need a more professional website.” That is a starting phrase, not a usable brief. Ask what a visitor should do, who handles that request, and what currently happens after submission. You may discover that the actual problem is that quote requests lack enough information for a response. The brief can then focus on a service page, an inquiry form, and a defined routing process instead of an open-ended visual redesign.
End the conversation by reading back the intended outcome, deliverables, required inputs, and unresolved choices. Send the brief for correction before estimating. This gives both parties a chance to identify a misunderstanding while it is still inexpensive to fix.
| Checkpoint | Working record |
|---|---|
| Outcome | Visitors can submit the information needed for a first quote discussion. |
| Deliverables | Service page, inquiry form, confirmation screen, and routing test. |
| Client input | Approved service descriptions and the destination for requests. |
| Open decision | Whether customers need file uploads at first contact. |
Do not translate every wish into an included deliverable. A client mentioning online payments does not automatically make payment integration part of the agreed first release.
What if the client cannot answer every question?
Record the unknowns and identify who can resolve them. Quote a bounded discovery step if the missing information materially affects effort; otherwise state a clear assumption and its effect if it changes.
Use the related business calculator to test the numerical assumptions where applicable. Record nonfinancial decisions in your action plan.
Put the idea to work.
- Confirm the approver.
- Separate deliverables from hoped-for revenue.
- Send the recap before estimating.
One more question
What if the buyer cannot describe the problem?
Ask them to walk you through a recent example. Concrete events usually reveal more than asking for a general list of goals.
AI-assisted educational content. Examples are illustrative, not reported client results. Editorial standards.