Microsoft Teams Phone System Design, Configuration, and Call Routing

Executive overview

Designed and configured a Microsoft Teams Phone deployment for a growing professional-services organization — PSTN connectivity, number plan, Auto Attendants, Call Queues, dial plans, emergency calling, and the network readiness work that makes the calls sound right.

Business challenge

The organization wanted Microsoft Teams to be the phone system, not just the meeting tool. Staff already lived in Teams, and running a separate telephony platform meant a second directory to maintain, a second admin console, and a second place for a call to go wrong. What they needed went well beyond dial tone: individual direct numbers, a main business number that answered professionally, departmental routing, defined after-hours behavior, voicemail that reached the right people, and a caller ID that showed the business rather than a stranger's direct line. Teams Phone is not enabled by assigning a license. A production deployment has to hold together across licensing, Microsoft Entra ID, Teams Phone policies, carrier services, number management, voice applications, dial plans, emergency calling, and the network path the media actually takes. The hard part of this engagement was not configuration. It was translating how the business wanted to answer the phone into call flows that behave the same way every time.

Environment and constraints

• A growing professional-services organization; client identity, tenant details, telephone numbers, and carrier arrangements are withheld.
• Microsoft Teams was already in daily use for chat and meetings, so calling had to fit the client estate and habits that existed rather than introduce a separate application.
• Both in-office and remote users, which affects emergency location handling, media paths, and what can realistically be tested from a desk.
• Existing telephone numbers carried business value, so number retention and porting dependencies constrained the connectivity decision rather than following from it.
• No dedicated telephony team. Whatever was built had to be operable by Microsoft 365 administrators with a runbook.
• Cutover could not interrupt inbound calls during working hours.

Objectives and success measures

• Establish Microsoft Teams as the primary calling platform for internal and external calls.
• Enable inbound and outbound PSTN calling with a connectivity model chosen against real carrier, geographic, regulatory, and integration constraints.
• Configure user numbers and service numbers with clear separation between people and voice applications.
• Build Auto Attendant and Call Queue behavior that is predictable across business hours, after hours, and holidays.
• Apply calling, voice routing, and caller ID policies by role rather than uniformly.
• Validate emergency-calling dependencies against the jurisdictions actually in scope.
• Establish a network and QoS baseline that can be measured against later.
• Document the solution so the organization's own administrators can operate, extend, and troubleshoot it.

Role and responsibilities

Microsoft Teams Phone architect and consultant. I ran the readiness assessment, designed the call flows and voice architecture, configured the production tenant, built and executed the test plan, troubleshot what the tests surfaced, and handed over documentation the organization's own administrators could work from.

Architecture and design approach

• I began with discovery rather than configuration, because almost every expensive mistake in a Teams Phone project is a design decision made at the console. I reviewed the Microsoft 365 tenant, the existing voice service and its contractual position, verified domains, administrative role assignments, and the policies already in place — then exported a baseline of the voice configuration before changing anything, so there was a known-good state to compare against.
• Requirements came from the departments, not from the IT inventory. Who needs a direct number and who does not. Which teams need a queue and who is in it. What happens at 5:01 p.m., on a public holiday, and when nobody picks up. Who is the operator, and what should a caller hear when they press nothing at all. I documented working hours and time zones per group, because a queue configured in the wrong time zone fails silently and only on the days it matters.
• I designed the full call tree on paper and had the business sign off on it before a single resource account existed. The flow covered the main number, business-hours menu options, departmental queues, operator routing, after-hours handling, holiday behavior, overflow and timeout destinations, and shared voicemail. Reviewing a diagram takes an hour; unpicking a live auto attendant that routes callers to the wrong department takes considerably longer.
• I treated PSTN connectivity as an architectural decision with four options on the table — Microsoft Teams Calling Plans, Operator Connect, Teams Phone Mobile, and Direct Routing — rather than a default. Microsoft supports combining them in a single tenant, so the question was not which one wins but which one fits each requirement. The appropriate model was selected based on carrier, geographic, regulatory, and integration requirements, and the reasoning was written down so a future administrator inherits the decision rather than guessing at it.
• I built the number plan before assigning anything, separating user numbers from service numbers. Service numbers back voice applications through resource accounts and are governed differently from a person's direct line: they need a Microsoft Teams Phone Resource Account license, they must never carry a Teams Phone Standard license, and if a voice application will place an outbound PSTN call on behalf of its resource account using a Calling Plan number, the licensing requirement changed on 1 November 2025 and a plain Calling Plan license no longer covers it.
• Every number went into the inventory in full E.164 form, with an owner, a purpose, and its assignment target. Partial or locally formatted numbers are the single most common cause of a routing rule that matches in testing and misses in production.
• I configured Auto Attendants against the signed-off design — separate business-hours, after-hours, and holiday flows, greetings, menu options mapped to dial keys, operator routing, directory search where the directory supported it, and explicit timeout and invalid-entry behavior. An auto attendant without an operator has no fallback when call processing fails, which is exactly the moment a caller should not be dropped.
• Call Queues were built per department with routing method chosen to match how the team actually works rather than by default. Attendant routing suits a small team that wants everyone alerted; round robin distributes fairly across a larger group; longest idle is fairer still but turns on presence-based routing as a consequence, which changes behavior for anyone who leaves their status on Do Not Disturb. I set agent alert time, overflow and timeout thresholds and destinations, no-agent handling, music on hold, and shared voicemail, and enabled conference mode where the client estate supported it.
• I built tenant dial plan normalization rules so that what people actually type — an internal extension, a ten-digit local number, an international number with a national prefix — resolves to a routable E.164 number. Rules are evaluated top-down and the first match wins, so ordering is part of the design, and every rule was tested against the effective dial plan rather than assumed correct.
• Calling policies, voice routing policies, and caller ID policies were assigned by role rather than to everyone. International calling was authorized where the job required it and withheld where it did not. Caller ID substitution presents the departmental or main business number for outbound calls from queue members, using resource-account substitution — the older service-number substitution method has been deprecated by Microsoft and was avoided.
• Emergency calling was designed rather than assumed. Validated emergency addresses, places within those addresses, network sites and subnets, trusted public IP addresses, and where relevant wireless access point and switch mappings, all tie a caller to a dispatchable location. Requirements vary by country, carrier, and regulatory jurisdiction, so the design records which of those it depends on rather than presenting itself as universal.
• I validated the network path as part of the build rather than as a post-deployment activity. Bandwidth, latency, jitter and loss, firewall and NAT behavior, proxy and inspection bypass for Microsoft 365 media endpoints, VPN split tunneling, wireless coverage, and QoS marking end to end. Voice quality is a property of the whole path, and in practice the fault sits in whichever segment has no single owner.

Security and governance considerations

• Administrative access was scoped to purpose. Teams voice administration does not require Global Administrator, and the roles assigned during the project reflected that — with multifactor authentication and Conditional Access applied to the accounts performing the work.
• Resource accounts backing Auto Attendants and Call Queues remain disabled for sign-in by design. They are service objects, they hold telephone numbers, and they are governed as infrastructure rather than left in the general user population where a lifecycle process might treat them as people.
• International calling is authorized by role. Unrestricted outbound dialing across an entire tenant is a toll-fraud exposure, and the cheapest control is to grant the permission only where the job needs it.
• External call forwarding and outbound transfer from voice applications were reviewed against their licensing and abuse implications rather than enabled by default, including the change Microsoft made on 1 November 2025 to how outbound calls placed on behalf of a resource account are licensed.
• Caller ID substitution was configured deliberately, so that outbound calls present a number the organization intends to publish.
• Emergency address data is personal and operational at once. It was handled with the same care as directory data, and access to change it was limited to the roles that need it.
• Where Direct Routing is in scope, certificate lifecycle is an availability control, not a formality. An expired SBC certificate takes the trunk down. The design assigns an owner, a renewal window, and a monitoring path — the Direct Routing health dashboard warns when a certificate is within 30 days of expiry, and somebody has to be watching it.
• Where Direct Routing is in scope, SBC administration is restricted and logged separately from Microsoft 365 administration, because the two have different blast radii and often different people.
• Number assignments were made a periodic review item rather than a one-time deliverable, tied into joiner, mover, and leaver procedures so a departed employee's direct number does not quietly keep ringing.
• Administrative changes to voice configuration are tracked, so a routing change can be attributed and reversed.

Implementation and migration approach

• Readiness first. I validated tenant and domain configuration, reviewed administrative roles, confirmed Teams Phone licensing for users and the separate resource account licensing for voice applications, checked identity attributes that voice features depend on, reviewed existing policies for conflicts, and exported a configuration baseline before making changes.
• Number planning and assignment. User numbers were assigned to people; service numbers were assigned to resource accounts backing each Auto Attendant and Call Queue. All numbers in E.164. The inventory records number, type, owner, assigned object, and purpose, and it is the document I expect to still be accurate in two years.
• Auto Attendant build. Resource account created and licensed, main number associated, then the three call flows configured separately — business hours, after hours, and holidays. Greetings, menu keys, operator routing, dial by name, dial by extension where the directory supported it, and explicit timeout and invalid-entry destinations. Microsoft allows only one directory-search method per auto attendant — dial by name or dial by extension, not both — and recommends turning directory search off entirely where dial keys are assigned, because a caller spelling a name is transferred as soon as their keypresses match a key. Where both were wanted, the main attendant links to a dedicated directory-search attendant behind a dial key.
• Call Queue build. A resource account per department, membership defined through the mechanism the business already maintains, routing method matched to team size and working style, agent alert time set, opt-out behavior decided, music on hold configured, and overflow, timeout, and no-agent actions each pointed at a real destination — most often shared voicemail monitored by the team rather than an individual's mailbox.
• Dial plan and normalization. Tenant dial plan rules built for extension dialing, local numbers, and international numbers, ordered so that the more specific patterns are evaluated before the general ones. Every rule tested against the effective dial plan for a representative user, because the effective plan is Microsoft's service dial plan for that country merged with either the tenant Global plan or, where one is assigned, the user's own tenant dial plan — and only the merged result matters.
• Policy assignment. Calling policies for forwarding, simultaneous ring, delegation, and voicemail behavior; voice routing policies where the connectivity model required them; caller ID policies to present the intended outbound identity. Assigned by role, documented in a matrix, and applied as policy rather than as per-user exceptions.
• Direct Routing, where the architecture calls for it. This is a distinct workstream: a Microsoft-certified session border controller, a publicly resolvable SBC fully qualified domain name on a domain verified in the tenant — Microsoft does not support an onmicrosoft.com name here — a public certificate with the SBC name in the subject or subject alternative name, TLS signaling, SIP OPTIONS enabled so the trunk reports its own health, the carrier trunk, then the PSTN usage, voice route, and voice routing policy chain that decides which call leaves through which gateway. Usage order matters: the first match wins and later usages are never evaluated.
• Emergency calling. Validated addresses and places, network sites and subnets, trusted public IP addresses that tell the service a client is on the corporate network, and wireless access point or switch mappings where the estate supports them. Emergency calling policy governs security-desk notification and remote-user location lookup for every connectivity model; the emergency call routing policy is relevant only to Direct Routing. Testing was controlled and coordinated so that verification did not page a security desk or reach an emergency service unnecessarily.
• Network and call quality. Firewall and NAT rules for Microsoft 365 media endpoints, proxy and inspection bypass, VPN split tunneling so media does not hairpin through a tunnel, wireless survey where coverage was in question, and QoS marking applied consistently from the endpoint through switch, router, firewall, and WAN. A marking that the first switch clears has bought nothing, and it is invisible from the Microsoft 365 side, which is why the check ran hop by hop.
• Testing, then handover. The test plan was executed against the design, defects were fixed and retested, and the documentation set — architecture, call flows, number inventory, policy matrix, emergency design, network recommendations, troubleshooting runbook, administrator guide, and end-user quick start — was walked through with the people who would own it.

Key decisions and trade-offs

• Design the call flows before touching the tenant. The single highest-leverage decision in the project was refusing to configure anything until the business had signed off on a call tree. Every later argument about routing was settled by pointing at the diagram.
• Treat PSTN connectivity as architecture, not procurement. Calling Plans, Operator Connect, Teams Phone Mobile, and Direct Routing differ in who owns the carrier relationship, who owns the infrastructure, and who you call at two in the morning. They can coexist in one tenant, so the decision was made per requirement and recorded with its reasoning.
• Keep service numbers off user accounts. Voice applications get resource accounts with their own licensing. Hanging a main business number off a person's account works right up until that person leaves.
• Point overflow and timeout at shared voicemail rather than an individual. A queue that overflows to one person's mailbox has moved the single point of failure rather than removed it.
• Choose routing method by how the team works, not by which sounds most sophisticated. Longest idle is the fairest distribution, and it forces presence-based routing on, which surprises teams that use Do Not Disturb heavily. Round robin was the better fit where that mattered.
• Restrict international dialing by default and grant it by role. Toll fraud does not need a sophisticated attack when a compromised account already has unrestricted outbound calling.
• Fix the network before go-live. Deferring QoS and firewall work until users complain converts a scheduled task into an incident, and the complaint arrives without the evidence needed to diagnose it.
• Write the troubleshooting runbook during the project rather than after it. The entries that earn their place are the ones that came out of something going wrong during the build, and those are forgotten within a fortnight of handover.

Results and outcomes

• The organization gained a single, centrally managed calling platform inside Microsoft 365, administered from the Teams admin center and Teams PowerShell rather than across a separate telephony console with its own directory.
• Inbound calls to the main business number are handled the same way every time, through a documented call tree with defined business-hours, after-hours, and holiday behavior instead of ad hoc forwarding.
• Departmental queues route to the right people with agreed overflow, timeout, and no-agent destinations, so a call that cannot be answered lands somewhere deliberate rather than ringing out.
• Number ownership is visible. The completed inventory maps every user number and service number to a person or a voice application, in E.164 form, which makes joiner, mover, and leaver handling a lookup rather than an investigation.
• Calling permissions are documented and assigned by role rather than held in one administrator's memory, so a permissions question has an answer that can be checked.
• Outbound calls from queue members present a departmental or main business number rather than an individual direct line, so returned calls come back to the team instead of one person's handset.
• The emergency-calling design is reviewable rather than implicit, which is what makes it possible to assess a new location against it instead of starting again.
• The implementation established a network and QoS baseline and a repeatable way to investigate quality complaints using Call Analytics and the Call Quality Dashboard, rather than treating each report as a new mystery.
• The administrators received a troubleshooting runbook organized by symptom, a handover guide, and end-user quick-start instructions, so routine changes and first-line diagnosis no longer require external help.
• The configuration is a foundation rather than a finished state. Adding users, departments, queues, or a further location follows the documented pattern instead of starting a new design conversation.

Assessment artifacts

The working reference from this engagement, in a self-contained interactive page: the PSTN connectivity comparison, call-flow and architecture diagrams, Auto Attendant and Call Queue configuration limits, dial-plan normalization examples, sanitized PowerShell, the emergency-calling and QoS design tables, the test matrix, and a troubleshooting runbook organized by symptom.

Lessons learned

• Almost every Teams Phone problem that reaches an escalation turns out to be a design problem rather than a configuration one. Settings applied in isolation, without an agreed call flow behind them, produce behavior where every individual value is defensible and the result is still wrong.
• Test business hours, after hours, and holidays as three separate exercises. A holiday flow that was never called on a holiday is untested, and the day it fails is the day nobody is in the office to notice.
• Full E.164 formatting everywhere removes an entire category of intermittent routing faults. Numbers stored in local format work in the environment they were written for and nowhere else.
• Voice quality complaints are rarely about Teams. Latency, jitter, loss, wireless coverage, a proxy inspecting media, or a VPN pulling media through a tunnel account for most of them — and none are visible from the Teams admin center alone.
• Emergency calling assumptions must be written down. The design depends on country, carrier, and regulator, and an undocumented assumption is one that gets invalidated silently when the organization opens an office somewhere else.
• The number inventory decays faster than any other document in the set and matters most at the moment it is wrong. Making it a standing review item rather than a one-off deliverable is what keeps it true, because nobody re-reads something that was signed off once.
• Handover is part of the implementation, not an appendix to it. A configuration nobody internal can explain is a dependency, and the client did not hire a dependency.

Related technologies

• Microsoft Teams Phone
• Microsoft 365
• Microsoft Entra ID
• Teams admin center
• Teams PowerShell
• Auto Attendants
• Call Queues
• Resource accounts
• Cloud Voicemail
• Microsoft Teams Calling Plans
• Operator Connect
• Teams Phone Mobile
• Direct Routing
• Session Border Controllers
• SIP and TLS
• E.164 number normalization
• Tenant dial plans
• Voice routing policies
• Caller ID policies
• Dynamic emergency calling
• Call Analytics
• Call Quality Dashboard
• Direct Routing health dashboard
• QoS and DSCP marking
• DNS and public key infrastructure

Related projects