Use the first conversation to separate a form problem from an unanswered business question
“We need a better enquiry form” can describe several different problems. The form may lose information, ask an unclear question or deliver a perfectly intact request that the business has not decided how to classify. The first conversation should establish which of those is happening before choosing more fields or a new platform.
Consider a fictional supplier that receives enquiries for metal components. Staff say that requests labelled “coated parts” take too long to route. The initial proposal is a compulsory finish selector with many technical options. A short review of three examples changes that proposal.
Bring examples that preserve the distinction
The team removes customer names and private drawings while retaining the information relevant to routing. The examples show the customer's wording, the actual received record and the question staff could not answer.
| Example | What arrived intact | What staff still needed |
|---|---|---|
| Q-12 | Exact reference MT-18 and the words “coated version” | Whether the buyer meant the supplier's published finish variant |
| Q-13 | A description of parts the customer already owns | Whether the enquiry concerned treatment of customer-supplied parts, a service the company had not listed |
| Q-14 | A current catalogue reference and its explicit finish | Nothing about finish; this request could follow normal review |
This evidence does not show a broken submission. All three descriptions are present in the receiving system. It shows that one broad phrase is covering different tasks and that the company has not given the website an approved way to distinguish them.
Test the proposed field against the actual uncertainty
A compulsory technical selector might help Q-12 if the buyer recognises the supplier's finish terminology. It does not answer Q-13's service question. It also adds work to Q-14, where the selected reference already establishes the relevant variant.
The team considers three options: require everyone to choose a finish, allow every request to remain free text, or retain known catalogue context and provide a bounded clarification route for other requirements. The first is too demanding for the uncertain customer; the second discards useful structure that already exists.
The commercial owner confirms that enquiries about treating customer-owned parts should go to a named person for a scope decision, without a public promise that the service is offered. The catalogue owner confirms which finish information is already attached to MT-18. These are decisions the form designer could not safely infer.
Define the first useful change
The agreed first change keeps a selected reference and its approved variant information visible. It also asks the sender whether the enquiry concerns a listed item or another requirement. The latter route includes a description and an explanation that staff will first review whether the business can help.
For Q-12, the response asks the specific variant question without forcing the buyer through an unfamiliar list. Q-13 reaches the approved scope-review route and remains an enquiry about a possible service. Q-14 proceeds with its existing catalogue information; it does not need a redundant finish choice.
The proposal is now bounded. It concerns the entry and routing of these request types, not a complete technical product selector or an automated suitability decision. The team records the content approvals and the receiving roles before estimating implementation.
Leave with evidence and an open-question list
The first conversation should distinguish what was inspected from what remains uncertain. In this case the sample records establish that the current form preserved the wording. They do not establish that every submission succeeds or that all possible product requests are covered.
The resulting acceptance examples repeat Q-12, Q-13 and Q-14 with fictional details. They check the customer explanation, received context and assigned review route. If an interface or staff permission is still unverified, it remains a dependency rather than being written as a capability.
For your own discussion, bring one clear request, one ambiguous request and one exception. Explain the decision each requires. That small comparison is often enough to distinguish a software failure from a content or responsibility gap.
Use project preparation to organise the participants and constraints. The quote-intake service describes how an agreed first review can become a useful customer path.