Who maintains a voice AI after go-live? The operating-model question

The three roles that need to exist

Most successful enterprise deployments converge on the same three roles, regardless of whether they sit in a single team or are split across operations, engineering, and CX.

• Conversation owner — reviews failed calls, owns intent and prompt changes, typically from CX or operations
• Platform owner — owns integrations, model selection, observability, typically from engineering
• Business owner — owns the metric, the roadmap, and the escalation path, typically from contact-centre leadership

What weekly looks like

A workable weekly cadence reviews a sample of escalated calls, tags failure modes, updates intents or guardrails for the top two failure modes, and ships those changes through a controlled release path. An hour of disciplined review per week prevents most drift; skipping it for a quarter is what creates the "the AI got worse" perception.

The non-engineer change path

If every prompt change requires an engineering ticket, the operating model collapses under its own latency. Platforms differ widely in what a conversation owner can change without code; this is one of the highest-leverage axes in vendor evaluation and one of the most under-rated.

The weekly cadence in detail

A workable weekly cadence is one ninety-minute meeting with the same three people, the same agenda, and a written decision log. The cadence is the operating model; everything else is implementation detail.

• Twenty minutes — review a sample of 20 to 40 escalated calls, tagged by failure mode
• Twenty minutes — review the platform-health dashboard: latency, integration error rates, intent drift
• Twenty minutes — agree the top two intent or guardrail changes for the coming week
• Twenty minutes — review last week's changes against the metric they were meant to move
• Ten minutes — write the decision log and assign the next week's review owner

How to staff the conversation-owner role

The conversation owner is the highest-leverage role in the operating model and the most commonly under-staffed. Plan for 0.5 to 1.0 FTE per high-volume deployment. The right profile is a senior contact-centre operations practitioner with prompt-engineering literacy — not a data scientist, not an engineer. The role makes hundreds of small judgement calls a quarter about what counts as a good response, and that judgement is the product of years of customer-facing operations, not of model training.

Staffing this role with a junior or a fractional resource is the most common cause of post-launch drift. Most other operating-model failures trace back to it.

The non-engineer change path — what to demand from the platform

A conversation owner should be able to change an intent, a prompt, or a guardrail and have the change live in production within an hour, with a clean rollback path. Platforms vary widely in what this looks like. Some require an engineering ticket and a deploy for every change. Others expose a controlled editor with diff review, staging, and one-click rollback. The second pattern is what makes a weekly cadence sustainable; the first is what kills it by month four.

During evaluation, ask each candidate platform to demonstrate a non-engineer changing a live intent and rolling it back. If the demo requires an engineer, the operating model will require one too.

How the operating model evolves through the first year

Three phases recur. In the first quarter, the team is firefighting — failure modes are abundant and the weekly cadence is mostly about triage. In the second and third quarters, drift becomes the dominant problem; intents that worked at launch start losing ground to changes in call mix or systems of record. By the fourth quarter, the team is mostly working on extension — adding intents, deepening integrations, raising containment on existing intents through targeted redesign. Staffing usually needs to flex with the phase: heavier in the first quarter, lighter in the second and third, and modestly heavier again in the fourth as scope expands.

Reporting that survives a steering committee

Steering committees lose patience with dashboards faster than the team building them expects. A monthly one-page report with five lines holds attention longer than a 30-tile dashboard.

• Primary metric vs target, with a single-sentence reason for any miss
• Top three failure modes this month, with the change shipped against each
• Top three failure modes carried over from last month — and why they remain open
• One paragraph on what shipped, one paragraph on what is shipping next month
• Forward look — the single risk most likely to compromise the next quarter

RACI for the four operating-model roles

Most operating-model failures are role failures. The RACI below names the four roles that have to exist for a high-volume voice AI deployment to survive, and the responsibility split across the six activities that recur weekly.

First 90 days — a week-by-week launch operating plan

The first 90 days set the operating model for the rest of the deployment's life. Drift here is expensive to reverse later.

1. Weeks 1–2: stand up the weekly cadence (same three people, same agenda, written decision log). Confirm per-call observability is accessible to the conversation owner with no engineering involvement.
2. Weeks 3–4: baseline containment, re-contact, CSAT, cost per resolved call against the pre-AI measurement methodology. Publish the baseline before tuning anything.
3. Weeks 5–6: ship the first two intent / guardrail changes and measure their impact against the baseline. Establish the rhythm of small, attributable changes.
4. Weeks 7–8: run the first end-of-month review against the success contract. Reaffirm or revise the primary metric in writing.
5. Weeks 9–10: extend the intent backlog by no more than two items. Catalogue failure modes that did not appear in the first six weeks but emerged at month two scale.
6. Weeks 11–12: write the first quarterly board pack — primary metric, top three failure modes shipped against, top three carried, single forward risk. One page.

Weekly review — runbook template

A weekly review that survives quarter-end has a fixed structure, a written decision log, and rotating ownership. The runbook below is what to copy into the calendar invite.

• Pre-read (sent 24h ahead): 20 escalated call samples tagged by failure mode + platform-health dashboard snapshot
• Block 1 (20m) — call sample review: each failure mode named, root cause hypothesised, owner assigned
• Block 2 (20m) — platform health: latency p95, integration error rate by system, intent drift signals
• Block 3 (20m) — change agenda: top two intent / guardrail changes for the coming week, with the metric each is meant to move
• Block 4 (20m) — last week's changes vs the metric they were meant to move; what shipped, what didn't, what we learned
• Block 5 (10m) — written decision log entry, next week's review owner named