Schedules, records, and notifications run on domain modules — the care and manager apps have complete UI with backend integration in progress.
For
Member #1042 · redacted
The care and manager apps have complete UI with backend integration in progress. Every screen on this page is an example over mock data, and none of it means a service running in production.
Care
IntuneLabs builds Korean-first realtime voice agents that hold a check-in in natural Korean — in the browser or in a mobile app — and an operator console where your team reads back what was said afterward.
When the call ends, the rest of the work begins — when the next call goes out, what belongs in the record, and who needs to hear about it. The care-operations layer is the domain modules for that work, and its UI is complete today while backend integration is in progress.
Where the call lands
The way two people talk sitting down.
In a familiar room, at an ordinary pace.
And what stays behind once it ends.
It becomes a record
When the call ends, its record and follow-up land in the console. The care and manager apps have complete UI with backend integration in progress.
The current implementation state and what is open, written as it is — browser and mobile voice are live, telephony is built but key-gated, and the care and manager apps have complete UI with backend integration in progress.
See the roadmapImplementation state
Built versus shipped
Use cases
A care organization routes regular check-in calls into its operations and handles call records and follow-ups from a single screen. The console is live; the care modules behind it have complete UI with backend integration in progress.
Read the docsA family reaches the same call stack from the browser and the mobile app. The browser needs no install to start, and the mobile app runs the same realtime voice stack.
See the appsAn operations team closes out the work after the call in the console — where the redacted transcript, the conversational risk signal, and the per-call timings are reviewed.
See the consoleHow it works
The schedule starts the call
A recurring call schedule builds the queue, and that call starts in the browser or in the mobile app.
Processing finishes during the call
PII redaction, output guardrails, and the conversational risk signal are already done while the call is happening — not in a batch afterwards.
The record hands off to the console
The redacted transcript and the per-call timings land in the console, and the follow-up is assigned to an owner.
Notification opens the next thing
The follow-up and the next call reach their owner. The modules for this step have complete UI with backend integration in progress.
Step 1
Schedules, call records, member records, follow-ups, and notifications are not separately built screens: they sit on domain modules spanning care and consumer verticals. What changes in one changes everywhere it is consumed.
Read the docsWorks with
Call types, frequency, and owner assignment are configured in the console. Below is an example screen over mock data.
Care organization
Recurring check-in · Weekly
Call setup
Auto-scheduleAdd a call type
The same configuration is available in code. Below is an example over mock data.
const plan = care.schedule({ member: "member_1042", frequency: "weekly", window: { day: "thu", at: "10:00" }, transport: "webrtc",});// When the call ends, the redacted record and its follow-ups remain.plan.onComplete(async (call) => { await records.append(call.redacted); await followUps.assign(call.followUps, "care_team");});Example code. It carries no real credential and no real endpoint.
Where this stands
The care and manager apps have complete UI with backend integration in progress. Everything that reaches production passes one human gate.
Step 2
Frequency and time window are set per group, and that schedule builds each day's call queue. The table below is an example over mock data.
See what is builtExample data
Every value in the table is mock. It shows no real member, no real organization, and no real care setting.
| Group | Frequency | Calls | Window | Status | Columns |
|---|---|---|---|---|---|
| Group A | Weekly | 24 | 10:00 | Active | |
| Group B | Twice weekly | 48 | 14:00 | Active | |
| Group C | Biweekly | 12 | 11:00 | Awaiting review | |
| Group D | Monthly | 06 | 16:00 | Paused | |
| Group E | Weekly | 18 | 09:00 | Active |
Step 3
When the call ends, the redacted transcript and the per-call timings remain. Personal identifiers are stripped during the call rather than cleaned up afterwards by a batch job over stored transcripts.
The same call record reads differently depending on who is looking. Below is an example over mock data.
Call record
Record #2026-0814-1042
The record and its follow-ups hand off to the console with an owner and a due date attached. Below is an example over mock data.
For
Member #1042 · redacted
Step 4
The follow-up and the next call reach their owner. The modules for this step have complete UI with backend integration in progress.
Delivery
Triggers
Which event reaches whom, and when, is set per group. Below is an example over mock data.
care-followups-sample.csv
| Date | Group | Type | Calls | Follow-ups |
|---|---|---|---|---|
| 08-14 | Group A | Recurring | 24 | 3 |
| 08-14 | Group B | Recurring | 48 | 5 |
| 08-13 | Group C | Biweekly | 12 | 1 |
| 08-13 | Group E | Recurring | 18 | 2 |
One page for the day's calls and follow-ups. Every value below is mock.
Daily digest (example)
What is built
30+
voice-pipeline processors built in-house
100+
feature flags
450+
operator-console components
34
care and consumer backend domain modules
Every figure is counted in the repository — repository audit, August 2026.
Feature list
Schedules
Frequency and time window are set per group, and that schedule builds the call queue.
Records
The redacted transcript and per-call timings remain, and display varies by who is looking.
Follow-ups
A follow-up that came out of a call lands in the console with an owner and a due date.
Notifications
Which event reaches whom, and when, is set per group.
Domain modules
The 34 domain modules are counted in the repository audit of August 2026. A module existing is not the same as that module running in production — the care and manager apps have complete UI with backend integration in progress.
Read the docsHow we engage
Nothing ships to production on its own, and every deployment is scoped and priced on its own terms.
Pilot
A pilot first, and production only after that pilot has run. Scope and duration are set per deployment.
Contact usScoped per deployment
set by scope and duration
Contact usProduction
Production scope is set after the pilot has run. Everything that reaches production passes a human gate.
Contact usScoped per deployment
set by what the pilot showed
Contact usOne human gate
Everything that reaches production passes a human gate — a person on our side reviews and releases it.
Resources
Docs and guides on the work after the call and on the domain modules.
You can start from how the care-operations layer is put together, or from what actually runs today.
See the operator console
Where call records, transcripts, and follow-ups are handled on one screen.
See the consoleSet up for a care team
Recurring calls and the work after them, tuned to how the work is actually done.
Read moreEvery screen and table on this page is an example over mock data. The care and manager apps have complete UI with backend integration in progress; none of this means a service running in production. IntuneLabs makes no health measurement and no clinical claim, and holds no security or privacy certification.