Australia call queues after the 2026 Teams changes: when should reception move off user licences and onto resource accounts?

01What changed, and why old reception patterns should be reviewed now

Microsoft’s current Teams voice guidance sets a clean baseline. Auto attendants and call queues that directly answer calls require a resource account, and each resource account must be assigned a Teams Phone Resource Account licence. Microsoft notes that the licence now has no cost associated with acquiring it, but you still need to obtain and assign it correctly.

Just as important, Microsoft says do not assign a Teams Phone Standard licence to a resource account. If you previously put a paid user telephony licence on a queue or attendant resource, Microsoft’s own direction is to switch that object over. That is the licensing trigger behind many 2026 clean-up projects.

There is another design implication. Microsoft’s voice application licensing reference says you need at least one Teams Phone licence in the tenant to enable Teams Phone Agent, Auto Attendant and Call Queue services, but each queue or attendant resource itself should sit on the resource-account model. In practice, that means named agents can keep user licences where they genuinely act as people, while shared entry points move to resource accounts.

If you are planning a broader clean-up of shared Microsoft 365 identities, the same logic usually appears elsewhere too, such as shared mailboxes and service identities. That is why this review often sits alongside a wider tenant rationalisation or technology consulting exercise.

• Keep user licences for real humans who place and receive calls as people
• Move auto attendants and call queues that answer calls to resource accounts
• Remove Teams Phone Standard from resource accounts
• Check outbound calling requirements separately, because those can add extra licensing or routing needs

02The breakpoints: when a named user setup becomes the wrong model

You do not need a full telephony transformation to justify the change. In most Australian environments, the switch becomes sensible as soon as one of four conditions appears.

First, the number is shared. If two or more people cover reception, rosters, lunch breaks or overflow, the number is no longer tied to a single worker. Keeping the main published number on one person’s account turns leave, resignation and handset changes into service events.

Second, the number is workflow-driven. Once callers hear a greeting, business-hours logic, holiday logic, overflow routing or voicemail routing, you are already in auto attendant and call queue territory. Microsoft’s setup guidance for call queues and auto attendants assumes resource-account-backed voice applications.

Third, the number needs to survive staff movement. A shared reception pattern should keep working if the front desk team changes, if a contractor covers a week, or if the office moves to hybrid coverage. If the number is anchored to a user, offboarding can accidentally become a telephony outage.

Fourth, you need cleaner cost allocation. The Teams Phone Resource Account licence itself is free. That does not make the whole setup free, because PSTN connectivity and some outbound scenarios still cost money, but it does remove the habit of paying for a user telephony licence on an identity that is not a person.

These are the common breakpoints. Once you hit even one of them, a user-centred reception design becomes harder to defend.

• Two or more people answer the same public number
• You need business-hours and after-hours routing
• You need queue overflow, timeout or shared voicemail
• The main number must stay stable through staff churn
• You want to stop paying user telephony licences on non-human identities

03Where resource accounts save money, and where they do not

The most obvious saving is stopping paid user telephony licences on queue and attendant identities. Microsoft’s resource account page makes clear that the Teams Phone Resource Account licence has no acquisition cost. If you have been using full user-style telephony licensing for non-human objects, that is wasted spend.

The more important benefit is usually avoiding hidden admin cost. A user-based front desk number creates recurring work across onboarding, licence reconciliation, handset changes, number moves, leave cover, shared voicemail handling and offboarding. Resource-account-led design removes a lot of that noise because the service identity becomes independent of the person covering it.

But do not oversell the saving. Resource accounts are free only for the voice application identity itself. If that queue or attendant needs to place outbound PSTN calls, Microsoft says extra requirements apply. For Microsoft-provided numbers, the resource account needs funded pay-as-you-go, Communications Credits, or telco pay-as-you-go overage, depending on the commercial model. For Direct Routing, you need an online voice routing policy. For Operator Connect, there are no other requirements when an Operator Connect number is assigned.

That means the financial decision is not simply user licence versus free licence. It is user licence versus resource account plus the right PSTN model. For most shared reception designs, that still comes out in favour of resource accounts because the object should not have been licensed as a person in the first place.

If you are reviewing PSTN choices at the same time, Microsoft’s current comparison of PSTN connectivity options is the right baseline. Teams supports Microsoft Calling Plan, Operator Connect and Direct Routing, and Microsoft explicitly notes that organisations can use more than one PSTN connectivity option in the same tenant. That matters in Australia, where many businesses mix connectivity models for different sites or functions.

04The architecture choices for a shared Australian reception number

Once you accept that the number is a service, not a person, there are three common architectures.

The first is the simplest: public number to auto attendant, then to call queue, then to agents. This suits a main switchboard, branch line or department reception. It gives you opening hours, holiday routing, menu options and queue handling with a clean separation between the published number and the people answering it. Microsoft’s guidance says the auto attendant or queue that directly answers calls should use a resource account.

The second is a direct queue model. This works where callers should land straight into reception without an IVR. It still benefits from a resource account because the queue, not the receptionist, is the service endpoint.

The third is shared outbound identity. This is the design many teams get wrong. Inbound is easy to clean up, outbound is where you must decide whether agents call out as themselves, as the reception number, or both. Microsoft’s licensing reference says outbound actions such as transfers to external numbers, callback, or representative on-behalf-of outbound calling line ID control trigger additional requirements depending on the PSTN method.

For most front desks, the design question is straightforward: if outbound calling under the shared business number matters, validate that path before you remove old user licences. If most traffic is inbound and transfers, the move is usually simpler.

This is also where cloud infrastructure and telephony infrastructure planning intersect. The Teams objects are easy to create. The quality of the design depends on how well you handle numbering, routing, emergency location obligations, and the operational model around them.

• Auto attendant to queue for main numbers and multi-option routing
• Direct queue for straightforward front desk coverage
• Separate inbound and outbound design decisions
• Check whether agents need to present the reception CLI on outbound calls

05Shared voicemail is often the hidden breakpoint

Many teams start this project because voicemail is messy, not because licensing is messy. A user-owned reception line tends to dump missed calls into one person’s mailbox, then someone forwards or manually triages them. That works until it does not.

Microsoft’s current shared voicemail guidance is more useful than many admins realise. Shared voicemail for auto attendants and call queues can be delivered to a Microsoft 365 group, distribution list or mail-enabled security group. Microsoft also notes an important behaviour difference: with a Microsoft 365 group, shared voicemails are delivered to the group’s associated folder, whereas with a distribution list or mail-enabled security group, each user gets a copy in their own inbox.

That distinction matters operationally. If your reception team needs one shared place to process messages, a Microsoft 365 group is usually cleaner. If each person should receive their own copy and handle locally, the other group types may fit better. Microsoft also notes that Teams visibility differs by group type, and Teams access for Microsoft 365 groups depends on the group being Teams-supported.

In practice, shared voicemail is a strong sign that the number should no longer live on a human identity. Once voicemail belongs to a team process, the number should too.

If you are trying to standardise how shared service identities are handled across Microsoft 365, this is often part of a broader managed services or governance review.

06A migration checklist: what to inventory before you switch

Most Teams telephony clean-ups fail because the technical change is easy and the inventory is weak. Before moving a front desk or queue off user licensing, build a short fact set for each number.

Start with identity and ownership. Is this a person number, a team number or the main public number? If the answer is team or public, that is already a signal for a resource-account design.

Then map inbound behaviour. Document greetings, opening hours, public holidays, menu paths, queue timeout rules, overflow targets and voicemail destinations. If the current setup depends on undocumented receptionist habits, write those down before you touch licences.

Next, map outbound behaviour. Do agents dial out using their own numbers, the shared business number, or never dial out from this service at all? This decides whether you need only the free resource account licence or additional PSTN configuration under Microsoft’s voice application licensing rules.

Finally, map operational dependencies. Check devices, Teams-certified phones, common area endpoints, Teams channels, reporting expectations and who supports the service after hours. Microsoft’s current call queue setup and supported configurations reference are useful here because they anchor the redesign to what Microsoft supports now, not what happened to work a few years ago.

• List every public and shared number
• Mark each number as person, team or business function
• Identify every auto attendant and call queue that directly answers calls
• Check each resource account for the correct resource-account licence
• Find any resource account still carrying Teams Phone Standard
• Confirm outbound PSTN needs before changing routing
• Confirm shared voicemail destination and group type
• Test after-hours and holiday routing before cutover

07What to ask your telco or Teams partner before you redesign

If Australia is your delivery market, the licensing clean-up is only half the project. The other half is making sure your PSTN model and support model still fit. Microsoft’s PSTN connectivity guidance and Operator Connect planning guide both point to the same practical issue: number availability, porting, provider relationships and support boundaries affect the design as much as licence assignments do.

Ask whether the provider supports your preferred inbound and outbound pattern for shared numbers. Ask how porting will work for main business numbers and branch lines. Ask which party owns fault isolation when Teams policy, carrier routing and number service all intersect. If you are using multiple PSTN models in one tenant, ask where that complexity lands operationally.

Also ask a blunt question about break-fix: when the front desk cannot receive calls, who has the first-response responsibility, and what evidence do they need from your team? That answer often distinguishes a clean managed service from a finger-pointing arrangement.

Where the environment is already messy, it can help to run the redesign as a small architecture and remediation package rather than a licence-only task. That is usually faster than discovering late that the queue logic, porting plan and support ownership were never aligned.

• Can this number be ported without changing its service behaviour?
• How is outbound CLI handled for shared reception scenarios?
• Do we need Operator Connect, Direct Routing, or a mixed model for these numbers?
• Who owns first-line support for call flow failures?
• What logs and diagnostics will be available during migration and after go-live?

08The practical decision line

For most Australian Teams admins, the decision line is now simple. If a queue or attendant directly answers calls, Microsoft says it needs a resource account with a Teams Phone Resource Account licence. If you are still paying user-style telephony licensing on that object, you should revisit it. If the number represents reception, a branch, a department or the business itself rather than a single person, move the architecture in the same direction.

The only reason to pause is outbound complexity. Where shared outbound CLI, callback or external transfers matter, validate the PSTN design first using Microsoft’s current licensing reference for voice applications. Everything else points toward the same answer: resource accounts for service identities, user licences for humans.

If you need help turning an inherited Teams voice setup into a cleaner supportable design, SyncTrix can help with telephony infrastructure, governance and compliance, and adjacent Microsoft 365 clean-up work.