Most SMB SaaS support teams running Intercom for chat, a separate KB tool, a third-party AI bot, and Calendly for bookings can consolidate to one helpdesk in 75 days — but only if they sequence the migration by data dependency. Knowledge base first (it seeds AI grounding), then chat (behind a feature flag), then booking (with calendar sync overlap), then AI bot in draft mode. A big-bang cutover breaks customer-facing URLs and wipes ticket history; a sequenced one doesn't.

Key takeaways

• The right order is KB → chat → booking → AI bot, because each phase produces the data the next phase needs to work well.
• Plan for 75 days, not 30: rushing the KB phase starves your AI bot of grounding content, and rushing the chat cutover breaks customer bookmarks.
• Run the old and new chat widgets in parallel for at least 14 days behind a percentage-based feature flag before flipping 100% of traffic.
• Calendar migration needs a two-week overlap where both Calendly and the new booking system accept reservations to avoid double-booking agents.
• AI bot should launch in draft mode (agent reviews every reply) for the first 30 days post-cutover before going autonomous on any channel.

Why sequencing beats a big-bang switch

A big-bang cutover — flip every tool on the same Monday — sounds clean and fails 80% of the time at SMB scale (estimate, based on the typical post-mortem pattern). The failure modes are predictable: the AI bot launches with no KB to ground against and hallucinates; customer bookmarks to support.yourcompany.com/articles/123 404 because the new KB uses different slugs; agents lose the chat history that was guiding their replies; and bookings collide because two calendars are still accepting slots.

Sequencing by data dependency avoids all of this. Each phase produces an artifact the next phase consumes:

• KB migration produces the article corpus the AI bot will ground on.
• Chat migration produces the conversation history the agent-assist feature learns from.
• Booking migration produces the agent availability data the routing logic uses.
• AI bot activation consumes all three.

Reverse the order and every step starves the next.

The 75-day timeline at a glance

Each phase has a hard exit criterion. You do not move on until the criterion passes. That's the single rule that keeps the timeline honest.

Phase 0: pre-flight audit (days 1–10)

Before touching anything, build four inventories.

1. Article inventory. Export every published KB article with its slug, publish date, view count, and inbound link count. Anything with zero views in 12 months is a candidate for archive, not migration.
2. Macro and saved-reply inventory. Most teams have 40–60 macros; half are duplicates or stale. Trim before you migrate.
3. Custom field inventory. Map every ticket field and customer field to its new home, including the type (text, dropdown, date, lookup). Dropdown options need a one-to-one mapping or your old tickets land in a half-populated state.
4. Integration inventory. Slack notifiers, Zapier zaps, webhook endpoints, SSO config, and any LOOKUP fields hitting your internal APIs.

The deliverable from phase 0 is a single spreadsheet with every artifact, its current home, its new home, and a person responsible. No spreadsheet, no phase 1.

Phase 1: knowledge base first (days 11–25)

KB goes first because the AI bot will ground on it, and because it has the longest tail of inbound links. Sequence inside the phase:

• Days 11–15: import. Use a markdown-friendly importer or an OpenAPI import if your KB documents an API surface. Helptal's knowledge base accepts markdown paste, .md file upload, and OpenAPI 3.x specs that auto-create one draft article per endpoint.
• Days 16–20: redirect map. This is the single most-skipped step in support migrations. For every old article URL, write a 301 redirect to the new slug. If you change your help center domain too, write the redirects at the DNS / CDN layer, not at the application layer — application redirects break when you point the domain.
• Days 21–23: SEO meta and sitemap. Set metaTitle, metaDescription, and noindex on any article that should stay private. Verify the auto-generated sitemap covers every published article.
• Days 24–25: AI grounding test. Upload internal-only docs (runbooks, escalation guides) as AI documents. Run 20 sample customer questions through the bot in test mode and check it cites the right articles.

Exit criterion: every article has a working URL (old or new), and 90% of test queries return a grounded answer with a correct citation.

Phase 2: live chat with parallel widgets (days 26–45)

Chat is the highest-stakes channel because customer conversations are happening in real time when you cut over. The pattern that works is a percentage-based feature flag on the widget snippet itself.

• Days 26–30: import historical conversations. A one-click Intercom or Help Scout import brings users, organizations, tags, tickets, and message threads with their original Message-IDs preserved — that last detail matters because it lets inbound email replies thread correctly into the migrated tickets.
• Days 31–35: deploy both widgets. Add the new widget snippet to your site. Behind a feature flag, route 10% of visitors to the new widget and 90% to the old one. Watch for JavaScript conflicts, CSS bleed, and agent presence issues.
• Days 36–40: scale to 50%. Once agents are comfortable in the new inbox and CSAT hasn't dropped, flip half. Train agents on macros, saved views, and assignment rules in parallel.
• Days 41–45: 100% cutover. Remove the old widget snippet. Keep the old tool in read-only mode for 30 more days so agents can look up historical context that didn't import cleanly.

Exit criterion: new widget handling 100% of new conversations, agent first-response time within 10% of pre-cutover baseline.

Phase 3: booking with calendar sync overlap (days 46–60)

Booking migrations fail when teams flip the public link on a Monday and discover Calendly is still accepting slots through old emailed links. The fix is overlap.

• Days 46–50: connect calendars. Each agent connects Google or Microsoft via OAuth so the new system reads busy/free correctly. Set per-agent weekly availability and any date overrides.
• Days 51–55: parallel acceptance. Both Calendly and the new booking page accept new reservations, but both read the same underlying Google/Microsoft calendar. Because both write events to the calendar, busy/free is the single source of truth and double-bookings can't happen.
• Days 56–58: redirect the public link. Point calendly.com/yourcompany to redirect to your new booking page (Calendly supports this in account settings, or use a marketing redirect). Update email signatures, the website footer, and any active outreach sequences.
• Days 59–60: deprecate Calendly. Cancel any new bookings on the old system, let existing ones run out.

Exit criterion: zero double-bookings in the overlap period, and all marketing surfaces pointing at the new link.

Phase 4: AI bot in draft mode (days 61–75)

The AI bot ships last because it depends on everything else. Launch it in draft mode — bot writes the reply as an internal note, agent reviews with Send / Edit & Send / Discard — for the first 30 days. This gives you a measurable accuracy baseline before any reply reaches a customer unsupervised.

• Days 61–65: draft mode on chat only. Email and web tickets stay agent-only. Measure: what percentage of drafts are sent as-is, edited, or discarded? Target >70% sent-as-is before progressing.
• Days 66–70: auto-reply on chat first message. Bot answers the first customer message; if the customer's next message indicates the bot got it wrong, route to a human and tag for review.
• Days 71–75: expand to email if accuracy holds. Per-brand opt-in, off by default. Conservative teams keep email in draft mode permanently — and that's a defensible choice.

Exit criterion: bot accuracy ≥70% sent-as-is, CSAT no worse than pre-migration baseline.

The cutover checklist that prevents downtime

Before you flip any phase to production, run this checklist:

• DNS / CNAME records propagated and verified (DKIM included)
• Custom domain SSL cert active
• Redirects for every changed URL tested with curl -I
• Webhook endpoints receiving test events with valid HMAC signatures
• SSO flow tested for at least one agent on each role (Owner, Admin, Agent, Read-Only)
• Email forwarding verified by sending a real test message end-to-end
• Suppression list imported so you don't email previously-unsubscribed contacts
• Backup export of the old tool downloaded and stored
• Rollback plan documented (how to flip back in <1 hour if something breaks)

How Helptal fits in

This playbook works against any consolidated helpdesk, but it lines up unusually cleanly with Helptal because all four surfaces ship in one workspace. Support tickets covers the shared inbox plus the Intercom / Help Scout / Zendesk one-click import that preserves Message-IDs for threading. Live chat covers the widget and proactive rules. Knowledge base handles markdown import, OpenAPI import, and the SEO meta you need to keep search rankings during the redirect phase. AI automation ships the draft-mode bot grounded on your KB. And appointment booking is bundled free on every paid plan — no separate Calendly subscription needed.

Frequently asked questions

How long does it take to consolidate a multi-tool support stack into one helpdesk?

For a 5–15 agent B2B SaaS team, the realistic timeline is 75 days from kickoff to AI bot in full production. Smaller teams (3–5 agents) can compress to 50 days because they have fewer macros, custom fields, and integrations to migrate. Larger teams (15+ agents) should plan for 90–120 days because change management becomes the bottleneck, not the technical migration.

Should I migrate the knowledge base or live chat first?

Knowledge base first, always. The KB articles are what the AI bot grounds on, so if you migrate chat first and turn on the bot, it has nothing accurate to cite. KB also has the longest tail of inbound links from Google and from your own product, so it needs the longest redirect runway. Chat conversations from the last 30 days are the only ones agents reference often; older ones can stay read-only in the old tool.

How do I prevent broken bookmarks when migrating my help center?

Build a one-to-one redirect map from old article URLs to new ones before you cut over DNS. Implement the redirects at the CDN or DNS layer rather than the application layer, because application redirects break the moment you point the domain at the new system. Keep the redirects live for at least 12 months — that's roughly how long it takes Google to fully recrawl and reindex a migrated KB.

Can I replace Intercom chat and Calendly with one tool?

Yes, if the tool bundles both natively rather than gluing them together via Zapier. The bundled approach is the whole point — you get one set of customer records, one inbox, one routing logic, and shared agent availability across chat and booking. The 75-day playbook above is specifically designed for teams making that consolidation, with calendar sync overlap during the Calendly cutover so agents don't get double-booked.

What's the safest way to turn on an AI bot for customer support?

Draft mode for the first 30 days, then auto-reply on chat (lowest-stakes channel) only after draft acceptance hits ≥70% sent-as-is. Email stays in draft mode for at least another 30 days because email replies are searchable forever and harder to walk back. Conservative teams keep email permanently in draft mode and only auto-reply on live chat, which is a defensible position for any B2B SaaS where one wrong answer can damage a high-MRR relationship.

The one thing to do this week: build the phase 0 inventory spreadsheet. Every successful consolidation we've seen starts with a single artifact-by-artifact audit of what's in your current stack, where it goes, and who owns the move. If you're evaluating tooling for the migration, Helptal's free plan gives you a working sandbox to import a sample of KB articles and conversations before you commit to the full sequence.