Deployment scenarios

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 card states the setting, what gets assembled, and which parts run today versus still in development.

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
See the setup
Care organization

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
See the setup
Care organization

This week

Call records

Sample panel — not real call data

Completed
Awaiting follow-up
  • Call recordwith transcriptSaved
  • Follow-upneeds a personWaiting
  • Call recordwith transcriptSaved
CallsRecordsSchedulesSettings

How we work

What is live and what is not, stated before you ask

Deployments are scoped and priced individually: a pilot first, and production only after that pilot has run.

We orchestrate 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
Call session pipelineOn call
  1. Transport
  2. Speech to text
  3. Korean tuning
  4. Language model
  5. Text to speech

The safety processors run inside this same pass.

Transports

PathState
Live
Live
Key-gated
Per deployment

Telephony is integrated during a deployment.

Starts with no install

Browser call

Connected

Backchannel waitBarge-in vs. nodFiller audio

Sample panel — not a real call

Feature flags

  • On
  • On
  • Default off
  • Default off
  • Default off

Risky paths default off.

Which deployment should we scope first?

Start from the transports that run today, or from the shape you would want assembled. A pilot proves one use case.

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 pricing

Start 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 roadmap

The 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.