An AI receptionist for appointment businesses: start with missed calls

The idea in one minute

A customer calls to book an air-conditioner repair while staff are busy. The proposed assistant answers an incoming enquiry, asks a few useful questions and prepares a request for the person responsible. It confirms a booking only after the scheduling system returns success. Until then, it calls the request pending. This is a proposed experiment, with no claimed customer deployment or measured result.

A market signal, with an unanswered question

The Y Combinator profile of Retell AI establishes an existing company building business voice agents. It is a research signal, not evidence that a particular Vietnamese service business will buy. Ask how many useful calls are missed, whether callers accept an AI conversation and whether owners value the result enough to pay. Funding or vendor marketing cannot answer those local questions.

Choose a narrow first customer

Start with one repair team, one service area, a small service catalogue and one scheduling owner. Interview the owner and staff before selecting software. Review aggregated missed-call records for a week without collecting private conversation content. If customers mostly message the business, test a form or chat assistant first. The product should follow the channel customers already use.

An example conversation

A caller asks: “My AC is not cooling. Can someone come tomorrow afternoon?” The assistant asks for the area, problem type, contact method and preferred time. It reads the details back and creates a pending request. For an exact repair price, it uses an approved fee list or explains that a technician must assess the job. A human request triggers a handoff or a callback request if nobody answers.

Test demand before programming

In week one, simulate the workflow with a person and a request template. Count eligible enquiries, missing details, callbacks and staff handling time. Then try around 20 synthetic calls: fast speech, changed times, local accents, unsupported areas and human requests. This suggested sample is for finding failures, not a representative market study. Invite real callers only with a clear introduction and a usable route to staff.

Build the first MVP

First define services, opening hours and questions the assistant cannot decide. Next create a request with required fields and a pending state. Connect a voice channel, test calendar and staff inbox. Test corrections, network failures and unavailable staff. Retell’s call-transfer documentation describes handoff to another phone number; verify it with the chosen provider and actual configuration.

Technical view: prevent duplicate bookings

Separate language interpretation from permitted actions. The backend checks service area, opening hours and availability using explicit rules. Give each request an idempotency key so retries reuse the same identity. Enforce booking conflicts on the server rather than trusting generated prose. Announce confirmation only with a booking ID. Keep a staff-visible summary and status; decide whether audio retention is needed rather than recording everything by default.

Costs and an initial offer

Budget separately for phone numbers and minutes, voice/model processing, hosting, calendar integration, monitoring and staff review. Do not promise lower cost than an employee without volume and operating evidence. A proposed initial offer covers one location and one workflow, with a weekly report of usable requests. Explore willingness to pay first and price after estimating cost per correctly handled request. This is a business-model hypothesis.

Decide whether to continue

A usable request has correct details, a clear status for the caller and enough information for staff. Track wrong dates, false confirmations and failed handoffs. Prevent duplicate bookings before live testing. Compare total staff effort with the existing process, not just conversation length. If callers abandon the flow or staff rebuild most requests, narrow the scope or switch channels. A natural-sounding demo is insufficient evidence to expand.

Next step

For a similar process, start with an AI opportunity assessment to define scope and evaluation criteria. Once inputs, outputs and review are clear, explore AI MVP delivery for a prototype you can evaluate.

Sources and research boundary

Primary sources checked on 10 October 2026. Scenarios, sample sizes, architecture and business ideas are editorial proposals. No benchmark or customer outcome is claimed.

Y Combinator — Retell AI

Retell — Call transfer