See how the work moves from trigger to outcome.
Six illustrative workflow designs, with the AI work, system checks, human decisions, and exception paths made visible. Use these designs to map your own process with a domain translator, builder, and named operator.
These are illustrative designs, not customer case studies or measured results. Set your baseline, quality gate, and target before piloting. Readiness depends on your data, permissions, integrations, and capacity to review the work.
See the translator, builder, and operator responsibilities →
Missed-call follow-up
Give an unanswered call an owned next step.
The operating problem
A customer calls while the team is busy. Someone later checks voicemail, sends a reply, asks what the caller needs, and copies the details into CRM. Leads can be lost in the gap between the call and the follow-up.
Systems it touches
Phone system, approved messaging service, CRM, and task queue.
Human gate and authority
Start with approval before every outbound message. Only move to an approved template without individual review after the pilot proves the boundary. AI cannot promise prices, arrival times, refunds, or availability.
When it goes wrong
Do not send without the required contact permission. Deduplicate call events, stop on opt-out, and send uncertain or urgent cases to the team. A failed delivery creates an owned follow-up task.
Who owns it
Translator: front-desk or sales lead. Builder: phone-to-messaging-to-CRM workflow owner. Operator: the person who owns missed-call follow-up each shift.
| Before | Proposed after |
|---|---|
| A person notices the missed call, composes a message, and manually records the follow-up. | A checked event produces an approved reply and an owned CRM task, with the send and outcome logged. |
Prove it beside the current process
Replay historical missed calls in shadow mode. Have the operator score message relevance and routing before any live send. Then run a bounded live pilot with an approval queue and compare equivalent call periods.
Acceptance gate
Every permitted send is logged once, every exception has an owner, and messages meet the agreed quality gate. Expand only if response improves without increasing errors or complaints.
Measure what changes
- Response timeTime from missed call to first permitted response.
- Recovered opportunitiesEligible missed calls that become qualified conversations or bookings; compare with baseline.
- Net effort and qualityManual minutes avoided minus review and rework; track duplicate sends, incorrect claims, and complaints.
Scheduling and reminders
Suggest times with AI. Confirm bookings through rules.
The operating problem
Staff coordinate availability across messages and calendars, then chase confirmations and reminders. Stale availability and unclear booking rules lead to extra work, missed appointments, and scheduling errors.
Systems it touches
Booking calendar, staff availability, service catalog, CRM, and reminder service.
Human gate and authority
The calendar and booking rules determine availability. The customer confirms the actual slot; staff approves special requests. During the pilot, the operator reviews proposed bookings before writes.
When it goes wrong
Recheck availability immediately before booking and use a unique booking key to avoid duplicates. Respect cancellation, time-zone, and reminder preferences. If the calendar write fails, do not announce a confirmed booking.
Who owns it
Translator: scheduling or dispatch lead. Builder: calendar and messaging integration owner. Operator: scheduling coordinator responsible for exceptions and reminder quality.
| Before | Proposed after |
|---|---|
| Staff interpret requests, check calendars, exchange messages, and chase confirmations. | AI interprets the request; rules validate availability; the chosen slot is confirmed, recorded, and monitored. |
Prove it beside the current process
Run proposals beside the existing booking process without reserving duplicate slots. Test reschedules, cancellations, concurrent requests, holidays, and service limits. Move to a limited live calendar only after staff training.
Acceptance gate
Confirmed bookings exist in the system of record, conflicts are blocked, and failed writes reach staff. Expand only if coordination effort falls while booking accuracy is maintained.
Measure what changes
- Booking cycle timeTime from eligible request to confirmed appointment.
- Attendance and errorsNo-show rate, duplicate bookings, invalid slots, and correction rate for comparable appointment types.
- Net coordination effortStaff minutes per booking, including exception review and reminder failures.
Lead intake and routing
Collect the right context without inventing the answer.
The operating problem
Static forms miss useful details. Sales staff chase missing information, interpret free text, and decide who should respond. Leads stall when the handoff has no owner or the qualification criteria are unclear.
Systems it touches
Intake interface, approved service information, CRM, and routing queue.
Human gate and authority
AI recommends qualification using explicit criteria. A sales owner reviews uncertain or excluded cases. Rules assign the responsible team; AI cannot reject a prospect silently or commit commercial terms.
When it goes wrong
Keep unknown values unknown. Ask only for information needed to handle the inquiry. Detect duplicates and keep the original context. A routing failure creates a visible queue item rather than dropping the lead.
Who owns it
Translator: sales or service lead who knows fit and exclusions. Builder: intake, validation, and CRM workflow owner. Operator: the lead desk or sales coordinator who owns the queue.
| Before | Proposed after |
|---|---|
| Staff chase details and manually interpret, copy, and route each inquiry. | A structured draft preserves the inquiry, flags unknowns, and gives the responsible person an actionable handoff. |
Prove it beside the current process
Score historical inquiries against a domain translator's rubric. Run new inquiries through shadow classification alongside the current intake. Compare missing fields, routing accuracy, and response time before enabling record creation.
Acceptance gate
Unknowns are visible, excluded cases receive human review, and every inquiry has an owner. Expand only if verified completeness and routing improve without losing prospects.
Measure what changes
- Intake completenessShare of records with the necessary verified fields; exclude invented or unsupported values.
- Routing qualityCorrect owner on first handoff, reassignment rate, and inquiries left without an owner.
- Business resultTime to first useful response and qualified conversion for comparable lead sources.
FAQ answers and escalation
Answer from approved sources and make escalation easy.
The operating problem
Support staff repeatedly answer the same questions while customers wait. An automatic answer can help, but stale policy, unsupported claims, and blocked escalation can turn a fast response into a poor service experience.
Systems it touches
Support interface, versioned knowledge base, retrieval service, ticket system, and escalation queue.
Human gate and authority
Begin with review before replies. Only automate a tested set of routine topics with current approved sources. Refunds, disputes, account changes, and individualized commitments remain with the responsible person.
When it goes wrong
Do not fill gaps with plausible guesses. Preserve the conversation when escalating and offer a human route. An answer does not count as resolved merely because the customer leaves the chat.
Who owns it
Translator: support lead or policy expert. Builder: retrieval, source permissions, and ticket workflow owner. Operator: knowledge and support owner who maintains sources and reviews misses.
| Before | Proposed after |
|---|---|
| Staff search policy pages, compose routine replies, and manually transfer difficult cases. | A sourced answer draft handles the routine question, with an explicit route for unsupported or complex cases. |
Prove it beside the current process
Build a test set of real questions, unsupported questions, conflicting policies, and escalation requests. Score source support and actual resolution. Start with draft mode and track repeat contacts before expanding.
Acceptance gate
Unsupported questions escalate, customers can reach a person, and source permissions hold. Expand only if resolution improves without higher repeat contact or unsupported claims.
Measure what changes
- Supported answersAnswers whose material claims are backed by a current, permitted source.
- Resolution qualityConfirmed resolution, repeat contact, incorrect-answer rate, and successful handoff.
- Net support effortHandling time including review, rework, escalations, and knowledge maintenance.
Post-call summaries and actions
Turn a transcript into a reviewed operational record.
The operating problem
After each call, staff reconstruct notes, promises, and follow-up tasks. Important facts can be missed, while typing notes reduces time available for the next customer. A fluent summary still needs to be checked against the conversation.
Systems it touches
Approved call transcript source, CRM or ticket system, task queue, and audit log.
Human gate and authority
The staff member who handled the call checks the summary and approves saving it. AI can propose owners and dates only when the conversation supports them. It cannot create a customer commitment from an inference.
When it goes wrong
Flag uncertain facts instead of inventing them. Verify customer identity, record permissions, and retention rules. Save once, separate internal notes from customer messages, and expose failed writes for retry.
Who owns it
Translator: service or account lead who knows the record standard. Builder: transcript-to-record and task integration owner. Operator: call-team lead responsible for review quality and follow-through.
| Before | Proposed after |
|---|---|
| Staff write notes from memory, copy them into records, and create follow-up tasks manually. | A source-grounded draft is checked by the call owner, then saved with approved tasks and a traceable record. |
Prove it beside the current process
Compare drafts with the transcript and the original human notes. Review factual accuracy, missed commitments, and edit time. Run alongside existing notes before switching the team to a reviewed draft workflow.
Acceptance gate
No unsupported commitments are saved, writes are traceable, and staff can correct drafts easily. Expand only if net note time falls while record quality and follow-through hold or improve.
Measure what changes
- Net note timeBaseline note-and-task time minus AI review, correction, and save time.
- Record qualityFactual errors, omitted commitments, required-field completeness, and correction rate.
- Follow-throughApproved tasks completed on time and commitments lost between the call and handoff.
Password reset and account recovery
Guide a locked-out user through approved recovery without giving an agent authority to bypass identity checks.
The operating problem
Locked-out employees need help, while service desks must resist account takeover. Recovery restores access to an existing account; it must not become a shortcut around its security controls.
Systems it touches
The identity provider’s recovery service, enrolled contact records, messaging channels, support queue, and security event log. AI explains the process and prepares the support record; the identity system evaluates proofs and issues a limited reset session.
Who owns it
Translator: identity or service-desk specialist who knows the recovery policy. Builder: identity-integration architect. Operator: access-support owner who monitors failed recovery, suspicious requests, and policy changes. Security owns changes to proof requirements and privileged-account recovery.
Password reset is not MFA reset
Changing a password must not silently remove MFA, change recovery contacts, or enroll a new authenticator. Losing an MFA device follows its own approved recovery path. No caller ID, familiar voice, urgency, or executive request can override that policy. OWASP MFA recovery guidance.
| Option | What it checks | Boundary and warning |
|---|---|---|
| SMS to an enrolled cell | Access to the registered phone channel. | SIM swaps, number porting, lost phones, and interception can defeat it. Use only where the recovery policy permits; a number provided during the request is not an enrolled method. |
| Code to an enrolled personal email | Access to a previously verified recovery inbox. | Email can carry a recovery code under an approved policy; it is not a NIST out-of-band authentication factor. SMS plus email does not automatically constitute MFA, and both may be accessible through the same compromised device. |
| Previously set memory keyword | Knowledge of an enrolled secret, rather than current access to a channel. | A single word or personal-history answer is guessable knowledge-based recovery. Do not use it as the sole reset proof. If a supported system accepts a separately enrolled secret passphrase, security must assess its strength and handling. It must never be a hint to the main password. |
| Voice call to an agent | The call itself proves no identity. The agent helps the user reach the approved validation flow. | Do not treat voice resemblance or caller ID as proof. Enter codes and secrets directly into the official secure interface, not the AI conversation. A phone-only route needs an approved isolated IVR/keypad verifier that keeps secrets out of recordings, transcripts, and model context. |
| Existing authenticator or saved recovery code | An enrolled authenticator or a pre-issued recovery secret through the identity platform. | Prefer supported strong authenticators where available. A saved recovery code is a secret to protect, not a personal trivia answer. Missing or failed proofs follow documented recovery or renewed identity proofing. |
A remembered secret is “something you know,” but being memorable does not make it strong. Two recovery channels are not automatically two independent factors. Apply the account’s assurance and recovery policy rather than inventing a checklist of SMS + email + keyword. NIST authentication guidance; NIST recovery guidance; OWASP on security questions.
How the voice-assisted version works
The user calls the published support number. The agent explains the available enrolled methods without exposing contact details or confirming account existence. The recovery service sends a request-bound challenge by an approved channel. The user submits it directly to the verifier; the agent receives only pass/fail and next-step status. The identity platform then authorizes a secure password-setting screen. Flagged requests enter the documented identity-review path. The agent never asks the user to speak their password, code, or memory secret.
| Before | Proposed after |
|---|---|
| Manual service-desk triage, repeated explanations, and inconsistent escalation when users lose access. | Agent-guided recovery with platform-enforced verification, protected secret entry, visible exceptions, and a traceable reset outcome. |
Prove it without changing real credentials
Use test accounts and simulated recovery. Test guessed, expired, reused, and cross-account codes; changed contacts; lost devices; repeated requests; social pressure; and attempts to remove MFA. Compare completion, accessibility, escalation, and false acceptance before a limited pilot.
Acceptance gate
No reset without policy-approved proof. Reset tokens are unpredictable, expire, work once, and stay bound to the account and purpose. Limit requests and attempts without letting attackers lock accounts by flooding recovery. Use consistent responses, preserve MFA, notify the user, and handle existing sessions under policy. Never log passwords, codes, or memory secrets. OWASP reset controls.
Measure what changes
- Recovery qualityUnauthorized recovery, bypass attempts, incorrect approvals, and legitimate users wrongly blocked.
- Completion and effortSuccessful legitimate recoveries, abandonment, time to restored access, and support review effort.
- Security and usabilityRepeat incidents, protected-secret handling, accessibility failures, and correct escalation for lost methods or privileged accounts.
Pick one workflow. Prove the change.
Map the current process, name the owner, and compare the pilot against the same work and quality standard. Include tool costs, maintenance, human review, and rework before claiming savings.