These are deployment scenarios, not customer stories
The eight below are shapes you can assemble from capabilities we actually built. None of them is a particular organization's story, and none of them carries an outcome figure. Each one shows the setting, what gets assembled for it, and which parts are running today versus still in development.
The scale of the implementation behind these scenarios
30+
custom voice-pipeline processors
100+
feature flags
450+
operator-console components
34
care and consumer backend domain modules
Every figure was counted in the repository — audit, August 2026.
By stage
What runs today, and what is still in development
Live
transcription accumulates during the call
One screen
call records and follow-up
Assembled from
- Voice engine
- Operator console
- +1
Regular check-in calls run, transcripts and call records land in the console, and follow-up runs only after a person confirms it.
What gets assembled
Each scenario is assembled from capabilities that already exist
The point is to separate what would have to be built from what is already there. The panels below are original mockups — no real call data and no real organization appears in any of them.
Regular check-in calls, routed into operations
The setting
Check-in calls happen on a set rhythm, and the team needs to be able to read back what was said afterwards.
What gets assembled
The voice engine holds the call, transcription accumulates while it runs, and when it ends the record and its follow-up land in the console. Production actions run only after a person confirms them.
Capabilities used
- Voice engine
- Live transcripts
- Operator console
This week
Call records
Sample panel — not real call data
- Call recordwith transcriptSaved
- Follow-upneeds a personWaiting
- Call recordwith transcriptSaved
By who it is for
Pick by who the deployment serves
How we work
What works and what does not, stated before you ask
Deployments are scoped and priced individually: a pilot first, and production only after that pilot has run.
We orchestrate best-of-breed vendor models for speech, language, and synthesis. What we build is the Korean tuning, the orchestration, and the reliability layer around them.
- Korean-first turn-taking
- Live transcripts and call records
- PII redaction and output guardrails
- Degrade over crash
- Staged rollout behind flags
- Production stays human-opened
- Key-gated telephony path
- Data handling scoped per deployment
- Transport
- Speech to text
- Korean tuning
- Language model
- Text to speech
The safety processors run inside this same pass.
Transports
Telephony is integrated during a deployment.
Starts with no install
Browser call
Connected
Sample panel — not a real call
Feature flags
- On
- On
- Default off
- Default off
- Default off
Risky paths default off.
Which deployment do you have in mind?
Start from what is running today, or from the shape you would want assembled.
Scoped per deployment
Not a fixed plan — we start from how you would use it and what has to be integrated, then quote from there.
See pricingStart from what is live
What runs today and what is still in development are kept separate, and you can read them that way.
See the roadmapThe scenarios on this page are not customer stories. No organization is named or implied, and nothing here carries a customer quote or an outcome figure. Each scenario describes a deployment shape you can assemble from capabilities that exist today.
Every panel on this page is an original mockup. None of them shows a real call, a real person, or real customer data. Figures are limited to what the August 2026 repository audit counted, and IntuneLabs holds no SOC 2, HIPAA, or GDPR certification.