Migrate without a cut-over day.

How it works

Add SendAvata to your ping tree as a buyer with a zero bid — or as a second target that receives the request but is never selected. Every request arrives, SendAvata computes the decision it would have made, records it, and does nothing. Your current router keeps routing live calls.

In the console, Call ops shows each shadowed request next to what actually happened: who your current system routed to, and who SendAvata would have chosen. Differences are highlighted with the reason — presence, state, cover, priority.

What you're looking for

• Presence disagreements — your current router thinks an agent is online; carrier registration says otherwise. This is usually the biggest single finding.
• State gating — calls routed to agents not licensed for the caller's state.
• Cover — calls routed to agents whose wallet couldn't pay.
• Priority order — where your intent and your configuration disagree.

Cutting over

When a day's diff is empty or only contains differences you prefer, raise the bid and lower the old buyer's priority. You can do this per line. If anything looks wrong, drop the bid back to zero — shadow mode resumes instantly and no data is lost.

From BESO, Ringba-only, or spreadsheets

From an incumbent white-label, the migration is mostly re-pointing the ping tree and re-inviting agents to a portal on your domain. From Ringba-only, SendAvata adds the seat marketplace and wallet layer Ringba doesn't have. From spreadsheets, the first week is usually spent discovering how many "online" agents weren't.