Teams Phone rollouts: lessons from the field

Teams Phone (what Microsoft used to call Microsoft 365 Business Voice, and before that just "Teams calling") has matured significantly over the last couple of years. I've delivered several rollouts now, and the product itself is generally solid. The deployment is where projects go wrong.

The three deployment model decision

The first conversation in any Teams Phone project is about how PSTN connectivity is going to work. There are three main options:

Microsoft Calling Plans: Microsoft handles the PSTN connectivity. You buy calling plan licences, get phone numbers directly from Microsoft, and there's no on-premises telephony infrastructure required. The simplest model, but only available in certain countries and may not support all number types (particularly existing geographic numbers in some markets).

Direct Routing: You connect your own SBC (Session Border Controller) to Microsoft's infrastructure, and your SBC connects to your existing PSTN provider or SIP trunk. More complex, but supports more scenarios and gives you more control over routing.

Operator Connect: Microsoft-certified operators connect directly to Microsoft's network, so you don't need to manage an SBC yourself. It sits between Calling Plans and Direct Routing: simpler than Direct Routing but more flexible than Calling Plans.

Choosing the right model requires understanding the customer's existing telephony contracts, number types they need to retain, and geographic footprint. This decision has to be made early and correctly. Changing it mid-project is painful.

The number porting reality

If the customer has existing phone numbers they need to keep (and they almost always do), porting those numbers is the most time-consuming and frustrating part of any telephony project.

UK number porting requires engagement with the losing provider, correct completion of porting forms, and agreement on a porting date. The losing provider has financial incentives to not make this easy. Process compliance requirements mean there's a minimum timeline, typically two to four weeks for a straightforward port, longer for complex scenarios.

I've had porting projects where everything was right and it still took six weeks. I've had porting failures that required starting again. If you're migrating a 100-number estate, stagger the ports. Don't try to port everything at once. One failed batch shouldn't block the whole business.

Policy configuration is more complex than it looks

Teams Phone has a significant set of policies and configurations: dial plans, voice routing policies, emergency calling policies, call park policies, auto attendant and call queue configurations. Getting these right for an organisation with complex call handling (multiple sites, different business hours, complex call routing) takes time.

The best way I've found to manage this is to build the call flow design in a visual format that business stakeholders can sign off before you start configuration. Getting sign-off on a diagram is much easier than getting sign-off on Teams admin centre configurations.

What I tell customers going in

• Build in more time for number porting than you think you need. It almost always takes longer.
• Plan a parallel running period. Don't cut over to Teams Phone on the same day you port numbers. Give users time to get familiar with the Teams client for calling while the old system is still available as a fallback.
• Train users before go-live, not after. The transition from a physical desk phone to the Teams app is a bigger change for most users than IT professionals expect. A 30-minute training session before go-live pays dividends.
• Test emergency calling from every site before go-live. This is a regulatory requirement and a safety issue. Don't skip it.

Teams Phone is a good product. Get the deployment right and it shows.