How does an AI receptionist work for a trade business?

An AI receptionist for a trade business answers a routed work call, uses the business's instructions to guide the conversation, captures the customer's details, and hands the owner a structured record for review.

The useful versions do not pretend to run the whole business. They have a defined route into the call, a narrow set of allowed outcomes, and a clear way to stop when information or authority is missing.

The call must reach the service

The first step is telephony, not AI. The customer calls a dedicated number or the business forwards an eligible call to the answering service.

That routing should be visible and testable. The owner needs to know which calls are handled, how long their own phone rings first, and how to turn forwarding off.

An app cannot silently intercept ordinary mobile calls. Existing-number handling depends on carrier forwarding, telephony routing, or another explicit connection.

Business context sets the boundaries

Before the first live call, the business needs to define what the receptionist can say and do. Useful context includes:

• business name and service area;
• supported and excluded work;
• working hours and escalation rules;
• terms the business uses with customers;
• details required before an owner callback;
• commitments the receptionist must not make.

This context should be versioned. A call needs a record of the instructions that governed it, especially when the business later changes its services or policy.

Conversation turns speech into confirmed facts

A caller does not speak in database fields. They may give their name, address, problem, and timing in one sentence, interrupt a question, pause, or correct an earlier detail.

The receptionist needs to recognise confirmed facts and ask only for what is missing. It should summarise the important details before ending rather than treating every spoken phrase as equally reliable.

Natural conversation still has boundaries. A fluent voice is not authority to quote a price, guarantee attendance, accept unsupported work, or give dangerous technical advice.

Structured output makes the call useful

After the conversation, the system converts confirmed details into a defined job-card shape. Typical fields include the customer, callback number, reported problem, location, timing, and review reasons.

Validation matters here. Free text may be readable but still omit the address or mix an uncertain statement into a confirmed field. A strict structure lets the product reject an invalid result or mark it for review.

The system must also handle repeated provider events. One call should create at most one job card, even when a webhook or terminal event is delivered again.

The owner reviews the handover

The job card is a starting point for the owner, not an autonomous booking. The owner checks the details, resolves uncertainty, decides whether the work fits, and makes any price or attendance commitment.

Where a transcript is lawfully retained, it can support that review. Retention, deletion, access, and recording notice still need explicit policy and technical controls.

Failure needs its own path

Calls do not always complete cleanly. The caller may stay silent, hang up, lose signal, or reach the service while a provider is unavailable.

A controlled system uses bounded retries, keeps confirmed details where lawful and useful, and closes honestly when it cannot continue. It does not trap the caller or present a partial record as complete.

How Max & Mia is designed

Max & Mia provides an assigned number. Customers can call it directly, or the owner can forward selected or all calls from an existing work number. Each call uses a versioned instruction bundle, natural dialogue, strict structured outcomes, and owner review. The target is one job card per call.

It does not currently answer an existing carrier number without explicit routing. Quotes, payments, autonomous booking, diagnosis, and guaranteed arrival times are outside the MVP.

That boundary is the practical difference between an assistant and an unsupervised operator. The assistant gathers and organises the callback context; the tradesperson keeps control of the work.

The on-site call-handling guide turns these boundaries into a testable workflow. The callback-ready details checklist defines the handover the owner should receive.