Every AI receptionist vendor shows the same slide: a grid of logos. Calendars, CRMs, schedulers, accounting software, helpdesk tools, sometimes forty of them.
The slide is nearly useless. It tells you which partnerships exist, not what will work on your account. And integration is the part of this product category where the gap between the demo and the deployment is widest — which is why it deserves its own guide rather than a bullet point.
Do you actually need integration?
Start here, because a surprising number of businesses don't.
There are two very different products in this category, and vendors are often vague about which one they are selling.
A message-taking assistant answers the call, gathers the caller's details, and sends you a notification. It requires no connection to anything. It is a voicemail system with better manners. If your business genuinely cannot be booked automatically — a law firm that assesses matters before scheduling, a contractor who quotes in person — this may be exactly right, and it is cheap to run.
A booking assistant reads your live availability, places the appointment, confirms it, and writes the record back into your system. This is the product most buyers think they are purchasing. It cannot exist without integration, because "available" and "booked" are facts that live in your calendar and CRM, not in the assistant's head.
Ask any vendor which of those two you are getting. The honest ones will tell you plainly, and several will tell you that part of your workflow can only be the first.
The only three connection types that exist
Strip away the branding and every integration claim reduces to one of three things.
1. Calendar and scheduling. The assistant checks real availability and creates, moves or cancels events. This is what makes booking work, and it is the single most valuable connection for most service businesses. Where calendars are standard and well documented, this is the most reliable category of integration to build.
2. CRM and records. The assistant reads existing customer records and writes back what it learns — who called, what they wanted, what was agreed. This is what stops the assistant becoming a separate silo you have to check alongside everything else.
3. Custom business systems, via API or webhook. When the software you run is industry-specific — a dispatch platform, a practice-management system, an order-management system — the connection is bespoke. An API call or a webhook fires when the call ends, and your system does something with it. This is where nearly all the engineering effort and nearly all the project risk lives.
If a vendor describes an integration that does not fit one of those three, ask what it actually connects to. There is no fourth category.
What this looks like in practice
OrdrNow connects directly to Google Calendar, and reaches most other systems through workflow automation — n8n, Make, Zapier and ActivePieces — or a direct API. Custom integrations are available on Enterprise plans.
It is worth being equally clear about what is not available, because most vendors in this category are not: there is no native ServiceTitan or Housecall Pro connector, no Shopify or WooCommerce order lookup, no EHR synchronisation and no property-management-system booking. Those are not built. The honest positive statement is this — if a system is reachable from a workflow platform, or exposes an API, we can usually connect to it. If it is closed and has no connector, that is a custom build we will scope rather than a feature we will pretend to have.
Being told "no" is more useful than being told "yes, we support everything," because it lets you plan. If your workflow depends on a dispatch platform writing tickets, the honest answer is that this is a custom integration project — which may well be worth doing, and which you should scope as a project rather than assume as a feature.
What an integration actually has to do
It helps to know what you are asking for, because "integration" hides a surprising amount of work.
For a booking assistant to place an appointment it must, on every call:
- Authenticate to your system without a human in the loop.
- Read availability for the right person, service and duration — not just "is the slot free" but "is the right technician free for the right job length."
- Write the booking and handle the response, including the failure cases — slot taken, double-booked, rule violated.
- Confirm to the caller only after the write succeeded. This one matters more than it looks: an assistant that says "you're booked" before the record exists creates a customer who believes they have an appointment you know nothing about.
- Write the record to the CRM, so the call exists outside the assistant's own memory.
- Recover gracefully when any of the above fails — offer a callback, escalate to a human, or at minimum take a message.
Most integration disappointments trace to steps 3, 4 or 6, not to the connection itself. Reading availability is easy. Correctly handling the world changing mid-call is the hard part.
What integration really costs
The subscription is not the cost. Industry estimates put a custom integration build at roughly $2,000 to $15,000 and 20 to 40 engineering hours, with the range driven largely by how well documented the target system is. Ongoing monitoring and tuning is commonly quoted at a fraction of the licence cost each year, and some analyses put realistic monitoring at the equivalent of a part-time role. Data preparation alone is sometimes described as consuming the majority of implementation effort.
Treat those as estimates from vendor-adjacent analyses rather than audited figures — the spread is wide because the work varies enormously. The point is simply that a $199/month product can carry a several-thousand-dollar implementation behind it, and any vendor who implies otherwise is either simplifying or has never done a bespoke build.
The honest way to think about it: the subscription buys the assistant, and the integration is a small project with its own budget, timeline and failure modes.
How to test an integration claim
This is the part worth screenshotting.
Ask for a live demonstration of your exact action on your exact system. Not a video, not a sandbox, not a different platform because yours is not supported. If the vendor cannot show the specific action on the specific system, the integration does not exist for you yet.
Then ask these:
- Who builds it, and who maintains it when the target system changes an API? Software you integrate with changes. Somebody has to notice and fix it.
- What happens when a booking fails mid-call? Listen for a specific answer. "It handles it" is not one.
- Does the assistant confirm before or after writing the record? After is correct.
- Is the integration included, or billed separately? Ask for the number.
- What is the fallback if the connection is down? Ideally: take the details and alert a human, rather than telling the caller everything is fine.
- Which integrations do you not have? Vendors with a real product answer this immediately. Hesitation is the answer.
The short version
Integration is not a feature list. It is the difference between an assistant that talks about your business and one that does things in it.
Decide which of the two products you need, place every claim into one of the three real connection types, insist on a live demonstration of your own action, and get the failure behaviour in writing. A vendor that answers all of that plainly is worth more than one with a longer logo wall.
You can hear what a booking call actually sounds like in our live plumbing demo — and if you want the wider picture of what a deployment involves, from discovery to go-live, see what to expect when you get an AI receptionist. For how a voice assistant works alongside the phone number you already have, see will AI voice work with my existing phone system.