The hidden workload inside an incomplete enquiry

Last week, I wrote about a sale the business never saw.

I wanted fitted insect screens for my ground-floor apartment in Basel. I had the problem, the means to buy and a real reason to act. The public journey left me uncertain about the product, the measurements, the response and what requesting a quote would start. I delayed before sending an enquiry.

The business received no signal from me.

That buyer-side story carries a second question. What work would the business have faced if the enquiry had contained only the information I genuinely understood at the time?

The available facts were useful and incomplete. I knew the problem at home. I knew I wanted fitted screens. I could describe the windows and doors in ordinary language. I lacked the product configuration, reliable dimensions and the vocabulary needed for a technical choice. I also wanted price context before making a commitment.

Those facts show intent. They leave 6 operating decisions open.

The owner may need to clarify the problem, decide whether the dimensions are usable, identify the relevant product route, choose what price guidance is safe, decide whether a measurement visit is needed and set the next follow-up.

Each open decision takes attention. A useful customer system prepares those decisions before the qualified person takes over.

The owner-side mirror

The customer and the owner can experience the same gap from opposite sides.

The customer lacks enough information to proceed with confidence. The owner lacks enough structured information to decide what should happen next.

On the customer side, the gap appears as uncertainty. On the owner side, it can appear as clarification, preparation and follow-up work.

That sentence is a hypothesis about the operating workload. My buying experience proves one customer moment. The Sofortli demonstration proves that a guided route can be built and tested with sample data. Owner interviews, real enquiry records and outcome evidence are still required before I can say how often this workload appears or what it costs.

The distinction matters. A prototype earns the right to ask a better evidence question. It does not supply the answer.

Decision 1: what problem is the customer trying to solve?

In my case, the starting point was practical: keep mosquitoes and other insects out of a ground-floor apartment while the windows and doors remain usable. “Fitted insect screen” was already a category I had learned during the search. The more detailed product language came later.

A system can begin with the problem and situation, then guide the customer towards relevant options. This is information design. AI may help interpret ordinary language, especially when the customer describes the same need in different words or languages. The output should remain a structured description of the problem. A qualified person owns the technical recommendation.

Evidence to collect: which clarification questions repeat before the business can identify the relevant product route?

Decision 2: are the dimensions usable?

A number is useful only when its meaning is clear.

The customer may provide an estimate, a photo or a precise measurement. Those inputs carry different levels of confidence. A width without the measuring point, unit or frame detail can create more questions than it answers.

The system-design job is to define the minimum usable input and label its status. An estimate can support a guide range. A verified measurement can support a later technical step. Business rules should make that boundary visible.

AI can help the customer describe what they measured and identify missing context. The output should preserve the estimate's uncertainty.

Evidence to collect: which submitted dimensions can be used immediately, which require clarification and which lead to a measurement visit?

Decision 3: which option is relevant?

Product selection combines customer preference with technical fit.

The customer can describe the opening, how it is used, the colour preference and any practical constraints. A guided route can narrow the options and explain why they may fit. A qualified person still owns the technical recommendation when the decision depends on the building, installation conditions or product rules.

This is where a fluent AI answer can create false confidence. Good language is a presentation quality. Decision authority comes from validated rules and accountable expertise.

The Sofortli demonstration keeps these jobs separate. The customer can explore a relevant route. The binding product choice remains with the qualified business.

Evidence to collect: how often does the first product route survive technical review, and which missing facts cause it to change?

Decision 4: what price context is safe to give?

In my case, price and commitment uncertainty contributed to the delay. A binding quote may require information the customer cannot provide alone.

A guide range can sit between silence and a final quote. It needs explicit business rules, known inputs and visible assumptions. The customer should understand what the range includes, what could change it and which step produces the binding price.

AI can collect the inputs and explain the assumptions in ordinary language. The pricing logic belongs to the business rules. The final quote belongs to the person authorised to issue it.

In the current Sofortli demonstration, every price is sample data and the logic still requires validation by a real business. The demonstration shows the structure of the handoff. Pricing accuracy and commercial effect remain open evidence.

Evidence to collect: which inputs are required for a useful guide range, how often the range changes after measurement and which assumptions cause the change?

Decision 5: is a measurement visit the next step?

An appointment has a purpose. The system should make that purpose clear before it asks for a time.

Some cases may be ready for measurement. Others may need a photo, one clarification or a technical review first. A fixed booking route may create avoidable visits when the decision criteria remain hidden.

Business rules can define the normal route. Automation can show available times, confirm the selection and send preparation instructions. A person reviews cases that fall outside the rule.

Evidence to collect: which visits produce a usable quote, which require another visit or clarification and which could have been prepared better before booking?

Decision 6: what should happen next?

An enquiry becomes useful when someone can see the next action.

The working Sofortli demonstration uses sample statuses, value, intent and next actions to organise the owner view. These are transparent operating signals. A validated probability model remains outside the current build.

I would start with 4 queues:

1. Ready to act. The customer has chosen a clear next step and supplied the information required for it.
2. Worth clarifying. The problem is relevant and one decision-critical detail is missing.
3. Continue follow-up. Interest is recorded and the next step remains unresolved.
4. Human review. The case involves technical judgment, unusual conditions, privacy, safety or another reason for accountable review.

Each category should show the signal that placed the enquiry there. A person can then correct the route. A hidden score gives the team less to inspect and less to learn from.

Evidence to collect: whether the category predicts the right next action, how often a person changes it and which signal caused the correction.

What to measure before claiming waste

An owner-side hypothesis becomes useful when the work can be observed.

I would record 6 things across a small batch of real enquiries:

• completeness when the enquiry first arrives;
• preparation time before the business can offer a useful next step;
• clarification rounds;
• measurement visits requested and completed;
• follow-up actions;
• the final recorded outcome.

These measures reveal the shape of the work. Lost-revenue evidence requires a separate causal test. A delayed response, an unfinished form and an unconverted quote can have several causes. The evidence has to remain attached to the stage where it was observed.

The first useful result may be modest: one repeated missing detail, one avoidable handoff or one queue that nobody currently owns. That is enough to define a better test.

The system behind the enquiry

Once the operating decisions are visible, the technology choices become easier.

Information design explains the route and prepares the customer.

Business rules define the inputs, price boundaries, normal path and exception conditions.

Automation handles confirmations, routing, reminders and known next steps.

AI works with language variation, adaptive questions and summarisation where fixed fields become too rigid.

A qualified person owns the technical recommendation, exceptions and binding commercial decision.

This is the design sequence I want The Closed Gap to teach. Start with the real operating problem. Identify the evidence and the decision. Give every job an owner. Then choose the smallest mechanism that can perform it reliably.

Turn one enquiry around

Take one real enquiry from your current process and read it from the moment it reached the business.

Write down:

1. what the customer had already decided;
2. which information was still missing;
3. which decisions the business had to make;
4. which parts used a rule and which required judgment;
5. what evidence would show whether the same workload repeats.

The Customer-Journey Test begins one step earlier, with the public route the customer sees before the enquiry exists. Together, the 2 views show where uncertainty enters the system and where work appears on the other side.

If you find one repeated missing detail or one decision nobody clearly owns, I would like to hear the words you use for it. Individual replies will remain separate from broader market evidence.

The owner-side question is simple: when an enquiry arrives, how many decisions are still hiding inside it?