AI Customer Support Launch: 30/60/90-Day Plan 2026

AI customer support launches fail when CSAT lags deflection. The failure pattern is consistent across the deployments we have seen unravel: the team picks a vendor, signs a license, builds a thin knowledge base in three weeks, and ramps the bot to a meaningful slice of traffic before the CSAT instrumentation exists to detect damage. The 90-day plan in this piece is the antidote — a phased, CSAT-gated rollout that treats the support program as a product launch with measurable outcomes.

The shape of the plan is deliberately conservative on traffic and aggressive on instrumentation. Days 1-30 are spent on the knowledge layer — auditing what documentation exists, building an intent catalog from real tickets, and shipping a RAG retrieval index against the top-100 ticket archetypes. Days 31-60 launch a 1% deflection pilot with explicit CSAT gates, a designed escalation handoff, and per-archetype confidence thresholds. Days 61-90 ramp toward a 10-25% deflection ceiling, wire production observability, and train the agent team on the handoff pattern so escalations land cleanly.

This piece is the operational guide underneath that plan. It covers why 90 days is the right horizon, the milestone-by-milestone sequence for each phase, the CSAT gates that govern when traffic can ramp, the templates we ship with client engagements (knowledge audit, escalation rubric, handoff script), and the four support-launch failure modes that account for almost every unsuccessful rollout we have seen.

Ninety days is not arbitrary. It is long enough to do the knowledge work upstream of the model — most teams underestimate this and pay for it in deflection quality — and short enough to keep momentum in front of the executive sponsor. Anything faster tends to skip the knowledge audit or the CSAT instrumentation; anything slower tends to lose stakeholder focus before the pilot ramps.

The failure pattern we see most often is a four-to-six-week rollout that hits deflection numbers in week three and ships CSAT damage that surfaces in week eight, by which point the bot is touching too much traffic to roll back cleanly. The customer base remembers a bad experience for longer than the deflection dashboard remembers a good month. Treating CSAT as a gating constraint rather than a downstream metric is what separates a launch that holds from a launch that has to be quietly rolled back.

The deeper reason 90 days works is that the instrumentation has to lead the model. Resolution CSAT, delayed CSAT measured 48 to 72 hours after the conversation closes, and model-scored conversation CSAT surfaced to a daily QA review — all three have to be live before the pilot opens. The first 30 days build the knowledge and instrumentation layer; the second 30 days launch a tightly-bounded pilot; the third 30 days ramp on the strength of the data those layers produce.

The plan is also opinionated about what does not belong in the first 90 days. Multi-language support, voice channels, and advanced personalisation are all expansions that should follow the day-90 stability check rather than ride alongside it. The same is true for ambitious deflection targets above 25% in the first quarter — those numbers can be real over a longer horizon, but they almost always require a depth of tooling integration (order lookup, refund APIs, account state, billing systems) that is not realistic to build inside the first 90 days. Ship the foundation; expand from there.

The first 30 days are the knowledge-and-instrumentation phase. No customer-facing traffic touches the AI in this window. The entire effort is upstream — audit the documentation, build the intent catalog from real tickets, ship a RAG retrieval index against the top-100 ticket archetypes, wire the CSAT instrumentation layer, and pick the escalation rubric the team will use once the pilot opens.

The temptation in this phase is to skip ahead to the model and the vendor selection. Resist it. The reason most pilots disappoint is not the model — it is the knowledge layer underneath the model. Documents that are stale, missing, or contradictory will produce a confidently wrong bot regardless of which frontier model you pick.

One nuance worth surfacing here. The knowledge audit is rarely the work the support team most wants to do — it is closer to housekeeping than to a launch. But it is the work with the highest leverage on the entire 90-day plan. A team that ships a disciplined audit in weeks 1 and 2 typically lands a 10-15 percentage-point higher deflection ceiling at day 90 than a team that skips it, and avoids almost every category of confident-hallucination failure mode that plagues less-prepared rollouts. The audit is the launch.

For teams that have not run a knowledge audit before, the structure is straightforward: build a spreadsheet of every article and SOP, assign each row to an owner, ask each owner to flag any document that is older than six months or has had a product change since last review, and triage the resulting list into "update before pilot", "update by day 60", and "deprecate". Three columns, two weeks of work, and the deflection ceiling moves more than any model upgrade will in the first year.

The second 30 days launch a tightly-bounded deflection pilot. One percent of inbound support volume routes to the AI; the other 99% stays on the existing human-only path. The window is long enough to see CSAT damage if it is there, and the traffic slice is small enough that any damage is contained.

The point of the pilot is not to hit a headline deflection number — it is to validate that the knowledge layer, the confidence thresholds, and the escalation rubric all hold up against real customer traffic. Deflection in this window is a byproduct, not the goal.

One pattern worth noting from the pilots we have shipped: week 5 deflection numbers will look disappointing. The model is learning archetype distributions, the confidence thresholds are calibrated conservatively, and the escalation rubric is biased toward handing off. That is the right shape for week 5. By week 8 the deflection number will have climbed substantially — and crucially, it will have climbed at flat or improving CSAT, which is the only deflection number worth reporting.

The escalation handoff deserves disproportionate attention in this phase. A clean handoff means the customer never repeats themselves: the agent picks up a transcript, an intent classification, a confidence score, and any relevant customer state, and continues the conversation from there. A poor handoff is the single largest source of CSAT damage we have seen across deployments — worse, in CSAT terms, than the bot simply being wrong, because the customer experiences wrong-and-frustrating rather than wrong-and-escalated.

The third 30 days ramp toward a stable deflection ceiling, wire production observability, and train the broader agent team on the handoff pattern so it scales beyond the pilot squad. By day 90 the deployment should be in a state where it can run unattended for a week without breaking — and where the quarterly model-upgrade cadence has been baked into the operating rhythm.

The ramp is not linear. Each traffic step (1% → 3% → 8% → 15% → 10-25% ceiling) gates on a CSAT-trend check, a false-positive-escalation rate, and a confidence-threshold stability review. Skipping any of those gates is the most common way day-90 deployments produce day-180 rollbacks.

The day-90 milestone is not a victory lap — it is a handover. The pilot squad transfers operational ownership to the support team, the eval cadence transfers to a quarterly rhythm, and the broader product backlog (multi-language, voice channels, personalisation) becomes viable to pick up. The day-90 ceiling is rarely the year-one ceiling — most deployments climb to a higher steady-state deflection by month nine — but the difference between a deployment that gets to month nine and one that gets rolled back is almost always the discipline of the first 90 days.

One operational note. The deflection range in week 12 will often land below the original ramp plan. That is normal and is usually a sign the CSAT gates are doing their job — they are holding deflection at the level the archetype mix actually supports, not at the level the slide deck promised. The response is to ship the realistic number, not to relax the gates.

The ramp gates are the most important operational artifact in the 90-day plan. Each traffic step has an explicit pre-condition, a measurement window, and an automatic-rollback rule. The discipline of the gates is what separates a deployment that scales from one that has to be rolled back in week sixteen.

Two implementation notes on the gates. First, every gate decision is a human decision — the dashboards are inputs to the decision, not the decision itself. Automating the gates is tempting and almost always backfires because the right rollback response to a CSAT signal usually involves context the dashboard does not see (a launch that just shipped, a known outage, a documentation change). Keep humans in the loop.

Second, the rollback rule has to be cheaper than the measurement window. If rolling traffic back from 15% to 1% requires a release, a config change, and a war room, teams will avoid the rollback even when they should not. The cleanest implementations we have shipped use a single feature-flag value that any on-call engineer can toggle — under thirty seconds from CSAT-alert to traffic-back-at-baseline.

Three templates ship with every engagement we run. The knowledge audit is the upstream artifact that sets the deflection ceiling; the escalation rubric is the per-archetype confidence and routing spec; the handoff script is the customer-facing language and the agent-facing context payload. Each is short by design — the value is in the discipline of having them at all, not in the length of the document.

What follows is the working shape of each template. Adapt to your own ticket archetypes and operational vocabulary; the structure is the load-bearing part.

A few notes on adapting the templates. The knowledge audit row shape is intentionally narrow — five columns, plus owner and notes, is the minimum that produces a useful work backlog. We have seen teams expand it into a thirty-column tracker that never gets maintained; the narrow shape gets maintained, which is the whole point.

The escalation rubric is the document with the highest operational consequence. Every never-deflect category — refunds above a threshold, churn-save conversations, security or account-compromise reports, anything regulated — has to be written down with the sign-off of the support lead and (where relevant) the legal lead. The cost of an AI deflection on the wrong archetype is much higher than the value of one extra deflected ticket.

The handoff script matters because customers experience the handoff as a continuity check, not as a feature. If the agent can confirm the AI summary inside the first thirty seconds of the live conversation, the customer experiences continuity. If the agent has to ask "what is this about", the customer experiences context loss — which, in our deployments, is the single largest source of CSAT damage. Train for the thirty-second confirmation.

Almost every failed support-AI launch we have seen falls into one of four categories. Knowing the patterns is the cheapest insurance against them — most of these are obvious in retrospect and missable in the moment. The stress-tests below are designed to surface each failure mode before it ships, not after.

Two further patterns are worth flagging even though they sit outside the headline four. The first is vendor lock-in by ticket schema — the AI vendor's ticket schema becomes the de facto schema for your support data, and switching vendors later requires a painful migration. Mitigation is to keep the canonical ticket schema in your own data layer (warehouse, lake, primary database) and treat the vendor schema as a downstream view.

The second is model upgrade inertia — the deployment lands on a frontier model in month one and stays on it for eighteen months while the broader model landscape moves twice. Mitigation is the quarterly eval cadence described in the day-90 milestone — 50-100 archetype prompts with expected outputs, rerun against the current frontier each quarter. If a new model wins on your evals, plan the migration; if not, the eval still gives you defensible evidence to stay put.

For teams designing the underlying business case before committing to a 90-day launch, our companion piece on support ROI and the deflection formula covers the math underneath the model — deflection ranges by tier, cost-per-ticket ladders, break-even thresholds, and vendor comparison. And for the anti-patterns to actively avoid during rollout, our piece on support anti-patterns and deflection mistakes walks through the deployments that have gone wrong and the common shape of the failure.

For teams that want the 90-day plan delivered as a managed engagement rather than run internally, our AI transformation engagements ship the knowledge audit, the RAG build, the CSAT instrumentation layer, the pilot, and the agent training as a phased program — calibrated to your ticket archetype mix and with measurable CSAT-controlled outcomes.