AI or Rules? How We Keep Our Virtual Receptionist Practical and Affordable

The customer problem behind this workflow

Uncontrolled AI usage can raise costs, slow answers and create unnecessary risk around published prices or operating hours. A model can also sound certain about a service it has not checked.

Small businesses need reliability and clear limits before they need the largest possible model. The useful question is not “How many AI calls can we make?” but “Which questions genuinely need AI?”

How we designed the YITM workflow

YITM starts with server-side rules and reviewed knowledge for straightforward service questions, published pricing, service areas and access boundaries. More ambiguous wording may move to a governed model request through the existing gateway.

Before any AI-generated interpretation influences the workflow, the response must fit a strict schema, reference the customer’s evidence and stay within budget. When a gateway times out or a response fails validation, the system must continue with clarification or human review instead of inventing a booking or price.

What we built, tested and learned

Our staged tests included model mock timeouts and structured-plan validation. In a bounded real Azure probe, three of five strict EP2 cases passed; two others highlighted the need to distinguish legitimate classification disagreement from unsupported evidence.

The lesson was to improve evidence-grounding and acceptance diagnostics rather than relax the validator just to turn every test green. Separate model tests, acceptance tests and actual production cost data remain essential.

What this could improve for YITM and other businesses

This design is intended to reserve paid interpretation for situations where it adds value, while keeping basic answers available. We have not established a verified percentage cost reduction from production traffic.

A local retailer, repairer or professional service could start with an approved FAQ, a small set of guarded actions and one model-assisted ambiguity path, then measure calls per useful enquiry.

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.

How we would reproduce a customer-facing error

Write down the exact sequence, not merely “the chatbot got confused”: first message, assistant question, second message, subsequent reply and expected outcome. Then reproduce it with the same browser session rules and configuration as the actual website.

Test several distinct failure modes: a rule selecting the wrong service, a validated AI plan containing unsupported evidence, context disappearing between requests, and an expired or disabled feature flag. Each requires a different remedy.

Compound intent: a practical example

“My laptop runs slowly, and Mum’s email has stopped working.” A helpful assistant recognises that the laptop performance problem and the email problem need distinct details. It should not infer they share the same cause.

A concise follow-up could be: “I can note both. Is Mum’s email failing on the same laptop or on another device?” One question can resolve an important relationship without making the customer fill out two lengthy forms.