Voice agents and conversation intelligence

Turning recorded voice (calls, meetings) into structured, searchable intelligence: summaries, recurring themes, entities, and compliance or risk signals. It is distinct from real-time voice agents, and it is usually the lower-risk starting point because the data already exists, nothing is customer-facing, and it tests how well models handle your actual accents, jargon and line quality before anything goes live.

Often yes, but not automatically. Recordings captured for quality monitoring or regulatory purposes were collected under a specific processing purpose, and analysing them with AI is generally a different one. The consent basis, retention position and residency need establishing before the build rather than during it, because it is answerable, and programmes that leave it to month four lose months.

Latency and interruption. Transcription, reasoning, tool calls and speech synthesis all have to complete inside the window where a human would have started speaking, and users interrupt constantly. Architectures that work asynchronously fail immediately under those conditions. The handoff to a human is the other hard part, and it is usually designed as an edge case when it is the main event.

Yes, on both halves of it. At HSBC Tenhaw's founder led an AI Voice Insights proof of concept that integrated with the contact-centre system, transcribed inbound handler calls into a vector database, classified each call for recurring themes, and drove automated agent notes and business intelligence on what customers were actually calling about, with 1.5M+ hours of annual manual administration projected rather than realised. Real-time agentic voice is shipped work at Velocity84, Tenhaw's build lab, which has produced more than twenty agentic products across voice, video, document reading, mobile and go-to-market, at startup rather than enterprise scale. Taking that into a regulated contact centre is scoped as a staged build with your telephony and compliance people in the room, and priced a stage at a time.

Start with the recorded estate. Analysing calls you already hold is lower risk because the data already exists, nothing is customer-facing, and it produces business value without touching a live customer interaction. Tenhaw's founder began there at HSBC, integrating with the existing contact-centre system and processing inbound handler calls. It also tells you how well the models handle your real accents, jargon and line quality before anything goes live, which is knowledge you will need either way. Latency, interruption handling and the handoff to a human make a live voice agent a different problem, and one unforgiving of architectures that only worked asynchronously. Prove value on the recordings first, then decide whether the live channel is worth the harder build.

Not reliable enough to be a headline metric. Sentiment scoring on real calls is noisy, culturally variable, and frequently wrong on exactly the calls that matter most. Treat it as one weak signal among several rather than the number the programme reports upwards, because using it as the headline is a reliable way to lose the confidence of the operational team that has to act on it. Thematic classification, showing what customers were actually calling about, is usually the more dependable output, and it answers a question most contact centres can currently only answer anecdotally.

Design it as the main event, not an edge case, because the handoff decides whether customers experience the agent as helpful or as an obstacle. Three things need specifying: how the agent decides to escalate, what the human receives when it does (the context, the transcript, the reason the agent gave up), and what the customer experiences at the boundary. Each should be specified and tested as carefully as the automation itself, and the escalation decision works on the same confidence-and-consequence routing logic used for document review. Most implementations design the happy path thoroughly and the handoff barely at all, which is the wrong way round.

Run a bake-off against your own recordings. It is the one place Tenhaw would insist on one. Speech recognition quality on your specific accents, jargon and line conditions varies meaningfully between providers, and it is worth testing rather than assuming from published benchmarks. For real-time work the orchestration primitives and telephony integration also differ substantially, so a transcription score alone does not settle the choice. In regulated environments, establish data residency for voice before any provider selection, because it is frequently the binding constraint and can rule providers out before quality is even measured.

Transcribe the calls into a retrievable store first, then classify each call for recurring themes, account issues and similar categories. The AI Voice Insights proof of concept Tenhaw's founder led at HSBC used exactly that architecture, integrating with the existing contact-centre system, processing inbound handler calls and landing transcripts in a vector database before thematic classification. The ordering matters, because with a searchable corpus in place, each new analytical question can be asked of the same store without reprocessing, rather than every question requiring a new pipeline. Outputs then need to land somewhere governed, with lineage back to the source conversation, or you have replaced one unsearchable estate with another. Settle the data-protection position in month one, before the build.

Two concrete outputs, serving different people. The AI Voice Insights proof of concept Tenhaw's founder led at HSBC produced both, and was projected to remove more than 1.5 million hours of manual administration a year, a projection rather than a realised figure. The operational output is automated agent notes, which remove the manual write-up from a call handler's day. The analytical one is thematic classification, a structured view of what customers were actually calling about, which most contact centres can only answer anecdotally. Aim at both, because programmes that pursue only the analytical output tend to struggle for operational buy-in; nothing changes for the people whose calls are being analysed.

They can, and on regulated work they usually should. Tenhaw's default is UK data residency with the EU available, and the pipeline runs on your infrastructure under your policies, not Tenhaw's. Residency for voice is frequently the binding constraint, so it is established before any provider is selected rather than after, because it can rule an otherwise strong speech provider out before quality is even measured. It also sits alongside processing purpose, consent basis and retention as a position settled with your DPO before the build starts, since recordings of customers are personal data and moving them is a decision rather than a deployment detail.

Often it will. A packaged tool answers packaged questions perfectly well, and if yours are generic, Tenhaw will say so. The build case turns on three things. Whether the categories you need are your own recurring themes and account issues rather than a fixed set someone else chose. Whether the summaries and themes have to land somewhere governed, with lineage back to the source conversation, because outputs nobody can trace have replaced one unsearchable estate with another. And whether the pipeline has to sit inside the contact-centre system you already run, which is how the AI Voice Insights proof of concept Tenhaw's founder led at HSBC was built.

Between £20,000 and £55,000, fixed, over two to four weeks. That is Tenhaw's published Agentic Proof of Concept price, and voice work is engaged through it. For that money the scope is usually the recorded estate rather than a live agent: transcribe a slice of your calls into a retrievable store, classify them for recurring themes and account issues, and find out how the models cope with your real accents, jargon and line quality. It ends in something running rather than a slide pack, and it commits you to nothing afterwards. Settle the processing purpose for those recordings inside the same weeks, not later.

Your DPO, as a co-author rather than a reviewer at the end. Tenhaw settles purpose, consent basis, retention and residency with them inside the two to four weeks of an Agentic Proof of Concept, because Article 5(1)(b) of the UK GDPR limits further processing incompatible with the purpose recordings were collected for. Then whoever owns the contact-centre system the pipeline has to integrate with, since that integration is most of the engineering. Then the operational leader whose handlers are on the calls, because their people have to act on whatever comes back. Getting those three in early is what decides whether the work ships or stalls in month four.

They will if the programme gives them nothing back, and the answer is in the design rather than the communications. The AI Voice Insights proof of concept Tenhaw's founder led at HSBC aimed at an operational output as well as an analytical one, so the same pipeline that tells the business what customers were actually calling about also produces automated agent notes that take the manual write-up out of the handler's day. Do the same, then keep sentiment scoring away from anybody's performance review, because it is noisy and culturally variable and people can tell when they are being measured by a number that is wrong about their hardest calls.

Give each stage an explicit number and treat the total as an architecture requirement rather than something discovered in production. Transcription, reasoning, tool calls and speech synthesis all have to finish inside the window where a human would already have started speaking, so writing the budget down early is what keeps the design honest once real systems are attached to it. Then test against interruption from the first week, because users interrupt constantly and designs that behave beautifully asynchronously fall apart the moment somebody talks over them. That is the most transferable lesson from shipping consumer voice products, where users are far less forgiving than internal testers.

Mostly they hate being trapped by one. Two design choices decide the experience. The first is interruption, because people talk over an agent constantly and an architecture that only ever worked asynchronously falls apart the moment they do, which makes the whole thing feel like a machine however good the voice sounds. The second is the boundary, the moment the agent gives up and a person takes over. Treat that as the main event and callers experience the agent as helpful. Most of the effort goes into the happy path and almost none into the boundary, which is why so many callers come away feeling obstructed.