90-Day AI Customer Communication Roadmap: Pilot to Production

Ninety days is a scope, not a promise

This is a phased structure for taking one AI customer communication use case from decision to a working, measured production deployment in about ninety days. It is a scope discipline, not a guarantee — the actual calendar time depends on your own systems, content and team availability, and the roadmap's value is in the sequence and the gates between phases, not in a fixed number of days that applies identically to every organisation.

It covers one use case deliberately, whether chat or voice, rather than a simultaneous rollout across every channel — the sequencing and lessons from one properly executed deployment are what make a second one faster, not the reverse.

Days 1-15: scope and baseline

The phase most often compressed under schedule pressure, and the one whose quality determines everything after it.

1. 1

   Select one use case, narrowly

   Not 'improve customer communication' — a specific, bounded scenario: after-hours enquiries, appointment booking, a defined category of support question. Breadth is added later, from evidence, not assumed at the start.

2. 2

   Sample real interactions in the chosen scope

   A week of real calls or conversations, classified by type, to establish what the use case actually contains rather than what it was assumed to contain.

3. 3

   Record the baseline

   Current volume, response time, resolution rate, cost per contact — whatever is relevant to the chosen use case, measured before anything changes, since this is what any later ROI calculation depends on entirely.

4. 4

   Define success numerically, agreed by the people who will judge it

   Specific numbers, not a general sense of improvement, agreed in writing before building starts.

5. 5

   Name owners for every workstream

   Content, integration, testing, operations, business sponsor. Unowned workstreams are where these projects stall.

6. 6

   Confirm platform or build decision is already settled

   This roadmap assumes that decision has been made — if it has not, that evaluation is its own preceding project, not part of these ninety days.

Days 16-35: content and knowledge

Usually the largest workstream by effort, and consistently the most underestimated at the planning stage.

1. 1

   Build the real question or scenario inventory

   From the sample gathered in phase one, ranked by frequency — the audit method covers this in depth for chatbot content specifically, and the same discipline applies to voice scenarios.

2. 2

   Resolve contradictions in existing source content

   Before any conversation design work begins — a contradiction in the source produces a confident wrong answer regardless of how well the conversation around it is designed.

3. 3

   Write for the channel

   Spoken answers for voice, scannable answers for chat — the same underlying facts, presented differently for how they will actually be consumed.

4. 4

   Define the explicit scope boundary

   What the system will never answer, agreed with whoever owns that risk in the organisation, not assumed by the project team.

5. 5

   Script escalation and failure paths

   Not understood, no answer available, and — for voice — noise and interruption handling. These are a meaningful share of real interactions and are frequently written last if at all.

Budget more time here than feels reasonable at the planning stage. Content and knowledge work is rarely the bottleneck teams expect it to be during planning, and it is almost always the bottleneck they encounter during execution.

Days 26-45: integration (overlapping with content)

Run in parallel with content work rather than after it, since integration discoveries frequently affect what the content and conversation design can actually promise.

1. 1

   Confirm read and write access to the systems the use case needs

   Order status, calendar, CRM — whatever the specific scope requires. Discovering an integration is read-only partway through reshapes the conversation design and is far cheaper to learn now than later.

2. 2

   For voice specifically, confirm telephony connectivity works end to end

   Including transfers carrying context, tested on a real call through the actual telephony path, not assumed from a vendor's documentation.

3. 3

   Build write-back with idempotency

   So a retry after a timeout cannot duplicate a booking or a record — this is a common and expensive gap to discover after launch rather than before it.

4. 4

   Define behaviour for every integration failure

   Degrade honestly on reads, queue on writes, fail closed on actions — decided in advance rather than improvised in production.

5. 5

   Confirm data handling and retention meet your own policy

   Documented, not assumed, before any real customer data flows through the system.

The integration workstream is where projects most often discover their real constraint, and running it in parallel with content work — rather than after it — is what keeps a late discovery from delaying the whole roadmap by the full length of the content phase.

Days 46-60: testing

A distinct phase with its own discipline, not an afterthought squeezed between content and launch.

1. 1

   Build the test matrix from the categories that matter

   Happy paths, ambiguity, out-of-scope requests, escalation, adversarial attempts, integration failures — the testing checklist covers this in depth, with voice-specific additions where relevant: real audio conditions, interruption handling, recognition accuracy.

2. 2

   Test against live escalation destinations

   Not test queues — the actual people and systems that will receive escalations in production.

3. 3

   Run an adversarial pass with someone outside the build team

   This consistently finds different problems than the people who built the system testing their own work.

4. 4

   Define exit criteria in advance and hold to them

   Written down before testing starts, so the go-live decision is a factual check against agreed criteria rather than a negotiation about confidence under schedule pressure.

5. 5

   Fix and re-test, not just fix

   A defect fixed without a re-run of the relevant test cases is an unconfirmed fix, not a resolved one.

Hold the exit criteria set in phase one. The most common testing-phase failure is quietly lowering the bar as the go-live date approaches, which defeats the purpose of having set criteria at all.

Days 61-75: narrow launch

Go live on a deliberately limited slice, with a way back, and widen only on evidence.

1. 1

   Launch on a limited scope

   One call type, a share of traffic, or out-of-hours only — whichever boundary makes sense for the use case and gives the clearest comparison against the baseline.

2. 2

   Monitor daily for the first two weeks of this phase

   Someone reading or listening to a sample every day, which finds more in two weeks than any dashboard finds in two months.

3. 3

   Keep the rollback tested and available

   Not just documented — confirm someone other than the system's builder can execute it under time pressure.

4. 4

   Track the phase-one success metrics from day one of launch

   So the comparison against baseline is available continuously, not assembled retrospectively at the end of the ninety days.

5. 5

   Resist widening scope during this phase

   Widening should be a deliberate decision made in phase six, based on evidence from this phase — not an incremental drift that happens because the narrow scope feels unnecessarily restrictive once things are working.

The daily monitoring habit established here is worth carrying forward past the ninety days, tapering in frequency rather than stopping abruptly once the narrow launch appears to be going well.

Days 76-90: measure and decide

The phase that turns a launch into a decision, closing the loop back to phase one's baseline.

1. 1

   Compare against the phase-one baseline explicitly

   The same metrics, the same definitions, so the comparison is genuinely apples to apples rather than assembled from different measurement approaches.

2. 2

   Build the ROI case from real data, not the pre-launch estimate

   Using the chatbot or call centre ROI frameworks with actual measured figures rather than the assumptions made before launch — this is what confirms or corrects the original business case.

3. 3

   Decide on widening, holding, or adjusting

   Based on the evidence gathered, not on the calendar reaching day ninety by itself. If the evidence does not yet support widening, holding the current scope longer is a legitimate outcome.

4. 4

   Establish the ongoing operating rhythm

   Weekly review of unanswered questions and escalation reasons, monthly content updates, named ongoing owners — a project that ends without this degrades quietly from the day the project team disbands.

5. 5

   Document what was learned for the next use case

   Content patterns, integration gaps, testing categories that mattered most — captured while still fresh, since this is what makes a second deployment faster than the first.

The operating rhythm established here is what determines whether the quality achieved by day ninety survives the following year — a system that stops being actively maintained the day the project formally ends will degrade, regardless of how well it performed at launch.

Adapting the roadmap for chat versus voice

The phase structure is identical; several specific activities within it differ meaningfully between the two channels.

• Voice needs telephony connectivity confirmed early — ideally in phase one alongside baseline measurement, since lead times on telephony changes can be longer than for any other workstream.
• Voice testing needs real audio conditions specifically — mobile networks, background noise, accents — which have no chat equivalent and are easy to underweight in a shared test plan.
• Voice content needs writing for speech specifically, shorter and more carefully paced than chat content, not simply the same answers read aloud.
• Chat can usually launch a narrower initial scope more cheaply, since there is no telephony dependency gating the pilot.
• Voice's failure and escalation paths need more explicit design work, since there is no chat-equivalent fallback of simply waiting for a typed reply — a silent or stalled call reads very differently to a caller than a delayed chat response does.

What can compress or extend the ninety days

Being realistic about what actually changes the calendar, since ninety days is a planning structure, not a fixed promise.

• Existing, well-organised documentation compresses the content phase considerably; fragmented or contradictory source material extends it.
• Existing API access to relevant systems compresses integration; legacy or poorly documented systems extend it substantially.
• An existing telephony relationship and infrastructure compresses voice projects; a new telephony setup extends them, sometimes considerably.
• Available internal team capacity compresses every phase; competing priorities for the same people extend all of them.
• A narrowly scoped use case compresses the whole roadmap; an ambitiously broad one extends it and increases risk simultaneously.
• Regulatory or compliance review requirements, where they apply, can extend any phase and should be identified in phase one rather than discovered later.

None of these factors are predictable in the abstract — assess them specifically for your own organisation during phase one rather than assuming a generic ninety-day timeline will hold regardless of your starting conditions.

Data and tooling requirements across all phases

What needs to exist, cutting across the whole roadmap rather than any single phase.

• Access to real historical interaction data for the sampling in phase one.
• A test environment separate from production for phases four and five.
• Analytics covering resolution, escalation and unanswered questions, available from day one of the narrow launch.
• A rollback mechanism, tested rather than assumed, before phase five begins.
• CRM or system integration sufficient for the chosen use case's actual requirements, confirmed in phase three rather than assumed in phase one.
• A documented owner list covering content, integration, testing and operations, established in phase one and carried through to the ongoing rhythm in phase six.

Most of this should already exist or be straightforward to establish for a well-scoped single use case — if a genuine gap surfaces in any of these during phase one, that is worth resolving before the ninety-day clock starts in earnest. Our automation services page covers building these underlying connections where a platform does not provide them.

Common mistakes

These account for most of the difficulty in roadmaps of this kind.

• Scoping too broadly — attempting several use cases or several channels at once instead of one deployment done properly first.
• Setting the launch date before the baseline and sample are complete.
• Compressing the testing phase under schedule pressure.
• Widening scope during the narrow-launch phase instead of waiting for the evidence-based decision point.
• No operating rhythm established for after the ninety days, so the system degrades once the project team's formal involvement ends.
• For voice specifically, starting telephony work late instead of in phase one.
• Building the ROI case only once, before launch, rather than rebuilding it with real data at the end.

The scope-creep failure — attempting too much at once — is the single most common reason these projects run well past ninety days, and it is also the easiest to prevent by simply holding to the narrow use case selected in phase one.

Decision framework and next step

Four questions before starting the clock.

1. 1

   Have you chosen one narrow use case, or several at once?

   One, deliberately. Breadth comes from evidence gathered in phase six, not from an ambitious starting scope.

2. 2

   Is your baseline measured before any building begins?

   This is the single input every later comparison and ROI calculation depends on.

3. 3

   For voice, has telephony connectivity work started in phase one?

   It has the longest lead time in the whole roadmap and should never be left until late in the project.

4. 4

   Who owns the operating rhythm after day ninety?

   Name this person before launch, not after — an unowned system degrades quietly from the day the project team disbands.

Follow the six phases in sequence, hold the exit criteria set in phase one, and treat ninety days as a scope discipline rather than a fixed promise. Our AI solutions overview covers how this roadmap fits into a wider AI customer communication programme.

Frequently asked questions

1. 1

   What does this ninety-day roadmap actually cover?

   Six phases for taking one AI customer communication use case — chat or voice — from decision to a measured production deployment: scope and baseline, content and knowledge, integration, testing, a narrow launch, and measurement leading to a widen-or-hold decision.

2. 2

   Is ninety days a realistic timeline for every organisation?

   It is a planning structure, not a guarantee. Existing documentation quality, system access, telephony infrastructure and team capacity all compress or extend the actual calendar considerably — assess these specifically in phase one rather than assuming a fixed timeline applies.

3. 3

   Why should only one use case be scoped at a time?

   Scope creep across several use cases or channels at once is the most common reason these projects run well past ninety days. A single, properly executed deployment produces evidence and lessons that make the second one faster.

4. 4

   What changes for a voice deployment specifically?

   Telephony connectivity needs confirming in phase one rather than later, given its long lead time; testing needs real audio conditions; content needs writing for speech rather than reading aloud; and failure paths need more explicit design since there is no chat-equivalent fallback.

5. 5

   What happens after day ninety?

   An ongoing operating rhythm — weekly review of unanswered questions and escalation reasons, monthly content updates, named continuing owners — without which the system degrades quietly once the project team's formal involvement ends.

The value of this roadmap is in its sequence and its gates, not in the exact day count — hold the discipline of scoping narrowly, measuring before building, and deciding on evidence rather than on the calendar.