Why Our AI Receptionist Cannot Book Work or Approve Prices on Its Own

The customer problem behind this workflow

AI can interpret language, but it does not automatically possess the business authority behind a contract. Job availability, diagnosis, payment and private customer records each require checks beyond conversation fluency.

A bad handover can damage trust even if no money changes hands. Saying a booking is confirmed when it is not creates a promise the team never made.

How we designed the YITM workflow

YITM separates understanding the enquiry from executing business actions. Safety rules and authenticated account boundaries run before any model planning. New enquiries remain drafts until the customer reviews and submits them.

A human reviews the proposed service, scope, pricing and availability. Access to previous repairs, invoices or quotes is routed through secure sign-in. The public receptionist should never request passwords or reveal someone else's records.

What we built, tested and learned

The 50-scenario recovery programme explicitly tests requests to mark a booking confirmed, charge a card, disclose another customer's repair details and provide existing-account information. Its synthetic assertions check that protected actions do not happen.

Those are design and regression safeguards. They should be coupled with live acceptance and ongoing operational review; no software test can replace checking the actual authorised booking and payment paths.

What this could improve for YITM and other businesses

YITM can offer a friendly first step while reserving decisions that matter for trained people. For customers, that means fewer false promises and a clearer understanding of what has—and has not—been submitted.

For a local service business, draw a simple boundary: AI can collect and organise information, deterministic code can validate permissions, and named staff confirm commitments.

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.

Questions that require a human decision

Whether a device can be repaired economically depends on diagnosis, parts, condition and customer priorities. Whether a booking slot is available depends on actual scheduling systems. A conversational answer alone cannot establish either fact.

Similarly, a customer asking for help with a family member’s account does not grant permission to disclose that person’s information. The safe workflow is to explain verification or seek the account holder’s consent through the appropriate channel.

What a safe draft looks like

The customer's message can be stored as a proposed request with a clear “not sent” state. The interface should distinguish reviewed published pricing from an individual quote and never label tentative work as confirmed.

A good acceptance test attempts the unsafe shortcut directly—“book me now and charge my card”—then verifies no payment, booking, notification or account change occurred.