GRAPHPAAS Articles

Service plans you pay for but nobody uses

30 Jul 2026

Service plans you pay for but nobody uses

Every Microsoft 365 seat is a bundle. An E3 licence isn't one product, it's roughly thirty service plans — Exchange Online, SharePoint, Teams, Intune, Power Automate, Viva Engage, Sway, Whiteboard, Bookings, Azure Rights Management, and a long tail nobody in the company can name. You buy the bundle at one price. Most tenants use eight of the thirty. The uncomfortable first fact: turning the other twenty-two off does not reduce your invoice by a cent. The price is per seat, per SKU, and it doesn't itemise. So why look? Because the usage pattern inside the bundle is the cleanest evidence you'll get for three decisions that do move money — and it's the one report almost nobody runs.

~30
service plans in one E3
€0
saved by disabling one
3
decisions the data does change
2
SKUs on the average duplicated user

What a service plan actually is

In the Graph API, a subscribed SKU has a servicePlans array, and each user's licence assignment carries a disabledPlans list. Enabled means the user is entitled and provisioned. Disabled means somebody — an admin, a group-based licensing rule, or a migration script from 2021 — switched that component off for that person. Nothing about either state appears on the invoice.

ONE SEAT, ONE PRICE, THIRTY COMPONENTS E3 seat €34 / month Used daily Exchange, Teams, SharePoint… Entitled, never opened Sway, Viva Engage, Bookings… Disabled by an admin often nobody remembers why Invoice line: 1 × E3 no breakdown, no partial refund
TL;DR
Disabling service plans is a governance action, not a cost action. The cost action is what the disabled and unused plans tell you: that the bundle is wrong for this user, or that you're paying for the same component twice.

The three decisions this data actually changes

1
Duplicate entitlements across stacked SKUs.

This one is real money. A user on E3 who was later given a standalone Exchange Online Plan 2, or Power BI Pro, or an Entra ID P1 add-on, is often paying twice for a component already inside the bundle. It happens through group-based licensing rules that overlap, or through a project that bought add-ons for a team without checking the base SKU. The service-plan view is the only place the duplication is visible — the invoice shows two happy line items.

2
Whether the whole rung is justified.

E5 costs about €21 a month more than E3, and almost all of that premium sits in a handful of plans: Defender for Office P2, Entra ID P2, Power BI Pro, audio conferencing, advanced compliance. If nobody on E5 has those plans provisioned, or they're provisioned and dead, you're not buying security — you're buying the idea of it. Same logic one rung down, which is the whole of right-sizing licences per user.

3
The add-on you're about to buy is already in the box.

The most expensive version of this: a department asks for a workflow tool, or a form builder, or a whiteboard, and someone signs a third-party contract. Power Automate, Forms, Whiteboard, Bookings and Stream are already sitting in every E3 seat, disabled or ignored. Checking the service-plan inventory before a purchase order is a five-minute query that occasionally cancels the purchase order.

The plans worth checking first

Service plan Lives in Why it's worth a look
Exchange Online P2 E3, E5 Also sold standalone — the classic double-buy.
Entra ID P1 / P2 E3 / E5, Business Premium Bought as an add-on by tenants that already own it.
Intune E3, E5, Business Premium Provisioned for users with no enrolled device at all.
Power BI Pro E5 Standalone Pro licences stacked on top of E5 seats.
Power Automate / Forms every bundle Owned by everyone, replaced by third-party tools anyway.
Viva Engage, Sway, Stream every bundle Rarely used, and each is an ungoverned content store.
Azure Rights Management E3, E5 Disabled somewhere in the past; breaks labels later.

Where this goes wrong

  • Disabling plans to "save money". It doesn't. It only removes capability, and the removal shows up as a support ticket six months later when someone opens a link they can't render.
  • Disabling plans at scale by hand. Per-user changes drift instantly. If you want a component off, do it once in the group-based licensing rule, not in 400 individual assignments.
  • Reading "enabled" as "used". Provisioning state is not activity. Pair the service-plan inventory with the actual usage reports — app activations, mailbox activity, Teams sessions — or you'll conclude that everything is in use because everything is switched on.
  • Ignoring the plans that were disabled deliberately. Some were turned off for a reason: a compliance requirement, a failed rollout, a privacy decision. Find out before you re-enable, and write it down this time.
Key takeaway
Waste inside the SKU doesn't refund itself the way an unassigned seat does. It converts into money in exactly two ways: cancelling an add-on you already own, and proving that a whole tier of seats belongs one rung lower. Both need the same table — every user, every SKU they hold, every service plan inside it, next to what they actually used.

Getting the list without a two-day export

Done by hand this is a Get-MgSubscribedSku loop, a Get-MgUserLicenseDetail loop, and a join in Excel against three separate usage exports — which is why it's done once, badly, the week before a renewal. GraphPaaS keeps the SKU and service-plan inventory per tenant alongside the per-user activity it already collects, so the duplicate-entitlement question and the "is this tier justified" question are both a filter away rather than a project. It's the same data set behind how much you're wasting on unused Microsoft 365 licences — that article counts the seats nobody uses, this one counts the parts of the seats you keep.

GraphPaaS

See every SKU in your tenant broken down to its service plans — and which of them anyone has actually opened.

Audit what's inside your licences →

Newsletter

Get the next article by email

Practical M365 & Azure cost pieces like this one. No spam, unsubscribe anytime.