A dashboard tells you the state of the world. It cannot answer a question.
Give an operations manager a dashboard full of bed occupancy, emergency department queues and escalation levels, and they still have to go hunting. Click into the right site. Find the right chart. Cross-reference it against another panel. That is a perfectly reasonable workflow when you have twenty minutes.
It is useless when you are on your feet during a winter surge and you need to know who is worst off, right now.
What you want in that moment is to ask. Which sites have queues over three hours. Who has the deepest staffing deficit. How are beds in London. The person under pressure should not have to know where the data lives or which panel it hides behind — and that, rather than any enthusiasm about conversational AI, is the case for putting a voice interface over an operations tool.
The value is not that it talks. It is that the operator no longer has to know the interface to interrogate it.
What we built, and what it is not.
We added a live avatar operations assistant, Wren, to our NHS Digital Twin — a browser-based operations platform that runs from a photoreal 3D map of a trust estate down to a live room-level floor plan, with a patient-flow and escalation model underneath. It is built on the SDK from Akapulu Labs.
Two things need saying before anything else, and they are the same two things that appear on the product itself.
It is a concept prototype, and every number in it is simulated. No real patient data and no real operational data goes anywhere near it. That disclosure sits on the entry screen, in the footer and on every modelling panel, and it stays there. It is an independent concept and it is not affiliated with the NHS.
What is real is the interaction pattern and the architecture around it. Those transfer to any operational estate — a logistics network, a utility, a campus, a manufacturing group — and they are the part worth writing down.
Cut the SDK at the right seam.
The integration came together in layers, and where we cut between our code and the vendor’s is the decision that made the result feel native rather than bolted on.
The base was unremarkable in the best way. The REST contract is clean and predictable: connect returns a room URL, a token and a session ID, and updates poll by that ID. We understood it in minutes, which is rarer than it ought to be.
The part that earned its keep was one level down. The SDK exposes lower-level hooks, not just a prebuilt conversation component, so we could discard the supplied interface entirely and build our own compact stage in the NHS design language — while the SDK still owned everything genuinely hard underneath it.
Where we cut
---- ours ---------------------------------
avatar-first stage, not a chat panel
NHS design language and typography
the launcher that follows the map
camera control over the twin
---- the SDK's ----------------------------
WebRTC transport (Daily)
media capture and playback
live transcripts
speaking-state
-------------------------------------------
A good SDK lets you cut along this line.
A weak one gives you the whole widget
or nothing.That seam is worth insisting on when you evaluate any conversational vendor, and it is a fair question to ask in a sales call. A voice assistant that visibly looks like a widget dropped in from somewhere else undermines trust immediately, and in healthcare it does so instantly. It is also the reason we went avatar-first rather than putting a chat window in the corner: a chat panel reads as an add-on no matter how you style it.
Meanwhile we never had to touch real-time media plumbing, which is exactly the work you want to buy rather than build.
The API key never reaches the browser.
This is the most transferable part of the whole build, and the easiest to get wrong under time pressure.
Every quickstart for every conversational SDK shows you the fastest path to a working demo, and the fastest path almost always puts the credential in client-side code. It works. It demos beautifully. It is also a key that anyone can read out of the network tab, attached to an account that bills by usage.
Where the credential lives
Browser
| signed-in user
v
Firebase Function /api/akapulu/**
| 1. verify the user
| 2. only then attach the API key
v
Akapulu API
|
v
room URL + session token + session ID
|
v
Browser <-- never sees the key
Media then flows browser <-> Daily
using the session token alone.Our calls go through a server-side proxy — a Firebase Function behind /api/akapulu/** — which verifies the signed-in user before it ever touches the key. The browser only ever receives a room URL and a session token. Neither is a credential, both are scoped to one session, and neither is worth stealing.
It is more plumbing than the quickstart. It is a great deal less plumbing than retrofitting it after a security review, and it is close to impossible to retrofit after a leak.
Grounding was harder than the wiring.
If you are budgeting a build like this, put the hours here rather than in the integration.
In an operational setting a confidently wrong answer is worse than no answer at all. A dashboard that fails to load is obviously broken and nobody acts on it. An assistant that invents a plausible bed count is not obviously broken, and somebody might.
So the model has to stay tied to the facilities and figures actually in front of it, and it has to decline gracefully when a question falls outside them rather than improvising something helpful-sounding. Constraining it that way was a larger share of the effort than all of the wiring put together, and it is the part that does not show up in a demo video.
Three rules came out of it that are worth applying to any assistant sitting over operational data:
- Answer only from the model in front of you. Not from training data, not from inference about what a number probably is. If the twin does not hold it, the assistant does not know it.
- Make declining a first-class outcome. Design and test the refusal path as carefully as the answer path. An assistant that will not say it does not know is not usable for operations.
- Never let it round, smooth or reconcile. If two figures disagree, that is a fact about the estate and the operator needs to see it, not a discrepancy for the assistant to tidy away.
Voice that operates the tool, not a chatbot beside it.
The last layer is the one that changes what the thing is.
Wren does not only answer. It acts on the model: pulling live figures out of the twin, and flying the 3D camera to a site when you ask to see it. You ask which site is worst off, and the map takes you there while the answer is still being spoken.
That is the difference between an assistant and a chatbot in a corner, and it is a design decision rather than a modelling one. The requirement is simply that every question the assistant can answer maps to something the application can also do — select, navigate, filter, open. If your answers and your application state are separate systems, you have built a search box that talks.
It also changes what people ask for. When the interface moves in response, people start using it to navigate rather than to query, and the assistant stops being a feature and becomes the way in.
What it is worth, stated honestly.
The operator case is straightforward. Asking instead of hunting turns four clicks across three panels into seconds. Hands-free means attention stays on the floor or the phone rather than in a menu tree at the exact moment pressure is highest. And it lowers the barrier to the data, which widens who can interrogate the system at all — from the analyst to the duty manager to an executive on a call.
The commercial case sits one level up, and it is not the one people expect.
A voice layer is cheap to bolt on badly and expensive to bolt on well, and regulated sectors only buy the second kind. Building the credential boundary and the grounded-answer constraint from the first line is not tidiness. Those are precisely the questions a procurement or information-governance process asks, and having credible answers already built is what moves a conversation from interesting demo to scoped pilot. The architecture that keeps one API key safe is the architecture that lets you say yes to a security questionnaire.
On efficiency, the honest position is that these are hypotheses rather than results. If asking a question drops from minutes to seconds, that time compounds across every shift and every manager. If the worst-off site surfaces the moment it tips rather than the next time somebody checks, intervention comes earlier and flow is protected before it breaks. Both are plausible, both are measurable, and neither is something a prototype running on simulated data is entitled to claim. They are the right things to be testing against a real operation, which is a different statement from having tested them.
Where it goes next is the same two moves in both cases: point the assistant at a genuinely live operational model rather than a simulated one, and move it from answering to acting — kicking off a coordination task or opening the right workflow, not just reporting the state.
What this means for a buyer.
Start with the business decision, audience, and evidence the project must produce. Simam Digital can turn that into a focused discovery, prototype, MVP, or production roadmap across AI applications, SaaS platforms, digital twins, real-time 3D, XR, and interactive systems.
