Business voice assistants: how to build one

Building a business voice assistant means putting together five components, of which only one is what you think about. The part that determines whether it will work is not the model that understands the voice: it is the integrations with the systems that contain the answers.

An assistant disconnected from the data can tell hours and address. A connected assistant can tell where the practice of who is calling is, and the difference is felt by anyone in the first ten seconds.

The Five Components

The last line surprises those who evaluate the project for the first time: the entry is the most obvious and the least decisive piece. Synthetic voices are good everywhere today, and no company has ever failed a stamp project.

The Decisions That Matter

1. What she needs to know how to do, in a short list. Two or three cases, not ten.
2. When he surrenders: after how many misunderstandings it passes to a person.
3. What do you do if nobody's here?: structured message, recalled, other.
4. What data can you read and which ones he can write.
5. How to Identify Who Calls: number, code, verification request.
6. What It Preserves of the conversation and for how long.

Point 5 is what companies face late and that conditions a lot. If the assistant is to give information about a practice, he must know with reasonable certainty who is in front of him. The caller number is the easiest method but is not always reliable, and asking for verification data lengthens the conversation.

Why Tests Are Part of the Project

Everything happens on the phone, and no table analysis predicts it.

• People who say three things in the same sentence
• Calls from noisy or moving environments
• Speakers speaking over the system
• Long silences that the system interprets as end of turn
• Numbers and dates pronounced in different ways
• People who hang up and call back right away

Each of these situations must be tried and managed. It is why a realistic estimate includes weeks of testing, and why projects that promise very short times typically deliver systems that behave badly on first contact with the real world.

Ready or customized

The criterion is the same as AI by subscription or customized: if you just need what the platform already does, use it. If the value lies in the link to your data, you need a project.

Practical examples

Assistant taking messages out of hours. A single use case, no integration, short time. It is the project that I would recommend first to those who have never tried: it costs little and recovers contacts that are lost today.

Assistant connected to case management software. It responds to "where is my request". An integration, identification by caller number with verification. Average complexity, high value if the calls on this topic are many.

Assistant booking and editing. It must read and write on the calendar, handle conflicts, confirm. It is the highest level and must be addressed after seeing the previous ones work.

The Real Times of a Project

The estimates circulating are often optimistic because only development matters. One voice project has four stages and the longest is not the one you imagine.

1. Definition: what he has to do, when he gives up, what he keeps, few meetings, but they have to be done with those who answer the phone today.
2. Integrations: link to the systems that contain the answers. It is the most technically full-bodied part.
3. Construction of flow: the actual conversational logic.
4. Tests with real calls: the phase that is cut and that determines whether it will work.

The fourth stage deserves special attention. It's not about proving that the system works when all goes well, but about finding out what happens when it goes wrong: noise, silences, people talking above, requests out of perimeter. Any abnormal behavior discovered at this stage is an issue that customers will not encounter.

What to ask in the budgeting phase

• Which systems it links to, with proper names
• What happens when he doesn't understand, after how many times
• How he identifies who he calls and what he reveals before he identifies
• How many real test calls are included
• What is stored, where and for how long
• Who intervenes if the system behaves badly, and with what times

These are six questions that distinguish a comparable quote from a generic one. A supplier who responds precisely to all six has already thought about the project; one who responds to three is improvising. The general criterion is in how much does an AI agent cost.

The perimeter of the first version

The mistake I see most often in the definition phase is a list of ten things the assistant should know how to do. The first version should have two.

The reason is not prudence: it is that every case of added use multiplies the combinations to be tested, and problems almost always arise in intersections. A system that handles two good cases is useful from day one; one that handles ten bad cases is shut down after a month.

1. List everything you'd like him to do.
2. Sort by real frequency, not by perceived importance.
3. Take the first two and put the rest away.
4. Release, measure, correct.
5. Add the third only when the first two really work.

Step 2 often reserves surprises: the case that seemed central turns out to be rare, and a trivial request that no one had mentioned is the most frequent of all.

Mistakes to Avoid

• Starting with ten use cases. Two, done right, are worth more.
• Postponing the switchboard verification. It is the presupposition of everything.
• Not defining when it gives up. It is the decision that saves the project.
• Skipping the real tests. The real world is different from the demo.
• Not deciding what it can reveal. Concrete risk of exposing data.
• Investing in voice instead of integrations. Optimizing the wrong piece.

How to apply it in the company

First check if your switchboard can divert calls to an external number: without that, the project has a different size.

Then choose a use case only, the most frequent one, and define on a page what it has to do, when it surrenders and what it retains. With that page in hand the estimates become comparable and the estimates much closer.

The cost framework is in how much does an AI agent cost, the typical errors in mistakes to avoid with voice AI.

Who follows him after release

A voice assistant is not a system that installs and works: it is a system that meets new situations every day and needs to be corrected.

You need a person who once a week, in the first few months, listens to or reads a sample of conversations. Not to check someone, but to see where the system got stuck, what they misunderstand, what requests weren't expected.

1. Look at a sample of negative-result conversations.
2. Write down the recurring reasons for failure.
3. Correct the two or three most frequent.
4. Repeat after a few weeks.

This cycle, repeated three or four times, improves a mediocre system in one that works. Jumping it means letting the system remain as it was on the first day as the world around it changes — which is the typical way these projects degrade, as described in how much it costs to maintain an AI system.

Conclusion

Eighty percent of a voice assistant consists of things unrelated to voice: integrations, logic, handling unexpected events and identifying callers.

Whoever evaluates a project by looking at the naturalness of the voice is looking at the least important piece. Instead, ask what it connects to and what it does when it doesn't understand.: the answers to these two questions predict the outcome better than any demonstration.

If you want to go from testing with ChatGPT to an AI system integrated into business processes, Giallo Studio custom designed agents and automations.

Finally, it should be considered that a voice assistant processes personal data of those who call and produce transcripts: the verifications of GDPR and AI in the company should be closed before activation, not after. It is worth explicitly deciding what you keep — audio, text, or just the outcome — because in most cases the minimum is enough and it simplifies a lot.