Enterprise
pay-as-you-go billing
Designing a scalable billing system for Microsoft 365 metered services—supporting departmental billing, spend management, and a growing service ecosystem.
Scaling pay-as-you-go for enterprise
I led the design of a new pay-as-you-go billing model to address key barriers to enterprise adoption.
The work expanded pay-as-you-go from a single-policy model into a system that could support multiple departments, billing destinations, budgets, administrative boundaries, and metered services—while creating a path for 18 existing services to transition without requiring them to migrate at the same time.
I worked across product, engineering, research, content, design, and leadership to define the shared model, bring Copilot and existing services into it, and establish patterns other product teams could adopt.
The enterprise adoption challenge
Pay-as-you-go already supported 18 Microsoft 365 metered services, but enterprise adoption was limited.
The primary barrier was departmental billing. Organizations needed to separate costs across departments, teams, or business units, while the existing experience supported one billing policy connected to one Azure subscription and resource group.
Spend visibility
Admins needed better ways to monitor metered spending, particularly for services such as Copilot where usage required closer cost oversight.
Discoverability
Pay-as-you-go management lived within a long general Settings page, making it difficult for billing admins to find.
Research with enterprise billing admins validated departmental billing, budget visibility, and delegated administration as key needs and informed the model we moved forward with.
Because the work crossed products, disciplines, teams, and time zones, I maintained a shared record of decisions, dependencies, open questions, design principles, and ownership. This let teams move independently without reopening foundational decisions as the model evolved.
Moving from one billing policy to many
Departmental billing changed the underlying billing structure.
- 1 Azure subscription
- 1 resource group
- 18 connected metered services
- Different Azure subscriptions and resource groups
- Services connected to the appropriate policies
Supporting two generations of infrastructure
Supporting the new model required infrastructure changes from individual service teams. Some services were ready to make those changes. Others had existing priorities and would transition later.
The experience therefore needed to support two generations of billing infrastructure during the transition without asking admins to understand which model each service used.
Exploring coexistence
These approaches exposed too much of the underlying infrastructure to admins and made the transition from the legacy model to the new one increasingly complex.
Tagging different policy types
Separating policy types into different views
Restricting which services could connect to each policy
Creating a separate space for the new model
We established the new departmental billing experience as a separate space rather than layering it onto the legacy experience. This gave customers a clear experience while giving product teams a practical path to adopt the new model over time.
A billing policy became the common foundation
The new model needed to work across departments and services without requiring every product to manage billing differently. I defined a shared billing-policy structure connecting the core elements admins need to manage:
Scope
Who or what the policy applies to
Billing destination
Azure subscription and resource group
Services
Metered services connected to the policy
Roles & access
Who can administer the configuration
Budgets & alerts
How spending is monitored
Adding spend management
Budget management was particularly important for services with less predictable consumption. For Copilot, this was a known adoption blocker. Budgets were designed for visibility and alerts rather than hard service stops, giving admins greater oversight without unexpectedly interrupting business-critical services.
Keeping setup in context
I also brought Azure subscription and resource-group setup into the billing flow, reducing the need for admins to move between administrative experiences to complete configuration.
Designing for Copilot while keeping the model reusable
As the broader pay-as-you-go work progressed, Copilot became the immediate launch priority. Because the new experience was already separated from the legacy model, we could focus on Copilot without waiting for all 18 services to transition.
Copilot introduced requirements such as nested services and user scoping that weren't shared by every metered service. I worked with PM and engineering to determine what belonged in the common billing model and what should remain service-specific.
- Billing policies
- Billing destinations
- Budgets and alerts
- Roles and access
- Common policy patterns
- Copilot configuration
- User scoping where required
- Service-specific management
Increasing pay-as-you-go visibility
The longer-term direction was to move pay-as-you-go from general Settings into Billing, where admins would naturally expect to manage it. That change required broader alignment than the Copilot launch timeline allowed.
Launching in the Copilot experience
To keep the launch moving, we placed Copilot pay-as-you-go within the Copilot navigation. It began as an interim solution, but Copilot's increasingly specialized service-management needs made the dedicated entry point useful beyond the initial launch.
The Copilot experience could support those service-specific needs while the billing-policy architecture underneath remained shared.
Microsoft 365 Backup tested the shared architecture
Copilot demonstrated that the model could accommodate a new, high-priority service. Microsoft 365 Backup tested the other side of the system: integrating an established service with existing administration and customer configurations.
Backup had already prepared for the new departmental billing infrastructure, but its experience predated the shared billing model.
Integration questions
Roles & access
How should existing Backup administration map to shared RBAC?
User setup
How could Backup retain its existing user configuration?
Service settings
Which settings belonged to Backup versus the billing policy?
Outcome
We mapped Backup to the shared access model without creating a separate RBAC pattern, preserved its existing user configuration, and kept service-specific settings within Backup.
The billing architecture remained consistent while the service retained the configuration that genuinely belonged to it.
A migration model for different customer and service states
The new experience solved the coexistence problem, but Microsoft services could not all move to the new departmental-billing infrastructure at the same time. An organization could therefore use services across both infrastructure generations while the ecosystem transitioned.
Starts directly in the new billing experience for supported services.
Continues using the existing configuration for services that have not yet adopted the new billing infrastructure.
Uses the new billing model for services that have adopted the departmental-billing infrastructure.
An organization can use the new model for migrated services while other services remain on the legacy infrastructure.
Designing beyond the happy path
Migration also needed to account for entry points outside our immediate control:
- Existing documentation
- Bookmarks
- Deep links
- Legacy admin paths
I defined transition principles that could be applied across services:
Preserve existing configuration wherever possible.
Route admins based on their current state.
Ask for input only when a real decision is required.
Allow services to migrate incrementally.
This established the foundation for progressively automating migration as more services became compatible with the new infrastructure.
Consistency where it matters, flexibility where services need it
Copilot, Backup, and the broader metered-services ecosystem made it clear that scale did not mean making every service identical. I defined the boundaries between the shared billing system and areas product teams could adapt.
- Billing-policy model
- Subscription and resource relationships
- Core terminology
- Budget and alert behavior
- Common states and interaction patterns
- Migration principles
- Administration patterns
- Service-specific configuration
- User or organizational scope
- Product-specific permissions
- Settings outside the billing policy
- Service-management experience
Turning decisions into a reusable framework
I turned the model, recurring patterns, migration principles, and customization boundaries into a service-agnostic design blueprint—a common reference that let design, PM, engineering, and adopting product teams onboard additional services without reopening foundational decisions each time.
From one billing policy to a platform for a growing ecosystem
Enterprise billing
Departmental billing
Organizations can structure pay-as-you-go across departments and different Azure billing destinations.
Spend management
Budgets and alerts provide greater oversight of metered consumption, addressing an important blocker for Copilot.
Discoverability
Pay-as-you-go management moved toward more visible and contextually relevant destinations.
Integrated setup
Key billing configuration can be completed with less movement between administrative tools.
Platform
A shared billing architecture designed to support multiple departments, services, subscriptions, administrative boundaries, budgets, and migration states.
Product teams
A reusable framework defines what stays consistent and what services can adapt, giving teams a path to adopt pay-as-you-go without redesigning the billing system for every product.
The result
Pay-as-you-go evolved from a single-policy experience into a shared billing system that could support new enterprise requirements, accommodate services with different needs, and transition a growing ecosystem over time.