The Enterprise Guide to Microsoft Teams Voice at Scale

Microsoft Teams is now the de-facto UC platform for UK enterprise and public-sector IT. Chat and meetings rolled out during 2020–2022 with little debate. Teams voice is a different proposition: the moment Teams becomes the corporate dial tone for an 800-user NHS Trust, a 3,000-seat university, or a council contact centre answering statutory enquiries, the conversation stops being about collaboration and becomes carrier-grade telephony — with the resilience, regulatory and operational obligations that brings.

This guide is the conversation we have with CIOs and IT Directors before contracts are signed. The question is not whetherto put voice into Teams but how to do it without trapping the organisation on the wrong carrier, licence mix or architecture. Where there is a defensible best practice we say so; where the answer is "it depends", we say what it depends on.

1. Teams Phone, Direct Routing and Operator Connect

Microsoft offers three commercial routes to turn Teams into a telephone system. They are not interchangeable: the choice determines who owns the carrier relationship, where the SIP trunks land, how you handle emergency calling, and how much architectural freedom you retain.

Microsoft Teams Phone (Calling Plans)

Microsoft sells you the PSTN directly. You buy a Teams Phone licence plus a Calling Plan bundle, Microsoft becomes your carrier, and numbers come from Microsoft’s inventory. This is the fastest path to live and the cleanest commercial story — one bill, one vendor. The trade-off is control. Routing is largely opaque; integration with contact centres, analogue endpoints, site-specific PSTN breakout or non-Microsoft carriers is awkward or impossible; and country coverage, while improving, is still patchier than UK-native carriers. For an estate under about 300 users in a single country with no contact centre, Calling Plans are often the right answer. Above that, the constraints begin to bite.

Direct Routing

Direct Routing is the "bring your own carrier" model. You (or a partner like Beckett) operate a pair of Session Border Controllers — typically AudioCodes, Ribbon or Oracle — certified against Microsoft’s qualified-SBC list. Those SBCs sit between Teams and one or more SIP carriers, terminating TLS signalling and SRTP media on the Microsoft side and presenting standard SIP/RTP to the carrier side. Everything is yours: which carriers you use, how calls are routed, how numbers are managed, how analogue devices and legacy gateways are interworked, how survivability is achieved. This is the path almost every estate above 800–1,000 users ends up on, because it is the only model that lets you make architectural decisions without asking permission from Microsoft.

Operator Connect

Operator Connect is Microsoft’s answer to the question "can we have the simplicity of Calling Plans but with a real UK carrier?" A Microsoft-approved operator becomes the carrier; you provision numbers and routes from inside the Teams Admin Centre as if it were Calling Plans, but the underlying PSTN is delivered by the operator on commercial terms you negotiate with them directly. There are no SBCs to operate. The trade-off is still control: routing is constrained, contact-centre integration is partner-dependent, and the data plane is owned by Microsoft. Operator Connect is an excellent fit for 500–1,500 user estates that want a UK carrier without running infrastructure — and a poor fit when the requirements include bespoke routing, regulated recording, or coexistence with a legacy estate during migration.

2. How to scale Teams voice beyond 1,000 users

The architecture that worked for 300 users does not gracefully extend to 3,000. Most of the pain in enterprise Teams voice programmes happens in the gap between 800 and 1,500 users, where the assumptions of a smaller deployment quietly stop being true and nothing obvious tells you. Scaling well is about capacity planning the elements that matter, designing the routing fabric so it can absorb growth, and being honest about which constraints are real.

SBC capacity and sizing

Session Border Controller sizing is governed by concurrent calls, not registered users. The standard planning ratio for a knowledge worker estate is roughly 1 concurrent call per 10–15 users in normal operation, climbing to 1 in 4 for contact-centre-heavy organisations like councils and NHS Trusts. A 1,200-user Trust with a 90-seat contact centre is therefore not a 1,200-call problem — it is a roughly 150–200 concurrent-call problem at peak, with the contact centre making up the bulk of it. SBC pairs should be sized for full single-side load with comfortable headroom: if either side fails, the survivor should carry busy hour without breaking sweat.

Media optimisation

By default, Teams routes media via Microsoft’s transport relays, which is fine for collaboration but adds latency and burns bandwidth on PSTN calls. For deployments above 1,000 users you want Media Bypass enabled where possible, so that media shortcuts from the Teams client directly to the SBC. For multi-site estates, this needs to be combined with Location-Based Routing so that a call originating in your Cardiff office breaks out through a Cardiff-adjacent SBC and number range, not via a London PoP. Get this wrong and you will spend the next twelve months explaining one-way audio tickets that nobody can consistently reproduce.

Number management at scale

At 1,000+ users, number management stops being a spreadsheet problem and becomes a database problem. DDI ranges need to be tracked against sites, departments, cost centres, emergency services routing identifiers, and porting status. Microsoft’s built-in number management is adequate for Calling Plans estates; it is not adequate for a multi-site Direct Routing estate spanning multiple carriers, and most enterprises end up with a dedicated number management platform that feeds Teams via PowerShell or Graph.

Location-Based Routing (LBR) and emergency calls

UK organisations have specific obligations around 999. Calls must present a number associated with the caller’s physical location, and emergency services must be able to call back to that location. For multi-site deployments this needs Dynamic Emergency Calling (the same Microsoft capability marketed as Dynamic E911 in the US, applied to UK 999 routing) configured against your network sites, with subnets, BSSIDs and switch ports mapped to civic addresses. NHS Trusts and councils increasingly require this to be tested as part of acceptance.

3. Resilience architecture

Voice resilience is not application resilience. When a CRM goes down for six minutes, users are annoyed; when the dial tone goes down on a council’s adult social care line, somebody is in serious trouble. A good Teams voice estate is built so that no single failure — fibre cut, SBC firmware bug, carrier outage, data centre power event — can take the estate off the air. The patterns are well-understood.

Active/active SBC pairs across two UK data centres

The minimum credible posture is two SBCs in each of two geographically separated UK data centres, all four active, with Teams configured to load-share across the pair. Either site can absorb the full estate. Firmware upgrades are performed one side at a time, in production, without scheduled downtime.

Carrier diversity

Two SIP carriers, terminated into different physical PoPs on different fibre paths. Carrier A as primary in Data Centre A and failover in Data Centre B, Carrier B mirrored — so that the loss of an entire carrier does not coincide with the loss of an entire site. This is not theoretical: every major UK SIP carrier has had a multi-hour outage in the last few years. The estates that shrugged those outages off were the ones with a second carrier already live and tested.

Routing fabric

The SBC layer should hold the routing logic — least-cost, location-based, time-of-day, emergency override — not the carrier and not Teams. This keeps the architecture portable: when a carrier is replaced, the routing logic does not move. It also means that the number plan is contractual, not architectural — you ported in, you can port out, the rest of the design does not care.

4. Call survivability

Resilience handles failures inside the voice estate. Survivability handles the day Microsoft 365 itself is unreachable, or the WAN drops at a single site. A major incident plan that depends on Microsoft 365 being available will not survive contact with the day Microsoft 365 isn’t.

Survivable Branch Appliance (SBA)

For sites where loss of dial tone is unacceptable — a hospital switchboard, a 24/7 council emergency line, a campus security desk — Microsoft and its SBC partners offer the Survivable Branch Appliance pattern. An on-site appliance registers with Teams in normal operation; when the WAN or Teams service is unreachable it takes over, with Teams clients on that subnet failing over to the SBA, which routes calls directly to a local PSTN breakout. Inbound numbers can be re-pointed at the local breakout by the carrier on scripted failover.

What you actually get during a Microsoft outage

Be honest with the business about what survivability does and does not give you. With a properly designed SBA, sites retain the ability to make and receive PSTN calls, including 999. You do not retain Teams chat, presence, voicemail, call queues, auto-attendants, or any feature that depends on Microsoft services. For most sites this is exactly the right trade. For a handful of operationally critical sites — a Trust switchboard, a council’s adult-services line — you may want to additionally keep a small set of analogue or SIP endpoints permanently registered to the SBA, so that there is no dependency on the failover script working under stress.

5. Disaster recovery strategy

Voice DR is poorly served by the templates that exist for applications and data — there is no "restore from backup" for a dial tone. The objectives that matter are RTO for major failures and MTTR for individual incidents.

RTO and RPO for voice

A well-designed Direct Routing estate has an effective RTO of zero for most failures, because active/active SBC pairs and dual carriers mean there is no recovery to perform — traffic simply stays up on the surviving path. The RTOs that matter are for the slow failures: SBC platform loss, total carrier withdrawal, number range repatriation. Realistic targets are 4 hours for full SBC platform rebuild on standby hardware, 24 hours for emergency carrier migration on a number range, 5–10 working days for full porting between carriers. RPO for voice is largely a recording and CDR question — see security and contact centre below.

Tested runbooks, not paper plans

Voice DR runbooks should be tested annually under realistic conditions, not desk-walked once and signed off. The two worth rehearsing are (a) loss of a primary SIP carrier for an extended window, including the conversation with the secondary about absorbing diverted traffic, and (b) loss of an entire data centre. The DR scenarios that go badly are the ones that have never been tested.

6. SIP trunk architecture

Behind every Direct Routing estate is a set of SIP trunks carrying calls between the SBCs and the PSTN. How those trunks are designed determines a surprising amount about day-to-day reliability and strategic optionality.

Carrier choice

UK enterprise SIP is a small market — perhaps a dozen carriers worth considering above 1,000 users. They differ on geographic number coverage, emergency-services routing maturity, porting performance, commercial flexibility, and out-of-hours operations. Beckett is carrier-agnostic and recommends based on the estate: a multi-academy trust spanning 60 sites has different needs from a single-site financial services business in the City.

Redundant trunks, geographic PoPs

The architectural rule is that no single trunk and no single PoP is a single point of failure. In practice this means at least two SIP trunks from at least two carriers, terminating into PoPs in at least two cities. For very large estates a third carrier is reasonable insurance, particularly where the second carrier is needed for international or specialist routing.

Number porting

Number porting in the UK is governed by Ofcom and operated through inter-carrier process. It is reliable but not fast: 5–10 working days for straightforward ports, longer for complex arrangements involving multi-line geographic ranges, FCS-related ranges, or contested numbers. Porting strategy matters because it is the lever that keeps you commercially honest with carriers. An estate where every number is ported is an estate that can move carrier without architectural pain. An estate built on a single carrier’s numbering plan is an estate with a hidden five-figure switching cost.

7. Security and fraud prevention

Voice security is one of the most neglected areas of enterprise unified communications. There is a comfortable assumption that Microsoft handles it because Microsoft handles Teams. That is not the case at the SIP perimeter. Direct Routing estates expose a SIP-aware attack surface that is fundamentally a telecoms problem, not an Office 365 problem, and it needs to be defended with telecoms thinking.

Toll fraud

Toll fraud — unauthorised use of a voice estate to call premium-rate or international destinations — remains a material annual loss across UK enterprise. The attack pattern is well-understood: a compromised account, a misconfigured route, a weekend, calls to premium-rate numbers where the attacker takes a cut of the termination fee. Defence has three layers: international and premium-rate barring on by default (opt-in per user); per-user and per-trunk concurrent call limits; and anomaly detection on volume, destination and time-of-day. Alerting needs to fire inside minutes, not the next business day.

SBC hardening

SBCs are internet-facing infrastructure and deserve the same posture as any other internet-facing service. TLS 1.2 minimum on the Microsoft side, SRTP for media, signed certificates from a recognised CA, strict IP allowlisting where carriers support it, SIP-aware rate limiting against REGISTER and INVITE floods, and a clear separation of management plane from media plane. Firmware patching is operational hygiene; treat SBC firmware advisories with the same urgency as server CVEs.

Recording and compliance

For regulated sectors — financial services under FCA, NHS for clinical and safeguarding records, councils for adult-services calls — recording is a compliance requirement, not a feature request. Recording architecture matters because the lawful basis for the recording usually requires that it be tamper-evident, access-controlled and retained for a defined period. Teams-native compliance recording works for many use-cases; integrated platforms (Verint, NICE, Red Box and others) are needed where the requirements include richer screen recording, MiFID-II-grade evidence or contact-centre quality monitoring.

8. Licensing optimisation

Microsoft licensing at scale is where most Teams voice programmes quietly overspend. Above 1,000 users, a casual licensing posture costs six figures a year; a deliberate one frees that money for things that actually matter.

Teams Phone Standard vs the E5 bundle

Teams Phone Standard is a per-user add-on; Microsoft 365 E5 includes it. The right answer depends on whether you would buy E5 anyway for the security, compliance and analytics capabilities. For organisations that genuinely use E5’s advanced security stack, the marginal cost of Teams Phone is effectively zero and E5 is the right answer. For organisations on E3, layering Teams Phone Standard on top is usually cheaper than uplifting to E5 just for voice — and you can mix, putting E5 on the IT, security and executive populations and E3 + Teams Phone on everyone else.

Common Area Phones and Shared Calling

Reception phones, meeting room phones, ward handsets, shared workstations — none of these need a full Teams Phone licence. Microsoft’s Common Area Phone licence and the more recent Shared Calling plan are cheaper per endpoint and exist for exactly this reason. A 1,500-user estate typically has 200–400 such endpoints that should not be on user licences. Auditing them is one of the highest-ROI exercises in any first 90 days of platform ownership.

Right-sizing user licences

Not every user needs full Teams Phone. Hot-desking populations, seasonal workers, contractors with short engagements, and non-customer-facing staff in sectors where voice is rarely used can often be served by Teams chat and meetings alone, with PSTN access granted on request. The discipline here is licence governance: a quarterly review of who has what, with auto-revoke on extended inactivity, will return a measurable percentage of spend every cycle.

9. Integrating legacy PBX during migration

The enterprise cannot rip out the old PBX on Friday and turn on Teams on Monday. Clinical systems are wired into the Avaya; analogue lift lines and fire panels sit on the Mitel; the Cisco UCM is tied into patient flow; the Unify (Siemens) estate has its own integrations. Migration is a choreography, not a flag day.

Phased coexistence

The pattern that works is hybrid SIP between the legacy PBX and the SBC, with users migrated in waves while both systems remain live. The SBC fronts both: Teams users on the new side, legacy users on the old side, with inter-working between the two so that internal dialling continues to work transparently. As waves of users migrate, the legacy PBX shrinks until it can be retired. Wave size is the lever: small enough that any single wave can be rolled back without drama, large enough that momentum is maintained.

Avaya, Mitel, Cisco, Unify — the practical differences

Each legacy estate has its own gravitational mass. Avaya CM/Aura estates are usually rich in SIP already, so interworking is easy; the challenges sit in the application layer (Modular Messaging, CM features Teams doesn’t natively replace). Mitel MX-One and MiVoice estates are common in UK councils and the NHS, often deeply tied to analogue and DECT; an analogue gateway strategy is required. Cisco UCM estates are the most complex on the application side — UCCX/UCCE, Unity, Jabber — and coexistence windows are longer because of the contact centre. Unify OpenScape estates are fewer in the UK but distinctive: integration patterns are understood, but attendant-console replacement needs careful design.

Number porting choreography

Numbers move when users move, not before. The cadence is: build the wave, port the user’s DDI from the legacy carrier to the Direct Routing carrier on the agreed cutover date, flip the user’s endpoint, monitor for inbound and outbound behaviour for 24 hours, close out. A wave of 50–100 users per week is sustainable for a competent team; bigger waves are possible but compress the recovery window if anything goes wrong.

10. Contact centre considerations

Contact centre is where Teams voice projects most often run aground. Teams call queues and auto-attendants are fine for departmental answering, but not for a council customer service centre handling thousands of calls a day across council tax, housing, planning and adult services — with skills-based routing, supervisor barge, wallboards, compliant recording and workforce management.

Teams-native CCaaS vs integrated platforms

Two architectural models exist. The Teams-native model ("Extend") sees the CCaaS vendor — Genesys, NICE, Five9, Anywhere365 and others — integrate as an application within Teams, using Teams users as agents. The integrated model ("Connect") places the contact centre alongside Teams, with PSTN delivered through the contact centre and handed to Teams agents over SIP. The right choice depends on whether the contact centre and the wider UC estate are best treated as one platform or two.

Agent licensing

Agents typically need Teams Phone or its equivalent plus a CCaaS agent licence. This is often the largest line in the licensing schedule for a council or NHS Trust contact centre; keeping it right as the agent population fluctuates is the difference between predictable cost and quarterly surprises.

Recording, quality and compliance

For regulated contact centres — FCA, GDPR-sensitive housing cases, clinical referrals — recording, retention, access control and search are not optional. Architect the recording platform around the retention obligation first, the search and review workflow second, and the storage cost third.

11. Common mistakes in enterprise Teams voice rollouts

Most failed or stalled Teams voice programmes fail for the same small set of reasons. None of them are technically interesting. All of them are avoidable.

1. Treating Teams voice as a Microsoft 365 project. Voice is a different discipline from Office workloads. Get telecoms expertise into the room from day one.
2. Sizing for users rather than concurrent calls. SBCs, trunks and carrier commitments are sized in concurrent calls. User-count plans routinely undersize contact-centre populations.
3. Ignoring emergency calling until the end. Dynamic Emergency Calling and LBR depend on subnets, switch ports, wireless infrastructure and civic addresses the M365 team does not own. Start in week one, not week twelve.
4. Single-carrier dependency. Any estate above 1,000 users should be dual-carrier from day one, with both paths carrying real traffic — not an untested standby trunk.
5. Underestimating contact centre. "We’ll use Teams call queues for now" has caused more programme overruns than any other sentence. Scope a real contact centre as a real workstream.
6. De-scoping survivability. SBA is often cut on cost, then quietly reinstated after the first significant outage. Build it in from the start for switchboards and emergency lines.
7. Defunding the legacy PBX too early. Coexistence windows are 12–18 months. Keep the maintenance contract live for the whole period.
8. Forgetting the analogue tail. Lift lines, fire panels, door entry, cardiac alarms, dispersed alarms in social housing — inventory and plan analogue gateways before they surprise you.
9. Skipping number management. A spreadsheet survives 300 users, not 3,000. Invest in a proper number platform before it becomes a liability.
10. No formal acceptance gate per wave. Each wave needs pass/fail criteria — MOS, emergency calling, recording, voicemail. Without them, problems accumulate silently.
11. Headset and endpoint neglect. Standardise on a small set of certified devices and roll them out alongside the voice service.
12. Treating the rollout as a project, not a service. The platform still needs patching, capacity monitoring, fraud watch, certificate rotation, carrier reviews and licence true-ups. Fund service operations from day one.

12. Sector case studies

The three scenarios below illustrate how the principles in this guide apply in sectors we work in. They are anonymised composite sketches drawn from real engagement patterns; they are not descriptions of specific Beckett clients.

Sector scenario: NHS Acute Trust, ~1,200 users, multi-site

Context. A regional acute Trust running a 15-year-old Avaya CM estate across one main hospital site, two community hospitals and a dozen clinic locations. Around 1,200 staff with handsets, 220-seat switchboard and bookings function. Avaya support was end-of-life; clinical safety case required dial tone availability above 99.95% with documented 999 routing per site.

Approach. Direct Routing into an active/active SBC pair across two UK data centres, dual SIP carriers, Survivable Branch Appliances at the three hospital sites, analogue gateways for ward lift lines and cardiac alarms. Switchboard delivered via a Teams-integrated attendant console. Migration in 14 waves of 80–100 users over four months, with Avaya coexistence maintained for 12 months past final cutover.

Outcome. Consistently strong MOS readings across the estate. Two carrier-side outages during the first 18 months; neither resulted in user-visible service loss. Licence consolidation onto a mixed E5/E3+Teams Phone footprint produced measurable recurring savings versus the original Microsoft quote. Switchboard answer-time SLA improved against the prior baseline.

Sector scenario: Russell Group University, ~3,200 users, migration from Cisco

Context. A Russell Group institution with a mature Cisco UCM estate, Jabber clients, Unity Connection voicemail and a 60-seat UCCX contact centre supporting admissions and student services. 3,200 staff phones across 40 buildings, plus DECT in security and estates. Cisco licensing renewal due; appetite to consolidate on Microsoft.

Approach. Direct Routing, four-SBC pair, dual carrier, with Cisco UCM retained for the contact centre during a phased UCCX-to-Teams CCaaS migration in parallel. DECT replaced with a Teams-compatible wireless solution for security; estates kept their existing radios. Location-Based Routing tied into the university’s network management database to drive Dynamic Emergency Calling.

Outcome. Voice migration completed across 16 waves over six months; contact-centre cutover six months later with no missed-call SLA breach during cutover week. Total cost of ownership materially reduced over a multi-year comparison against the Cisco renewal trajectory, principally driven by removed UCM licensing and reduced support spend.

Sector scenario: County Council, ~800 users, migration from Mitel

Context. A County Council with a Mitel MX-One estate, 800 staff handsets across 18 offices and a 90-seat contact centre handling revenues, benefits and adult social care. Strong appetite for hybrid working post-pandemic; existing Mitel investment did not support the home-working patterns the council had moved to.

Approach. Direct Routing with a single SBC pair (sized with headroom for council growth), dual SIP carriers, analogue gateways at the principal offices for legacy services. Contact centre delivered via a Teams-native CCaaS partner, with compliance recording for adult social care. Migration in 10 waves over three months for general users, contact centre run in parallel and cut over in a single weekend window.

Outcome. 100% of users on Teams Phone within 12 weeks; contact-centre cutover completed without missed-call impact on the Monday following the migration weekend. Estate now supports unrestricted hybrid working with consistent caller experience whether agents are at home or in-office. Carrier diversity tested in earnest during a UK SIP outage in the first year; council services were unaffected.