Cutting Over From a SaaS Support Bot to a Custom Agent Without a Gap

Don't rip and replace

The SaaS bot you want to move off is deflecting real volume right now. Turn it off before the custom agent is proven and you get a queue spike on top of a migration. The way to migrate a support bot to a custom agent without a gap is to run both, shift work gradually, and keep a fast way back.

Run both in parallel first

Route by ticket type. The SaaS bot keeps the pure-FAQ deflection it's genuinely good at. The custom agent takes the transactional tickets it was built for — order status, returns, refunds — where your data and rules matter. Nothing is switched off; the custom agent is just added alongside.

Instrument the gap

Log every ticket the SaaS bot couldn't resolve, tagged by type. That log is two things at once: the scoping data for what the custom agent needs to handle, and later, the regression set you test it against. If the SaaS bot's logs aren't exportable, you've found a lock-in cost worth knowing about.

Cut over one category at a time

Order status first. Once its containment and error rate hold for a couple of weeks, add returns. Then refunds. Each category graduates on its own numbers, not a calendar date. On our support agent project the transactional categories — where's my order, returns, refunds — were exactly the phased scope, and containment landed around two-thirds once all three were live.

Keep the SaaS bot for the long tail

Pure informational deflection — "how does sizing work," "where's your size guide" — is where a retrieval bot over a good help centre is simple, cheap, and enough. You don't have to replace 100% to get the value.

The rollback plan

A feature flag per ticket type. If the custom agent's error rate spikes on refunds, the flag routes refund tickets back to the SaaS bot or straight to humans while you fix it. A migration without a rollback is a bet, not a plan.

The parallel-run checklist

Before you shift a single ticket, have these in place:

• A per-ticket-type routing switch — the mechanism that sends "order status" to the custom agent while "sizing questions" stay with the SaaS bot.
• Logging of every unresolved SaaS-bot ticket, tagged by type — this is your scoping data and, later, your regression set.
• An evaluation set built from those logs — real historical tickets with a known correct outcome, so a change to the custom agent is measured, not felt.
• Per-category dashboards for containment and error rate, watched daily during a cutover.
• A defined rollback trigger — "error rate on this category above X for two days routes it back" — decided before you need it.
• A named owner for the go/no-go on each category, so the decision to advance isn't a committee.

Don't run the cutover in peak season

A phased migration needs weeks of calm observation per category. Starting it in the run-up to Black Friday means you're changing the thing that handles your highest volume at the moment it's highest, with no slack to watch it. Finish the migration before peak, or pause it until after — a half-migrated queue going into peak is the worst of both.

Where this stops being right

• A punitive SaaS exit clause or minimum term means the parallel-run period costs double for a while — budget it or time the cutover to the renewal.
• A very small queue may not justify the phased approach — switch, watch closely, and keep the rollback flag.
• Non-exportable SaaS logs cost you the scoping data — you'll rebuild it from your own ticketing system instead.

FAQ

Do we have to replace the whole bot? No. Keep it for pure FAQ deflection. The custom agent takes the transactional tickets where your data and rules decide the outcome.

How long should the parallel run be? Long enough to cut over each ticket category and watch it hold — weeks per category, not a weekend.

What's the rollback? A routing flag per ticket type that sends that category back to the SaaS bot or to humans if the custom agent's error rate spikes.

ISTRALLEN builds custom support agents alongside your existing bot and cuts over category by category; see AI for E-commerce.