
Prepare a question-and-resource packet
Separate meeting details, discussion questions, and supporting resources. The Workona discovery example organizes scheduling, agenda, and resources such as a creative brief. The questions below are an original discovery sequence, not a sales script or a copy of that product's workspace.
This illustrative example is a fictional local repair business asking for a website. For the exercise, one sample answer is supplied: customers call to ask whether the shop repairs their type of item before bringing it in. This is not a real client's statement. Budget, content approver, system access, and requested launch date remain unknown.
Bring an empty brief and the current public site or other client-approved material if available. Ask the client which service information is accurate before treating existing copy as a requirement. Do not request passwords during this discussion; record the approved access process as a later input to confirm.
Map each question to the brief it informs
| Question to ask | Why it matters | Illustrative answer or open field | Brief field |
|---|---|---|---|
| What are customers trying to find out before contacting you? | Defines the first task the site should support. | Supplied fictional answer: whether their item type is repaired. | Customer task. |
| What repair categories can you confirm, and where is that information maintained? | Establishes what content can be supported. | [SERVICE LIST AND SOURCE TO REQUEST] | Content and evidence. |
| Who can approve the service wording? | Identifies the decision needed before content is final. | [APPROVER TO CONFIRM] | Approval responsibility. |
| What must happen after a visitor finds the right service? | Distinguishes information from booking, payment, or another workflow. | [NEXT STEP TO ASK] | Scope boundary. |
| What budget, timing, and access constraints should shape the proposal? | Exposes limits before estimating work. | [BUDGET, DATE, ACCESS PROCESS UNKNOWN] | Constraints and dependencies. |
The sample answer supports investigating a service-information problem. It does not prove that an online booking system, payment feature, or customer portal is needed. Ask what happens next before adding those features to scope.
A 45-minute discovery agenda
| Minutes | Conversation | Output |
|---|---|---|
| 0-5 | Confirm the request and purpose of this conversation. | Agreed discovery focus, without promising a solution. |
| 5-15 | Examine the customer task and current failure. | Task statement and evidence to request. |
| 15-25 | Review service content and desired next step. | Known content, missing source material, and scope questions. |
| 25-35 | Discuss approval, budget, timing, and access process. | Constraints and unresolved dependencies. |
| 35-45 | Read back the brief and agree follow-up. | Corrections, resource requests, and next conversation or proposal step. |
The blocks total 45 minutes. Share the questions beforehand if that helps the client gather materials. Keep internal reminders, preliminary assumptions, and quote calculations separate from the client-facing question list.
Write the brief without inventing the answer
An illustrative first brief entry could read: “Requested work: website. Customer task to investigate: determine whether the shop handles an item type before visiting. Content needed: confirmed repair categories. Next step: [ASK CLIENT]. Budget, launch date, content approver, and access process: [UNCONFIRMED].”
That entry is useful because it identifies what the next conversation must resolve. It is not a scope agreement. Do not turn “website” into a fixed page count or quote when the service list and desired workflow are still missing.
Close by asking the client to correct the task statement. Assign resource requests and dates only when someone agrees to them. Preserve unanswered questions in the brief you use to prepare the proposal; remove a gap when the evidence arrives, not when the wording looks finished.
Copy a discovery-planning prompt
Prepare an initial client discovery agenda and question packet in US English.
Client's stated request, quoted exactly: [request]
Meeting duration and participants: [inputs]
Known customer task or reported difficulty: [supplied facts or unknown]
Current materials with sources: [inputs]
Known scope, budget, timing, approval, and access constraints: [inputs or unknown]
Required brief/proposal format: [format]
Create a timed agenda from task clarification through current evidence, desired next step, constraints, and brief read-back. Map each discovery question to its purpose and the brief field it informs. Separate known facts, my hypotheses, questions to ask, and unresolved fields. Keep internal preparation/resources apart from client-facing questions. Draft a short brief using only supplied answers, with visible gaps and a resource-request list.
Do not invent client answers, service categories, prices, page counts, approval authority, access rights, deadlines, or contract commitments. Preserve [UNCONFIRMED] and use [NEEDED: specific information] for missing evidence. Treat possible features as questions, not scope decisions. Check the meeting time total and return the requested original format. Do not create a contact submission or claim any integration.
Rehearse the questions before the client call
Ask a teammate whether each question will change a brief field or a scope assumption. An existing HTML question-and-resource packet can be saved and rendered in NOS for that internal review. Keep the client brief, proposal, and contract in the agreed tools and formats. Go into the meeting ready to clarify the customer task; leave it with supported requirements and named gaps rather than a confident quote built on missing answers.