Mapping Scenarios to Licences and Consumption

What it does

Turns a client scenario into a defensible commercial proposal by matching it to the right mix of per-user licences and consumption meters. The Copilot family mixes fixed seats, prepaid packs, pay-as-you-go and Azure-billed compute units, and the traps are all in the seams.

Key facts

Microsoft 365 Copilot (per-user) — fixed seat (list ~$30/user/month, annual). Predictable, but you pay whether the seat is used or not.
Copilot Chat consumption / PAYG — Chat itself is free with qualifying M365 plans; agents run in it are metered in Copilot Credits, billed via an Azure subscription with no commitment.
Copilot Studio message packs vs PAYG — prepaid packs at $200/month for 25,000 Copilot Credits, or pay-as-you-go at $0.01 per credit on Azure. Credits replaced "messages" on 1 September 2025; a 25,000-message pack became a 25,000-credit pack.
Security Copilot SCUs — provisioned at ~$4 per SCU per hour (minimum 1), overage ~$6 per SCU. M365 E5/E7 now includes an SCU allowance (400 SCUs/month per 1,000 paid licences, capped at 10,000, no overage — you get throttled instead).
GitHub Copilot tiers — Free ($0, ~2,000 completions/month), Pro $10, Pro+ $39, Business $19/seat, Enterprise $39/seat; premium requests over allowance at $0.04 each.

When to use / skip

For steady, daily knowledge-worker use, buy per-user M365 Copilot seats — the metered alternative gets more expensive and less predictable at that volume. For occasional or spiky agent use, or a pilot, lean on Copilot Chat plus PAYG credits and commit to nothing.

For Copilot Studio, model expected credit burn first, then choose: prepaid packs when volume is steady and you want a fixed line item; PAYG when it's variable or you're still finding the level. Remember licensed M365 Copilot users get common grounding (classic/generative answers, Graph tenant grounding) zero-rated inside M365 — so seats can cut your credit bill. For the SOC, size Security Copilot in SCUs and check the E5/E7 inclusion before quoting standalone capacity. For developers, size GitHub Copilot by tier and watch premium-request overage.

Configuration decisions

Usage shape: steady daily use (favours fixed seats) or spiky/occasional (favours consumption)?
How many named users genuinely need tenant-grounded Copilot, versus free Chat?
Expected Copilot Studio credit burn per month — and which actions dominate (a Graph tenant-grounding action is 10 credits, a classic answer 1)?
Do the users already hold E5/E7? That changes Security Copilot and Chat maths materially.
Who carries the Azure subscription for PAYG meters, and who owns the overage risk?

Gotchas

Credit rates are per action type, not flat. A chatty agent doing tenant grounding burns credits far faster than the headline pack size suggests. Model the action mix, not just message count.
PAYG has no ceiling. Without a budget alert on the Azure meter, an autonomous agent can run up a bill overnight.
The "messages → Copilot Credits" rename in September 2025 confuses older quotes. Make sure your figures use current credit rates.
Security Copilot SCUs are billed hourly on provisioned capacity — you pay for provisioned SCUs whether or not analysts run anything. Don't over-provision "just in case".
GitHub Copilot is billed entirely separately from M365; premium-request overage at $0.04 each adds up on heavy agent use. It won't appear on the M365 bill.
Zero-rating only applies to licensed M365 Copilot users. The same agent run by an unlicensed user in Chat consumes credits.

Consultant notes

Build the proposal as seats plus a metered envelope with a stated assumption on credit burn, and a named budget alert. Never quote consumption as if it were fixed.
The cheapest defensible design is usually fewer seats for heavy users, free Chat for the rest, and a capped credit pack for shared agents.
Always check existing entitlements first — E5 clients part-own Security Copilot capacity and Chat, and may already have Power Platform capacity that offsets Copilot Studio.
Put a review checkpoint at 30 and 90 days to true-up packs vs PAYG against actual burn. First estimates are always wrong; the point is to correct fast.

Consumption meters need a budget alert on day one — flag it in the proposal, not after the first surprise invoice.