The call went well. Did anything actually happen?

An AI voice agent is a software system that handles defined phone conversations: it understands what a caller is asking for in natural speech, answers from information the business has approved, takes an allowed action in a connected system where one applies, and transfers the call to a person when the conversation needs judgement.

Callers describe a situation rather than filling in a form. A voice agent has to take an ordinary sentence and pull out what the request actually is, what constrains it, and what has already gone wrong — then decide what it still needs to ask.

A voice agent answers from a defined set of business information — hours, locations, what services cover, policies, approved answers to common questions, and live availability through a connected system. What it can reach is decided when the workflow is designed, so a call cannot wander into information that was never meant for it.

When a voice agent does not have enough information to act, it can ask a clarifying question, stop short of the action and take the caller’s details instead, or transfer the call to a person. Which of those happens is decided per workflow when the agent is designed — the one behaviour that is never acceptable is filling the gap with something plausible.

Where it is connected, a voice agent can take an allowed action during the call — create a booking in the calendar or booking system, create or update a record in the CRM, log the outcome, or trigger a confirmation message. What it is allowed to do is defined per workflow, and it does not have access to anything beyond that.

A voice agent can answer inbound calls and place outbound ones. Inbound is the straightforward case: somebody rings and the call gets handled. Outbound carries obligations inbound does not — who may be contacted, on what basis, at what times, and how to stop — so outbound workflows are designed around confirmations, reminders and follow-ups to people who are already expecting to hear from you.

A chatbot handles the same kinds of request in text, on a site or in WhatsApp. An IVR routes callers through fixed menu options. A voice agent holds a defined conversation on the phone and can complete the task within it. A person is better whenever the call needs judgement, negotiation or genuine discretion — and most businesses end up using more than one of the four.

When a call ends, what should remain is a record the business can act on: who called, what they wanted, what was done, and what happens next. Where it is configured, that includes a transcript and a summary written back to the customer record, so the next person to speak to them starts from what already happened.

Voice agent scope follows how many different calls it has to handle, how far each one has to go, how many systems it has to reach, whether outbound is involved, how many languages and locations are in play, and what has to be true about privacy, consent and verification for the calls being handled.

These are delivery projects, listed as delivered. What they establish is the kind of system this work sits inside — conversational interfaces, decision flows and the integrations behind them.

What is an AI voice agent?

Software that holds a real phone conversation for a defined job — as opposed to a recording, a menu or a script. The distinction that matters commercially is that it can finish the task, not just route the caller: the booking is made, or the record is updated, during the call.

What can a voice agent actually do on a call?

Within the workflow it was built for: answer known questions, book or reschedule something through the system that holds availability, qualify an enquiry by asking the questions that decide fit, route the call to the right team, and record the outcome. What it is allowed to do is defined when the workflow is designed.

How is this different from an AI chatbot?

The jobs overlap — both can qualify, book and hand off — but the medium does not. A chatbot user can read, scroll back and tap an option. A caller can do none of those, so everything has to be carried in the conversation and the action has to complete while they are still on the line.

How is a voice agent different from IVR?

An IVR is a routing tool and a good one when routing is genuinely all you need. The practical test is whether your callers regularly want something no menu item covers — if they do, they are currently being sent to whoever is least able to say no, which is what a voice agent is for.

Does it replace the people who answer the phone?

What usually changes is the mix rather than the headcount. The calls that vanish are the ones nobody was doing anything interesting with — the same booking, the same opening-hours question — and what remains is the harder half, which is also the half where having a person on the line is worth paying for.

Can it answer inbound calls?

Yes, and it is the most common starting point because the value is easy to see: the calls that currently ring out, go to voicemail or arrive when everybody is already on the phone. Those are the ones a business never finds out it lost.

Can it make outbound calls?

Yes, and the first question is never technical — it is whether you have a lawful basis for calling these particular people, which you generally do for someone with a booking and generally do not for a purchased list. That answer decides whether an outbound workflow is worth designing at all.

Can it book appointments?

Where it is connected to the system that holds availability, yes: it reads what is genuinely open, offers real slots, and creates the booking during the call rather than promising that somebody will call back.

What happens if it does not understand the caller?

It asks a clarifying question, stops short of the action and takes details for a call back, or transfers to a person — whichever the workflow specifies. What it does not do is fill the gap with something plausible.

What happens if information is missing?

The same three designed responses. Missing the branch means asking which branch — not confirming a booking it cannot actually make, and not asking the caller to repeat what they already said.

Can it transfer a call to a person?

Yes. Worth deciding early is who receives them — a queue, a named person, a rota — and what happens when nobody picks up, because an unanswered transfer is a worse outcome than never offering one. That is designed rather than left to the moment.

Can it use our existing business information?

Yes, within a defined boundary set during design. In practice the useful exercise is the opposite one: deciding what it must never say, because most businesses have information sitting in reachable systems that nobody wants read out on a phone call.

Can it connect to our CRM or booking software?

Yes, where an integration is available. It can read allowed customer context, create or update records, and write the call outcome back. Each connection is scoped explicitly, including what happens when that system is unavailable.

What happens if a connected system is down mid-call?

It falls back to something it can still complete — usually taking details for a call back. This is worth specifying per integration rather than in general, because “the calendar is slow” and “the calendar is unreachable” deserve different answers on a live call.

Can calls be recorded or transcribed?

Both can be configured. Treat it as a decision with obligations attached rather than a setting: what has to be announced, what consent looks like for your callers, how long anything is kept and who may listen are established for your jurisdiction and audience before it is switched on.

Does it support multiple languages?

Yes. The part that catches people out is that a language is not one decision — recognising it, speaking it well, and handling a caller who switches mid-sentence are three, and how far each is supported depends on the providers chosen for your deployment.

Can different types of call use different workflows?

Yes, and that is usually how it is built — a booking call, a status question and a complaint are different conversations with different endings, different permissions and different handoff rules.

What determines the size of a voice agent project?

Almost always the number of different calls it has to recognise, rather than anything technical. One intent taken all the way through is a contained build; five is not five times the work but it is closer to that than most people expect, because each one needs its own edge cases and its own testing.

Who owns the system and the call data?

You do. The practical test of that is whether you could take the system to another supplier without asking us for anything, and setting provider accounts up in your name where practical is what makes the answer yes.

What happens after launch?

The first weeks of real calls are the most useful information the project produces, because callers ask for things nobody thought to design for. Acting on that is a separate, explicitly scoped piece of work rather than something assumed into the build.