How We Built an AI Receptionist That Asks Better Questions

The customer problem behind this workflow

A conventional contact form asks everyone for the same fields. A keyword chatbot can also misfire: a mention of “flashing” might match a screen article even when the customer is describing a power problem.

YITM’s front desk must help people who are unsure of terminology, including families organising support for someone else. The first job is to understand what they need, not sell a specific service.

How we designed the YITM workflow

The reception layer first checks for safety and protected-account requests, then approved website knowledge and known service patterns. If the message is too vague, adaptive discovery asks for the missing subject: which device or service? After “It’s my laptop”, a relevant next question is whether the screen flashes, the light blinks or the computer switches off.

The desired handover is a customer-reviewable QuoteMe draft with the original symptom, identified device and later details preserved. A human technician decides what diagnostic work is appropriate. Asking a clearer question is not a diagnosis or booking confirmation.

What we built, tested and learned

During YITM’s Stage 1I acceptance work, we reproduced a genuine browser journey where the receptionist asked about the device but treated “It’s my laptop” as a fresh general enquiry. That was a product defect, even though earlier synthetic suites passed.

The improvement is a bounded clarification state, explicit question tracking and a test that follows all three turns. The regression tests later passed; the public browser journey still required verification while Stage 1I remained disabled.

What this could improve for YITM and other businesses

A better question can reduce avoidable back-and-forth and help staff begin with a more useful description. That is an expected operational benefit, not an observed reduction in response time or conversion rate.

For another Melbourne small business, start with one recurring ambiguous customer question. Record which single follow-up makes the next step possible; only then automate it.

Local business perspective: Epping, Wollert and Melbourne North

Our own service work in Melbourne’s northern suburbs provides a practical test bed: customers want a clear next step, especially when they cannot describe a technical problem. This article is a first-party YITM workflow example, not a claim that an identical automation suits every local business. A café, clinic or trade service should map its own permissions, customer journey and response expectations before copying the pattern.

A practical customer journey: three messages, one enquiry

Message one: “Something flashes and stops working.” At this point the system knows there is a symptom but not which device. The responsible next action is to ask what is flashing, not show a repair price or choose an article at random.

Message two: “It’s my laptop.” This answers the device question but does not settle whether the screen, power light or another component flashes. The receptionist should acknowledge the answer and ask a targeted follow-up: “Does it switch off completely, freeze, or show an error?”

Message three: “The screen flashes and the laptop switches off.” The staff handover should show a laptop, screen flashing and unexpected shutdown in the same draft. Nothing in those messages proves a faulty battery or display. A technician still needs to assess the equipment.

A correction checklist for real conversations

Record the initial problem separately from the object or device involved. “Won’t power on” can remain relevant when “laptop” is corrected to “desktop”; do not erase the symptom because the device changed.

When the customer says “actually”, look for the specific fact being corrected. Replace only that fact. Show the corrected summary back to the customer before the request is submitted, especially where parts, service locations or appointments could be affected.

Give the customer an explicit option to start a separate enquiry. Without it, unrelated follow-up questions can contaminate the original problem and confuse the technician.