Home/Systems/Voice AI agent
OP-04 · AI WORKFORCE · REPLACES HOLD MUSIC

Voice AI agent: it answers, understands, and acts.

A voice AI agent for customer support is a system that answers the phone, understands what the caller is asking in real time, and does what a support rep would do next: verify the caller, find the answer, log the call, hand off when it should. The version Paul Rahme built at the marina-software client is The AI phone support agent built for a US marina-management product. It answers from the documentation only, creates a Zendesk ticket for every verified call, files GitHub issues for the bugs and gaps it hears, and transfers to a live agent with a note when a person is needed.

On production calls at the client Every verified call becomes a Zendesk ticket Docs only it does not invent answers
Book the Automation Audit → Watch the scale model ↓ Free · 30 minutes · you leave with a written Automation Map

Scale model of the system

voice.agent — scale model

Scale model of the voice agent: a caller is verified, the question answered from documentation, a ticket logged, and the call handed off when judgment is needed.

THE GRIND IT REPLACES

Why the phone line is the queue nobody gets to

Every support team has a phone number, and the phone is the channel that scales worst. A ticket can wait; a ringing phone cannot. Someone stops what they are doing, asks who is calling, finds the account, and answers a question that is already written in the documentation. Ten minutes later it rings again.

The cost is the interruption tax on people who could be fixing the product, hold music for callers outside the hours a small team covers, and calls nobody logs because nobody had a hand free. Bugs reported by phone vanish. Feature requests vanish. The alternatives are worse: a phone tree callers hate, or another hire reading the manual aloud.

WHAT THE SYSTEM DOES

An AI receptionist that verifies callers and creates tickets

Answers every support call, greets the caller, and confirms the need.
Verifies the caller: phone number first, then email or company or marina name.
Classifies the request: how-to question, known issue, missing documentation, or feature request.
Answers from the product documentation, in plain language.
Creates a Zendesk ticket for every verified call.
Files GitHub issues for bugs, feature requests, and documentation gaps.
Transfers to a live agent when needed, with a note, and handles interruptions along the way.
Does not make up answers: if it is not in the documentation, it says so.
Does not touch account changes, billing, or refunds; those are transferred, every time.
HOW IT WORKS

From ring to logged ticket, step by step

One call, one pass through the same flow. The agent listens in real time, decides what kind of request it is hearing, and takes only the actions it is allowed to take for a caller it has verified.

01

Answer and confirm

The agent picks up, greets the caller, and restates the need in one line so the caller can correct it before anything else happens.

02

Verify the caller

Phone number first, then an email address or the company or marina name. Until this passes, the agent helps in conversation but creates and promises nothing.

03

Classify the request

Real-time intent handling sorts the call into one of four types: how-to, known issue, missing documentation, feature request. Billing, refunds, and account changes go straight to transfer.

04

Answer from the documentation

The agent looks the answer up in the product documentation and explains it in plain language. Interruptions are handled; the caller can jump in, ask again, or change direction.

05

Log everything

A Zendesk ticket is created for every verified call. If the call surfaced a bug, a feature request, or a gap in the docs, a GitHub issue is filed automatically.

06

Transfer or close

When a person is needed, the agent transfers to a live agent and leaves a note: who called, how they were verified, what was said. Otherwise it confirms what was done and closes politely.

UNDER THE HOOD

What the voice agent is built from: voice, caller verification, Zendesk ticketing, GitHub issues

A voice layer in front of the same discipline as Aldenebai's text support agent. Speech in and out in real time, an LLM with guardrails for understanding and answers, and the tools you already run holding the state. No side system to reconcile.

LLM + GUARDRAILSZENDESKGITHUBDOCS RETRIEVALTELEPHONY
ORCHESTRATION
A fixed call flow: confirm, verify, classify, answer, log, transfer or close. The model fills the conversation; it does not choose the steps.
MODELS
An LLM with guardrails for real-time understanding, intent handling, and plain-language answers.
KNOWLEDGE
product documentation, and only that. Nothing outside the docs is presented as fact.
GUARDRAILS
Verification gates every write. No ticket, promise, or log for an unverified caller. Billing, refunds, and account changes are transfer-only.
INTEGRATIONS
Zendesk for the ticket on every verified call; GitHub for issues on bugs, feature requests, and documentation gaps; live-agent transfer with a hand-off note.
OBSERVABILITY
Every call ends as a ticket, so the audit trail is your existing queue. Mis-heard details and dropped transfers are tracked as known failure modes.
DATA & SECURITY
Model calls run through your own AWS account (Bedrock), so your data is not used to train provider models and Aldenebai holds no keys. Ticket content and the audit trail stay in your systems; PII is redacted before model calls where required; retention is set by you.
WORKS WITH
In production on a marina-software support line with Zendesk ticketing and GitHub issues. The same agent can be wired to Freshdesk or HubSpot, Jira or Linear, and any telephony provider that exposes a real-time audio stream.
RUNS ON
Your infrastructure, under your access controls.
GUARDRAILS & THE HUMAN IN THE LOOP

How it knows when to stop talking and transfer

The agent has a short list of allowed actions: greet, verify, classify, answer from the docs, log, transfer. It cannot promise a refund, change an account, or state anything the documentation does not support. Ask for one of those and it hands you to a live agent with a note rather than improvising. Fail verification and it stays helpful in conversation but writes nothing on your behalf. These rules live in the flow, not in the model's judgment on the day.

It also says what goes wrong. Spelling an email aloud is sometimes mis-heard, one reason the phone number comes first. Very rarely, a transfer drops during hand-off. Both were found in live testing and are monitored in production. A system you can trust is one whose failure modes you can name.

Docs only. No answer the documentation does not support.
Verify before write. Tickets and logging only for verified callers.
Transfer-only topics. Account changes, billing, and refunds always go to a person.
Hand-off note. Every transfer carries who called, how they were verified, what they asked.
Named limitations. Mis-heard spellings and rare dropped transfers are tracked, not denied.
STATUS

Where the voice agent stands: on production calls, around 100 a month

Live
on the client's support line; 8/10 readiness at the pre-launch review
Every
verified call logged as a Zendesk ticket
4
request types handled end to end

The voice agent answers around 100 calls a month on the client's support line, a rounded monthly average from production; resolution and transfer figures are not yet published. The two known limitations, found in live testing and still monitored, are on the case study.

WHO THIS IS FOR

Support teams whose phone still rings

Product companies with a support line and documentation good enough to answer from. If most of what your phone team says is already written down, and the rest is logging and routing, this is the job the agent takes. You need a ticketing tool (the voice agent writes to Zendesk), a place to file issues (GitHub), and documentation the agent may answer from. The first 30 days go on mapping your call types to the four categories, wiring verification to your customer records, and running the flow in live testing before it takes the line. That is the order the voice agent followed at the client.

B2B SAASMARINA SOFTWAREVERTICAL SOFTWARE
Not sure your calls fit?
The Automation Audit maps your call types, verification rules, and hand-off cases — and tells you plainly which calls a machine should take.
Book the Automation Audit →

Questions support leads ask about AI phone agents

What is a voice AI agent for customer support, and how is it different from an IVR?

An IVR plays a menu and routes by keypad. A voice AI agent for customer support holds a real conversation: it listens in real time, works out the intent, verifies the caller, answers from your documentation, and logs the call in your ticketing tool. The agent Paul Rahme built at a US marina-software company, does all of that before a person is involved.

How does the AI phone support agent verify a caller before doing anything?

It asks for the phone number first, then confirms with an email address or the company or marina name. Only a verified caller gets a Zendesk ticket or a promise that something will be logged. An unverified caller is still helped in conversation, but nothing is written to your systems on their behalf.

What happens when the caller asks something the documentation does not cover?

The agent says so instead of guessing. It answers only from the product documentation, so a missing answer becomes a documentation-gap issue in GitHub, and the call is still logged in Zendesk for a human to follow up. Every gap it hits is recorded, so the docs improve with each call.

Which calls does it refuse to handle on its own?

Account changes, billing, and refunds. Those are transferred to a live agent every time, with a note on what the caller already said so nobody repeats themselves. Anything outside how-to questions, known issues, missing documentation, and feature requests is a hand-off, not an improvisation.

Is a voice AI agent reliable enough for production support calls?

The voice agent is on production calls at the client. Before go-live the full support-call flow was validated in live testing and scored 8/10 on readiness, and the two known limitations are named rather than hidden: an email spelled aloud is sometimes mis-heard, and very rarely a transfer drops during hand-off. Both are monitored. The known limitations are on the record: spelling an email aloud is sometimes mis-heard, and very rarely a transfer drops during hand-off. Both are monitored, not hidden.

Let the phone answer itself.

The free Automation Audit maps your call volume, verification rules, and hand-off cases — and tells you plainly which calls a machine should take. 30 minutes, written Automation Map included.

Audit: free, 30 min →