We have two voice agents in our portfolio built for different jobs: one answers inbound calls for a financial services firm, the other calls customers for a logistics company and collects requests. We already wrote about the economics of voice agents elsewhere. This one is about the process itself — how we scoped the task, what decisions we made along the way, what turned out harder than it looked at the start, and what the client ended up seeing on the dashboard.
Two different jobs under one label
"Voice agent" is a broad label for things that work quite differently under the hood. The financial firm's task was inbound: the customer calls in, the agent answers routine questions, and hands the complex ones to an operator. The logistics company's task was outbound as much as inbound: the agent both answers calls and calls people from a list to clarify details or collect a request. Both talk in a natural voice and understand ordinary speech, but the scenarios built into them and the data they work with are different. So even though the projects sit under the same theme, they were put together differently from day one.
Where we started: mapping scenarios and policies
The first step on both projects was not about technology — it was about what actually happens on a call. We work through the call scenarios and the company's policies: what customers ask, what rules operators follow when they answer, where a routine answer ends and an individual case begins. For the support agent, that meant turning the company's policies into a form the agent could actually answer from, without inventing wording of its own. For the calling agent, it meant deciding which fields a conversation absolutely has to fill in for the resulting request to be usable, rather than a string of disconnected phrases.
What comes out of this step is a line: what the agent takes on, and what stays with people. That line gets fixed in the technical spec along with price and timeline before any work starts, with an NDA where needed.
What turned out to be hard in practice
The hard part of either project was never getting the agent to talk — that part is solvable. The hard part is the boundary and the handoff.
For the support agent, it was teaching it to honestly recognise the moment a question falls outside its policies, rather than guessing. An agent that confidently gives a wrong answer to a financial firm's customer is worse than one that admits, in time, that the question is not its to answer and calls in an operator.
For the calling agent, it was keeping one underlying logic for both inbound and outbound calls, with different scenarios inside each, while still producing data in the same structured shape regardless of who started the conversation. A call the customer starts and a call the agent starts read very differently — the record that comes out of either has to be equally usable.
And one principle applied to both: the agent does not pass itself off as a human. It introduces itself as an automated assistant. We treated that as a matter of trust in the client's brand rather than a technical constraint — the pretence gets uncovered quickly and damages the impression more than talking to a machine ever would.
How context reaches the operator
When the support agent hands a call to a person, the conversation history goes with it — what the customer has already said and what the agent already clarified. The customer does not have to repeat everything to an operator who just picked up. For a call centre where patience runs out faster on the second explanation than on the first, this was a requirement from the start of the build, not an option added later.
What went into the dashboard
The two dashboards were built around different questions a manager actually asks. The support agent's dashboard shows calls, topics and load: how many calls came in, what people ask about most, how load is distributed over time. The calling agent's dashboard shows calls, requests and outcomes: how many conversations happened, how many turned into a request, and how each call ended. In both cases the goal is the same — the manager sees the raw picture of what is happening on the line for the first time, rather than an operator's summary of it.
What handover looked like
Both projects ran in stages, each ending with a demo of the live agent — something you can actually call and talk to, not a slide deck. Price was fixed in the technical spec before the start and did not change along the way. After handover, we fix issues free for 90 days, then move to retainer support if the client wants it.
Where this approach does not fit
- The company has no written policies yet. If operators' answers live in their heads rather than in a documented set of rules, the agent has nothing to work from. Turning that knowledge into a form the agent can answer from is a separate task that has to happen before the agent itself gets built.
- Every call needs legal or medical judgement. Where the cost of a wrong answer is high, the agent should honestly flag that risk during discovery, and the project should at most capture a contact for a specialist rather than try to replace the consultation.
- There is no one to pick up escalations quickly. A dashboard full of topics and load is useless if transferred calls have no one to answer them — the agent removes load from the phone line, but the bottleneck just moves to an already overloaded operator.
We build voice AI agents and other AI-driven automation at Hikmah Labs. More about the studio at https://hikmah-labs.dev/en/.
Top comments (0)