An AI Receptionist For Inbound Customers
AI Front Office is the receptionist for visitors of a tenant's business — over chat, SMS, and voice. It checks service-area coverage, matches the request to the service catalog, finds the next available window, and creates a booking that goes to dispatcher review. Pre-booking questions are answered from the tenant's own knowledge base — never invented.
Why Inbound Customer Intake Breaks — And What The Receptionist Fixes First
Field-service and home-services dispatchers lose hours every day to inbound calls that follow the same five-step script. AI Front Office runs that script faithfully — and escalates the moment the conversation needs a human.
Calls Outside Business Hours Go To Voicemail (And Customers To Competitors)
A burst pipe at 9pm goes to the company that picks up. If the answer is a voicemail prompt and a callback in the morning, the customer is already calling the next name on the search results page. The first response wins the job.
Dispatchers Spend All Day On The Same Five Questions
"Do you service my area?" "Do you work on Trane?" "What's the diagnostic fee?" "Is anyone available today?" "Are you licensed in Texas?" — every dispatcher in the country gets the same script every morning, and it eats the hours that should be spent on actual scheduling.
Prices Get Quoted That Should Never Have Been Quoted
A new CSR sees a request, eyeballs a number, and quotes it — sight unseen. The truck rolls, the real diagnosis is different, and the customer is anchored on the bad number. The receptionist never quotes an exact price. Price RANGE plus trip charge — always.
After-Hours Bookings Land Without Triage And Wreck The Morning
A web form takes a request, drops it in an inbox, and the dispatcher has to triage 20 of them at 7am before the first truck moves. Every one of them needs a callback to confirm the details that should have been captured the first time.
Out-Of-Area Requests Eat An Hour Before Anyone Says No
Half the calls are addresses you don't actually cover, but nobody catches it until the dispatcher pulls up the map mid-conversation. By then you've taken the contact info, asked the diagnostic questions, and built a customer's hope — and the polite "we don't service that zip" feels like a bait-and-switch. The receptionist verifies coverage before it offers a slot.
New CSRs Take Weeks To Run The Intake Script Right
Every new hire learns the same five-question script by listening to recordings and getting corrected for a month. In the meantime, calls get fumbled — the wrong service type goes in, the trip charge isn't disclosed, the licensing question gets a shrug. The receptionist runs day-one with the catalog, the coverage map, and the KB already loaded.
AI Front Office At A Glance
AI Front Office Receptionist
Greets, qualifies, books appointments, and routes to a human dispatcher when needed.
Inside AI Front Office — The Actual Capabilities
Every block below maps to a real tool the receptionist uses against your service catalog, coverage map, calendar, and authored knowledge base. The agent never confirms a final appointment — booking enters a pending_review state for a human dispatcher.
Qualify The Visitor Before You Quote Anything
The receptionist runs through the same intake the best dispatcher would — identify the customer, confirm the address is in coverage, match the free-text request to a real service in the catalog, and pull pricing as a range (never an exact quote). All before the agent proposes a window.
- Look up returning customers — lookup_customer by phone, email, or address; phone is normalized to E.164.
- Verify service area before offering a slot — lookup_service_area by address or lat/lng; out-of-area requests escalate instead of auto-booking.
- Match free-text requests to the catalog — lookup_service_catalog turns "AC isn't cooling" into the right service_type_key with display name and price range.
- Price as a RANGE, never an exact quote — the catalog returns a range and trip-charge cents; the agent quotes neither tighter nor looser than that.
Answer Pre-Booking Questions From The Tenant's Own Knowledge Base
Visitors ask all sorts of things before they'll book — "do you service Trane?", "are you licensed in this state?", "do you offer financing?", "what's your warranty?". The agent searches the tenant's authored knowledge base — FAQ articles, uploaded PDFs and Word docs, and auto-transcribed videos — and cites the source it used. If the KB has nothing, the agent does not invent an answer.
- Search the authored KB — lookup_knowledge_base covers FAQ entries, uploaded documents, and transcribed video content.
- Each result carries a source_label — "FAQ" / "document" / "video" — so the agent can cite the source in its reply.
- Gated by ai_front_office_kb_enabled — tenants without an authored KB simply don't see the tool.
- No hallucination — if no relevant entry comes back, the agent asks a clarifying question or escalates instead of guessing.
Propose A Real Window, Then Hand The Booking To A Human
Once the service is matched and the area is confirmed, the agent pulls up to three real windows from the calendar and lets the visitor pick. A BookingRequest is created in pending_review — visible to the dispatcher, not yet a confirmed appointment. Idempotency keys make retries safe.
- Pull real windows — lookup_next_available_window returns up to 3 windows; the agent never invents a slot.
- Booking enters dispatcher review — create_booking_request writes a pending_review record; the human owns the final confirmation.
- Idempotency-keyed writes — every booking call carries an idempotency_key so a retry or duplicate turn doesn't double-book.
- Captures everything the dispatcher needs — service type, urgency, address, phone, name, requested window, returning-customer id when applicable.
Escalate To A Human The Moment The Conversation Should Leave The Agent
The agent doesn't try to save every conversation. If the request is out of scope, the catalog returned no match, the visitor explicitly asks for a person, or any tool returned an error, the agent marks the conversation awaiting_dispatcher and notifies on-call. The dispatcher inherits the full thread plus a one-paragraph summary.
- Seven explicit escalation reasons — out_of_service_area, no_availability, customer_request, tool_error, sla_at_risk, sensitive_topic, other.
- One-paragraph summary required — dispatcher gets context, not just a transcript.
- Full thread inherited — every visitor turn, every tool call, every agent reply is on the record when the human picks it up.
- On-call dispatchers paged — escalations route through the configured on-call channel, not a generic inbox.
Outcomes Teams Can Measure
The receptionist's job is to win the first response, take qualified bookings out of the dispatcher's morning, and never quote a price the truck can't honor. Measure against your pre-agent baseline so the team can see what the receptionist absorbed and where dispatchers are still doing intake work.
- After-hours capture rate — bookings created outside business hours that would previously have hit voicemail.
- First-response time — seconds from inbound message to first agent reply; the metric customers actually feel.
- Qualified-booking rate — share of bookings where service area, catalog match, and window were all confirmed before the dispatcher touched the record.
- Dispatcher-touch rate per booking — average dispatcher minutes per inbound booking, vs the pre-agent baseline.
- Escalation reason mix — what's reaching dispatchers (and which reasons are the real bottlenecks worth fixing in the catalog or KB).
Two Writes, Both State-Only · No Auto-Confirmed Appointments
AI Front Office's RISKY_TOOLS list is empty by design. The agent has two write-shaped tools — create_booking_request and escalate_to_dispatcher — and both are state-only. The booking enters pending_review for a human dispatcher; the escalation just marks the conversation. Nothing is auto-confirmed, nothing is auto-charged, no truck is auto-dispatched.
- RISKY_TOOLS is empty — create_booking_request writes a pending_review record; escalate_to_dispatcher is state-only with no destructive action.
- Price range, never an exact quote — the catalog returns a range; the agent quotes within that range and discloses the trip charge.
- Scoped to a single intake conversation — the receptionist is invoked by AiFrontOffice::ReceptionistService and the voice webhook; it is intentionally NOT registered in DOMAIN_MODULES for cross-app routing.
- Audit trail on every turn — visitor message, tool call, agent reply, escalation reason, and dispatcher handoff are all captured on the IntakeConversation record.
WHAT TEAMS TRY INSTEAD
The four alternatives — and why none of them know your service area, your catalog, or your dispatcher
Field-service operators usually try one of these four before considering an embedded receptionist. None survive the first real intake — none of them check coverage, quote a real catalog range, or hand off cleanly.
Pasting inbound requests into ChatGPT, Claude, or Copilot
General-purpose AI doing one-shot replies to copied customer messages
- The receptionist runs the actual five-step intake — coverage check, catalog match, price range, real window — instead of generating polite prose
- Reads the tenant's catalog and coverage polygon directly, so it knows when to say "we don't service that zip" before booking hope
- Writes a real <code>BookingRequest</code> in <code>pending_review</code>; a generic chatbot can't create a structured record the dispatcher inherits
Dialpad AI / Hyro / Ada
Vendor-trapped voice-bots that live in the phone system silo
- Sees the same service catalog, coverage map, and calendar that dispatchers and field techs use — no parallel knowledge graph to sync
- One agent across chat, SMS, and voice — not three separate vendors with three separate logs and three separate KBs
- Pricing comes from the catalog as a real range plus trip charge, not from prompts a contact-center admin tuned by hand
A custom intake bot built on the web form
An engineering team's six-month build, then forever maintenance
- Shipped already. Engineering spends zero weeks plumbing identity, KB grounding, idempotency keys, or escalation routing
- Gets the seven explicit escalation reasons, on-call paging, and conversation audit trail for free — most DIY builds plateau at "create a row"
- Inherits new tools and capability tiers without redeployment as the platform evolves
The manual fallback — voicemail and a callback in the morning
The default when the dispatcher is on another call
- Picks up at 9pm when a burst pipe is calling, not at 8am after the customer already called the next name on the results page
- Runs the same intake script the senior dispatcher would run — day one, no training tail
- Out-of-area requests escalate before the 45-minute callback eats the morning
PLATFORM LEVERAGE
AI Front Office inherits everything the platform already runs
A standalone receptionist bot has to plumb each of these. AI Front Office gets them for free because Field Service, Bookings, and Libraries already do.
Cross-app data plane
Reads the Field Service catalog, the coverage polygons, the Bookings calendar, and the Libraries KB to run a real intake — not just a polite reply.
Unified permission model
Visitors are not platform users — the receptionist runs in an unauthenticated boundary with explicit scopes, and dispatcher handoff respects on-call and routing rules already configured.
Audit trail on every turn
Visitor message, every tool call, agent reply, escalation reason, and dispatcher handoff all live on the IntakeConversation record with the same retention as the rest of the platform.
Translation in 100+ languages
A Spanish-speaking caller gets a Spanish intake — and the dispatcher inherits an English summary. The same translation service that powers Chat and SOPs powers the receptionist.
Mobile delivery for on-call dispatch
Escalations and pending-review bookings page the on-call dispatcher inside the same mobile app they already use for jobs and timesheets — not a separate paging vendor.
RubyLLM-grounded model tiering
Catalog lookups and address normalization run on cheap nano/small models; full intake reasoning uses standard tier — automatically, per call.
INDUSTRY FIT
Industries where an AI receptionist absorbs the most dispatcher time
AI Front Office helps wherever inbound customer intake bottlenecks at the front desk.
HVAC & Plumbing
A burst pipe at 9pm books a morning window without waking the on-call dispatcher. The catalog returns a diagnostic-fee range, not a fake flat quote.
Electrical & Solar
Licensing questions ("are you licensed in Texas?") get answered from the KB with a citation instead of a "let me check and call you back."
Pest Control
Recurring-treatment customers get matched by phone or address; first-time callers run through the five-step intake before a window is offered.
Appliance & Garage Door Repair
Brand-specific questions ("do you work on Trane?", "do you service LiftMaster?") get KB-grounded answers with a source label, not invented brand coverage.
Cleaning & Restoration
After-hours water-damage calls get qualified, geo-checked, and booked into pending review before the morning triage queue forms.
Property Management & HOA Vendors
Tenant intake runs in the tenant's language, captures unit number and access notes, and hands a structured ticket to the on-call vendor.
WHY MANGOAPPS WINS
An embedded agent beats a chatbot, a vendor add-on, or a custom build on every axis
The argument finance, security, IT, and ops all share — and the one a generic chatbot or a single-channel voice-bot structurally cannot answer.
Cheaper than the alternatives
No per-seat ChatGPT license, no Dialpad AI / Hyro / Ada contract, no six-month custom intake build, no overnight answering-service retainer.
More secure
Visitors run in an unauthenticated scope; every tool call is logged to AiApiLog and the IntakeConversation record. Nothing leaves the tenant boundary — and no separate AI vendor has your customer list.
Easier to deploy
Already deployed if you have Field Service and Bookings enabled. Turn the receptionist on, point it at the catalog and coverage polygons, and it's running the same day.
Easier to use
Visitors get one experience across chat, SMS, and voice — and dispatchers get one inbox of pending-review bookings and escalations instead of three vendor consoles.
Easier to manage
KB toggle, voice toggle, and escalation routing all sit in the same admin console as every other app. One audit log, one access model.
Easier to extend
Shares the agentic tool framework with every other MangoApps agent. A new intake question (badge required? gate code?) ships as a tool, not a prompt rewrite.
AI is actually better
A vendor voice-bot can read a script. Only AI Front Office can also check whether the address falls inside today's coverage polygon, match the request to a real catalog SKU, find a real window, and hand a structured booking to the on-call dispatcher.
At our head office within HR, marketing, and finance, we use ChatGPT quite a bit, and MangoApps AI Helper is a useful tool for us. As I go around to the stores, I’ve been showing them how the AI Intranet Helper can find things and answer plain language questions about our resources, and they’re quite excited about that.
Alison van Zijl
Head of Human Resources
Full House
Customer Success
Related Customer Stories
Customer Case Studies
Customer Case Studies
Customer Case Studies
Customer Case Studies
Customer Case Studies
Customer Case Studies
Frequently Asked Questions About AI Front Office
Seven tools across the intake conversation — lookup_customer (returning-customer match by phone/email/address), lookup_service_area (in-coverage check), lookup_service_catalog (match a free-text request to a service type and price range), lookup_next_available_window (up to 3 real windows from the calendar), lookup_knowledge_base (search FAQ + uploaded docs + transcribed videos for pre-booking questions), create_booking_request (booking enters pending_review), and escalate_to_dispatcher with one of seven explicit reasons.
No on both counts. Pricing is a RANGE returned by the catalog plus an explicit trip-charge figure — the agent is forbidden to tighten the range into an exact quote. Bookings are written as pending_review records; a human dispatcher owns the final confirmation. The dispatcher's review IS the human-approval gate.
The agent asks a clarifying question or escalates with reason other / sensitive_topic. It does not invent an answer. lookup_knowledge_base is also gated by the ai_front_office_kb_enabled tenant config — tenants without an authored KB simply don't see the tool, and the agent won't reach for it.
Seven explicit escalation reasons drive escalate_to_dispatcher — out_of_service_area (catalog/coverage miss), no_availability (calendar returned nothing), customer_request (visitor asked for a human), tool_error (any tool failed), sla_at_risk (urgency the agent shouldn't handle solo), sensitive_topic, and other. Each escalation includes a one-paragraph summary plus the full conversation transcript.
AI Front Office is deliberately NOT registered in Agents::ToolRegistry::DOMAIN_MODULES. It is invoked directly by AiFrontOffice::ReceptionistService (chat/SMS) and Hooks::VapiController#handle_function_call (voice). Its tools are scoped to a single unauthenticated intake conversation and must never be exposed to authenticated agents or the cross-app router.
Let's Talk
Since 2008, we've been building the workforce platform — earning the trust of 2 million+ users and an NPS of 78.
Why Choose Us?
- AI-Powered Platform: The most unified workforce experience on the planet.
- Top Security: HITRUST, ISO & SOC 2 certified.
- Exceptional UX: Delightful on mobile and desktop.
- Proven Results: 98% customer retention rate.
Trusted by Legendary Companies:
