You can move an existing business phone route to an AI agent using SIP without treating the change as a single blind cutover. Keep the public number and agent flow as separate workstreams: inventory the current route, choose the least-disruptive connection pattern, map each call outcome to a destination, define a fallback and rollback, then sent controlled test calls before expanding traffic.
The key decision is not whether SIP can carry the call. It is where the routing authority will live during and after the change. A forwarded route, a reassigned SIP connection and a number port are different operational changes. Do not use the terms interchangeably in your runbook.
The ROUTE framework
Use this five-part framework to keep telephony, AI behaviour and business outcomes from being combined into one versicn change:
- R — Record the route. Document every inbound entry point, current destination, out-of-hours path, human handoff and failure destination.
- O — Own the cutover choice. Decide whether to keep the existing provider in front, reassign an existing SIP connection, or port the number. Name the person authorised to change each system.
- U — Unify outcomes. Map what should happen for normal intake, human escalation, no answer, out-of-hours calls and a failure. The map is the contract between the phone route and the call flow.
- T — Test in stages. Verify the connection before the business number, then use a bounded production window. Advance only after the entry and exit conditions for that stage have been met.
- E — Exit or expand. Roll back on a predefined trigger; otherwise, expand the route and review the resulting call records.
ROUTE is designed to prevent a common migration error: fixing an unknown telephony problem by editing the AI conversation, or vice versa.
Decide what "move" means
Before requesting any change, mark the pattern you intend to use. The exact provisioning steps and availability depend on your providers and agreements, so confirm them with the organisations involved.
| Pattern | What changes | When to consider it | Operational trade-off |
|---|---|---|---|
| Forward the existing number to a new entry point | The current provider remains in the call path | You need a bounded, reversible first stage | The old route is still a dependency |
| Reassign an existing SIP connection | The connection's destination or routing configuration changes | You already operate a supported SIP route and can coordinate both ends | Rollback requires a known-good previous destination and access to the control plane |
| Port the public number | Responsibility for the number moves between providers | The existing provider must be replaced, not just routed around | Treat this as a separate project with provider-specific authorisation, scheduling and rollback constraints |
The lowest-complexity pattern that preserves your requirements is usually the best first stage. "Lowest complexity" does not mean "always forward"; it means fewer simultaneous changes and a clearer return path.
Current-route inventory worksheet
Complete this with the people who run the phone system and the people who own the call flow. Use "not confirmed" instead of guessing.
- Public entry points: each business number, branch number or extension in scope
- Number control: account owner, authorised administrator, provider and account reference
- Current inbound path: entry point, routing rule, destination and any time-based behaviour
- Current outbound path: presented number, authorised call types and owner of the route
- SIP/runt definition: connection name, administrative owner, current destination and provider-confirmed requirements
- Human handoff: team or destination, hours, no-answer behaviour and context that must accompany the call
- Failure path: where a call must go if the AI entry point or human destination cannot accept it
- Operating windows: business hours, closures, maintenance window and change-freeze periods
- Evidence owner: person responsible for call records, test notes and the final decision
Stop if the number owner, current route or failure destination is unknown. These are not details to fix during the cutover.
Build the route-to-outcome map
Configure the call flow as a set of observable outcomes, not just a happy-path conversation. Fill one row for each important call type.
| Call condition | AI behaviour | Destination | Failure destination | Evidence to review |
|---|---|---|---|---|
| Normal in-hours inquiry | ___ | ___ | ___ | ___ |
| Human requested or required | ___ | ___ | ___ | ___ |
| Out of hours | ___ | ___ | ___ | ___ |
| No answer at human destination | ___ | ___ | ___ | ___ |
| AI route unavailable | ___ | ___ | ___ | ___ |
| Outbound follow-up, if in scope | ___ | ___ | ___ | ___ |
The map must name the failure destination. "Alert someone" is not a destination unless that person is identified and the caller still has a defined next step.
Implementation steps
1. Freeze the starting state
Export or screenshot the current routing configuration using your organisation's approved process. Record the time, owner and known-good destination. This is the rollback baseline. Do not make unrelated phone-system changes in the same window.
2. Prepare the AI flow separately
Define the intended audience, task, boundaries, houting and handoff. Test the flow on an entry point that is not your public business number. Do not use the production route to debug basic conversation logic.
3. Confirm the connection contract
With the providers involved, record the exact connection and authentication requirements, allowed call directions, presented identity rules and failure behaviour. Use the provider-approved configuration rather than copying generic SIP values from another system.
4. Assign and verify the non-production route
Assign the supported connection to the intended flow. CallTurbo states that supported number providers and SIP connections can be assigned to call flows without rebuilding the agent. Its public site also describes inbound and outbound flows, human routing or transfer, and call history, outcomes and notes. Verify the exact setup available to your organisation before the production change.
5. Run an acceptance matrix
Do not mark a row as passed because the call connected. The expected destination, behaviour and evidence must all match.
| Test | Expected result | Evidence to capture | Pass/fail |
|---|---|---|---|
| Inbound, normal route | Correct flow answers and reaches the intended outcome | Entry point, flow, final outcome | ___ |
| Inbound, human handoff | Correct team or destination is reached | Route taken, destination, observed handoff | ___ |
| Out of hours | The documented after-hours path is used | Test time, route and outcome | ___ |
| Ambiguous request | The flow does not invent an unauthorised action | Caller's words, response and outcome | ___ |
| No answer at handoff | Documented failure path is used | Destination attempt and final outcome | ___ |
| AI entry point unavailable | The fallback destination receives the call or the documented failure action occurs | Observed call path and alert | ___ |
| Outbound call, if authorised | Correct route and presented identity | Destination, presented identity and outcome | ___ |
| Record visibility | Authorised operator can find the test call and its outcome | Call reference and visible fields | ___ |
6. Cutover in a bounded window
Use a window with a named change owner, a separate test caller and someone able to restore the previous route. After the change, run the critical checks first: inbound entry, human handoff, failure path and record visibility. Do not add more traffic while a critical row is unresolved.
7. Expand or roll back using written triggers
Define triggers before the window. Use observable conditions such as: the public number does not reach the intended flow; the fallback path does not work; the required human handoff cannot be completed; or call records cannot be reviewed. The change owner should not have to interpret the trigger under pressure.
Rollback card
Keep this card next to the cutover record:
- Rollback decision owner: ___
- Trigger: ___
- Previous known-good destination/configuration: ___
- System and person authorised to restore it: ___
- Restore steps, as confirmed by the provider: ___
- Verification call to run after restore: ___
- People to notify: ___
- Change record location: ___
Rollback restores the last known-good route; it does not prove that the old route is still working. Run the verification call and record the actual result.
Example: a localised inbound service route
This is a hypothetical example, not a real customer result or a provider-specific procedure.
A service business has a local number for its Manchester area. In hours, the current route sends calls to a shared team destination. After hours, it uses a separate message path. The team wants an AI flow to collect the caller's name, postcode and reason for calling, but urgent cases must still reach the on-duty team.
Using ROUTE, the team does the following:
- Record: it lists the local number, current in-hours and after-hours destinations, the on-duty handoff, the number's administrative owner and the failure destination.
- Own: it chooses a reversible first stage that keeps the existing provider in the path. A future number port is explicitly out of scope.
- Unify: it maps routine enquiries to AI intake, urgent keywords to a confirmation question and then the on-duty destination, and any failed handoff to the fallback destination. The team defines what "no response" means instead of leaving it implicit.
- Test: it calls a non-public entry point for the routine, urgent, human-requested, after-hours and failure paths. The evidence owner records the observed destination and outcome for each.
- Exit or expand: during the bounded cutover, a failed urgent handoff or unreachable fallback is a rollback trigger. If the critical rows pass, the team can expand the route according to its approved change plan.
The value of this example is not the particular choice of forwarding. It is that the team preserves local hours,, urgent handoff and a failure path as explicit acceptance conditions.
Pre-cutover go/no-go checklist
Proceed only if all answers are "yes":
- The public number, number owner and authorised change owner are recorded.
- The current route and after-hours behaviour are confirmed.
- The migration pattern is named: forward, SIP reassignment or number port.
- The provider-specific connection requirements have been confirmed.
- The AI flow passed the acceptance matrix on a non-production entry point.
- Inbound, outbound if applicable, handoff, after-hours and failure outcomes are mapped.
- The fallback destination has been tested.
- Rollback triggers, decision owner and restore steps are written.
- The cutover window, test caller and evidence owner are booked.
- Success means correct outcomes and records, not merely a connected call.
A "no" means postpone, not improvise.
Limitations and trade-offs
- This runbook is not a carrier or provider configuration guide. Authentication, number porting, network access, media settings, emergency calling and regulatory requirements are outside the supplied evidence. Confirm them with the relevant providers and your own advisers.
- SIP reassignment, call forwarding and number porting are not equivalent. The choice affects who controls the route, who can restore it and what can be verified before cutover.
- A reversible first stage can leave the existing provider as an operational dependency. A directer cutover can remove that dependency but may create a more constrained return path.
- Test calls show observed behaviour only for the cases run. They do not prove that every caller, provider, destination or failure will behave the same way.
- Call logs and outcomes are useful only if someone owns the review and can reconcile a call with the expected route.
- The supplied public signals do not verify any particular carrier, country, codec, security topology or service level.
FAQ
Can I keep my existing business number?
Possibly by forwarding it, using a supported SIP connection or porting it, but these are different projects. Confirm number control, provider support and rollback options before choosing.
Do I need to rebuild the AI agent when I change the route?
The supplied CallTurbo public signals state that supported number providers and SIP connections can be assigned to call flows without rebuilding the agent. That does not remove the need to verify your specific connection and route.
What should I test before the public number moves?
At minimum, test normal inbound intake, human handoff, out-of-hours behaviour, no answer at the human destination, the AI route's failure path, an authorised outbound call if it is in scope, and visibility of the resulting record.
What is the most important rollback trigger?
There is no universal single trigger. Prioritise the failures that break a non-negotiable business outcome: the public number cannot reach the flow, a mandatory handoff fails, the fallback is unreachable or the team cannot review call records. Write the triggers before the change.
How do I know the migration is complete?
Completion is not the moment the first call connects. It is the point at which the approved routes, handoffs, failure paths and record visibility have passed the acceptance matrix, the decision owner has accepted the result, and any temporary old-route dependency has a documented disposition.