Before asking the customer again, find out whose information is missing
“Waiting for the customer” can hide more than one problem. A request may genuinely lack information the customer needs to provide. Another may contain enough information but be waiting for your own organisation to interpret it using records it already controls.
The first project conversation should distinguish those situations. Otherwise a proposed form redesign can transfer an internal lookup problem to the customer without making the work easier to complete.
Bring two requests that appear to have the same problem
In this fictional service business, two enquiries sit in a desk queue marked “More information needed.” Both concern replacement covers for existing equipment. The organisation is considering making a model-code field compulsory on every public enquiry.
Request E-21 contains a model label and a photograph of the existing cover, but no usable measurement of the opening. The technician's approved intake instructions require that measurement before the cover can be assessed. The image alone does not establish it.
Request E-22 contains the model label MK-8, a readable measurement and the customer's description. The office cannot find MK-8 in its current replacement-code list. Staff therefore sent the same generic clarification message to this customer, although the missing relationship is between the organisation's own model and replacement references.
The two records look similar in the queue. Their evidence points to different owners.
| Request | What is actually present | What prevents the next decision | Owner of the missing information |
|---|---|---|---|
| E-21 | Model label and cover photograph | Required opening measurement is absent | Customer clarification, using the agreed instructions |
| E-22 | Model label MK-8 and required measurement | Current staff list has no MK-8 replacement mapping | Organisation's product-record owner |
The measurement is part of a fictional business process, not advice on how to select a safe or suitable component. Technical suitability remains a decision for the organisation's authorised specialist.
Inspect the internal source before changing the form
The product-record owner checks the approved source register. Its current entry links MK-8 to replacement reference CV-208, with a note that a final technical assessment is still required. The receiving desk's lookup list was prepared from a smaller selection that omitted MK-8.
The owner confirms that MK-8 belongs in the list used for this request type. This is an explicit source decision. A developer should not infer the relationship from a similar-looking reference or copy a code from another customer's enquiry.
The first useful scope is therefore a staff lookup correction and a clearer route for an unmatched model. It does not require a new mandatory public field asking customers to know CV-208. The organisation already owns that information.
E-21 remains a customer clarification. Staff use the approved measurement question and retain the original request reference. They do not invent a measurement from the photograph or mark the request ready because E-22 has been resolved.
Complete the desk task
In the private example, the corrected staff list includes the authorised MK-8 relationship. An ordinary desk operator opens E-22, finds CV-208 with its assessment note and records that the internal lookup is complete. The request moves to the existing technical-review step; the customer is not asked to supply the organisation's own replacement code.
The operator also tries an unknown model MK-99. It remains unmatched and goes to the product-record owner. The correction must not turn a lookup into an automatic guess whenever a value is absent.
E-21 still shows its missing measurement and clarification owner. A previously supported model continues to return its own reference. These checks establish the boundary of the change: one authorised mapping has been restored to the staff task, while missing customer evidence and unknown internal relationships remain distinct.
Make the first deliverable small enough to examine
The discovery note now names three pieces of work: correct the approved lookup coverage, show the reason a request is waiting and give staff the right next owner. A wider catalogue or new portal can remain a separate option.
The reviewer can ask specific questions. Does E-22 reach technical review without another unnecessary customer message? Does E-21 still require its measurement? Can staff distinguish an unknown model from an incomplete customer description? Those are more useful acceptance questions than whether the new system looks more modern.
No labour-saving figure is needed to make the decision. The evidence establishes an avoidable clarification and a supported correction. A broader commercial case would need its own workload and cost information.
Prepare your own examples safely
Bring a blank form and fictional or anonymised records. Include what the customer supplied, the staff message and the internal reference material involved. Identify who can approve the source facts and who performs the desk task.
If you cannot share the underlying material initially, describe the relationship in plain language. The purpose of the first conversation is to locate the question, not to collect private operational records before access is agreed.
Request operations can make these ownership differences visible. Use project planning to identify the first complete task, then discuss the example with the decision-maker who can confirm the relevant source.