Print: Body

Licensing and Design Decision Reference

Body

What this document is

Two design-time references in one document, because they are consulted at the same moment by the same people. Part one is the Licensing Quick Reference — what each object needs before it will work. Part two is the Shared-Number Calling Decision Guide — when Microsoft’s Shared Calling feature fits and what it costs elsewhere. This document supersedes both standalone versions.

PART ONE — LICENSING QUICK REFERENCE

Where the line sits

Campuses purchase and manage their own Microsoft licensing. The program advises on what level is needed for Teams calling and nothing more — it does not buy, allocate, or manage licenses, and Microsoft licensing spans needs far wider than telephony. This page exists so a campus is not surprised at design time by something it has not bought.

1. What needs a license

Work through this at design, before configuration begins. The second column is the question to ask your Microsoft licensing contact, not an instruction to buy.

Object	What it needs	Confirm before you rely on it
PEOPLE
A staff member making and receiving PSTN calls	A Teams Phone entitlement, on top of their base Microsoft 365 license.	Which base plans at your campus already carry it, and which need an add-on.
A staff member using Teams only internally	No Teams Phone entitlement. Internal Teams calling does not require it.	Whether the user will ever need an outside line — retrofitting is slower than including them.
A user on a base plan that already includes Teams Phone	Nothing additional. Confirm it is assigned and has replicated before assigning a number.	That the entitlement is actually enabled, not merely included in the plan.
SHARED SERVICES
A call queue	A resource account, and that resource account needs its own license.	How many resource account licenses your campus holds and how many the design needs.
An auto attendant	A resource account, licensed the same way as a queue.	The same. Attendants and queues each consume one.
A resource account with no phone number	Still needs the resource account license in most designs.	Whether your specific configuration requires it — check at design, not at build.
DEVICES AND SPACES
A common area phone — lobby, corridor, workshop	Its own account and its own license. It is not a free extension of a user.	The count of common area positions in your estate. This is routinely under-scoped.
A Teams Room or shared meeting device	A meeting room license, plus a calling entitlement if it is to make PSTN calls.	Whether calling is actually required in that room, or only meetings.
An analog device on a MediaPack	Not a Microsoft license. It is carried as an analog port on your Participation Agreement.	Your analog port count on the PIA against the physical inventory.
PLATFORM PREREQUISITES
AudioCodes management platform (UMP)	Carries its own licensing prerequisites on the AudioCodes side, confirmed with AudioCodes before build.	That the UMP prerequisites for your campus are confirmed in writing — they have blocked testing elsewhere when discovered late.

Verify before publication

Microsoft plan names, inclusions, and add-on structures change. Confirm the specific plan and SKU detail against the current SUNY Microsoft licensing position before this page is issued to campuses, and again at each review. This reference is deliberately written in terms of what each object needs rather than what a plan is called, so that a naming change does not silently make it wrong.

2. Three things that cause rework

Resource account licenses are forgotten	The queue or attendant is built, looks complete, and calls do not arrive. It is the single most common licensing fault in this program. Count them during design.
Common area positions are under-counted	Lobbies, corridors, workshops, plant rooms, and lift lobbies. Walk the estate rather than working from a directory export.
Licenses are assigned but not replicated	A newly assigned entitlement takes time to take effect. Assigning a number before it has replicated produces a fault that resolves itself and wastes a ticket.

Who to ask

Licensing questions specific to your campus go to your own Microsoft licensing contact. Questions about what the calling service requires go to your voice administrator and on to the Shared Calling Services Program. Neither AudioCodes nor Spectrotel manages Microsoft licensing.

PART TWO — SHARED-NUMBER CALLING DECISION GUIDE

Two different things share a name — read this first

The SUNY Shared Calling Services Program is the program this pack belongs to — the shared platform, carrier contract, and support arrangement your campus participates in. Separately, Microsoft Teams Phone has a feature Microsoft calls “Shared Calling,” which lets a group of users make and receive outside calls through one shared number held by an auto attendant’s resource account. This guide is about the Microsoft feature only. To keep the two apart, program documents call the feature shared-number calling, and name Microsoft’s label for it where you will meet it in the admin center and Microsoft’s documentation.

The short version

Shared-number calling lets a group of users make and receive outside calls through a shared number rather than each holding their own. It is a legitimate design for the right population and it is supported. It is not a general method for reducing active DID counts, and it should be chosen deliberately rather than applied broadly.

4. Where it fits

Microsoft’s own documentation for the feature: “Plan for Shared Calling” and “Configure Shared Calling” at learn.microsoft.com — the design questions in this guide come first, Microsoft’s pages carry the build steps.

Potential benefit	What it actually gets you
Fewer active numbers	Useful where a population genuinely does not need individual reachability — seasonal staff, shared workspaces, some field and facilities roles.
A common outbound identity	Calls present a departmental number rather than an individual one. Sometimes exactly what a service area wants.
Simpler joiner and leaver handling	No individual number to allocate, port, or reclaim as people move through a shared role.
A lower recurring line count	Real, but modest. Model it against your own Participation Agreement rates before assuming a saving.

5. What it costs you elsewhere

Concentrated dependency	A larger population now depends on a smaller set of numbers. A fault on one shared number affects everyone behind it rather than one person.
Added configuration complexity	More policy objects and more relationships to understand and hand over. Complexity is paid for at every future staff change, not once at build.
Caller identity questions	Outbound presentation, callback behavior, and how a returned call reaches the right person all need a decided answer, not a default.
Support complexity	Diagnosing a shared-number fault is harder than diagnosing a user fault, and reports arrive with less specific detail.
Emergency calling implications	Emergency location is tied to the caller and their network position, not the shared number. Confirm the emergency behavior for the specific design before it is built.
Operational understanding required	Whoever supports it must understand it. If one person on campus understands the design, it is a risk rather than a saving.
Survivability exclusion	Microsoft does not support its Shared Calling feature in combination with a Survivable Branch Appliance. A campus with an SBA, or planning one, cannot put SBA-dependent users behind a shared-number design — this eliminates the design for those populations; it does not merely complicate it.

Emergency calling is the item to settle first

Any shared-number calling design must have its emergency calling behavior confirmed before it is built — how the location is determined for each caller, what the callback path is, and what a dispatcher receives. Do not infer this from how individual numbers behave. Raise it with the program at design.

6. Program guidance

Shared-number calling should not be treated as the default method for reducing active DID quantities. Campuses considering broad use should review the design with SUNY and the program technical team before building it.

Question to answer	What a good answer looks like
Who is in the population, and why?	A named group with a shared working pattern — not simply the users left over after the individual numbers were allocated.
Does anyone need to reach them directly?	If the answer is yes for any meaningful subset, those users need their own numbers regardless of the rest.
Is an SBA involved, now or planned?	If yes, the population behind it is out of scope for shared-number calling — Microsoft does not support the combination.
What is the outbound identity, and is it right?	A decided presentation number, and agreement from the department that it is what callers should see.
How does a returned call reach the right person?	A queue, an attendant, or a named process. “Someone will pick it up” is not an answer.
What is the emergency calling behavior?	Confirmed with the program, in writing, for this specific design.
Who supports it after go-live?	A named technical owner who understands the design, plus documentation in the campus pack.
What is the modeled saving?	A number, calculated against your PIA rates, set against the added complexity. If it is small, the complexity is not worth it.

Before you design it

Bring the population, the reason, and the answers above to the program. A short design review costs an hour. Rebuilding a shared-number design after go-live, once staff have learned it, costs considerably more.

Details

Article ID: 12221

Created

Mon 9/14/26 6:06 PM

Modified

Mon 9/14/26 6:09 PM