Usage Based Pricing for Add-Ons With a Flat MSP Base

Separate the Base Service From the Variable Charge

A billable unit is the thing the agreement says a client pays for. A measured event is only evidence for that charge when it matches the agreed unit. A mailbox appearing in an admin report doesn't by itself establish that you can invoice it as an additional support seat or product license.

The model's seat means a billed user, or the device count if larger. An extra endpoint already reflected in that count shouldn't quietly appear again as another charge for the same included service. Keep a separately purchased service distinct from the change in base seats.

Baseline security belongs in every plan under the model. Don't add a metered surcharge for the endpoint protection or other baseline components you've already included. Advanced services can be separate, but their scope and charge still need agreement.

At the model's $22.50 monthly delivery-tool cost per seat, calculate that same hypothetical client's planned internal tool cost as 20 × $22.50 = $450 a month. That is a delivery cost inside the managed service, not an additional invoice line. An internal cost report is not permission to bill.

Choose an Add-On With a Defensible Unit

Use a variable add-on where the service has a usable count and the contract says what that count means. Separately agreed metered storage is a possible candidate when the relevant billing report can support the charge. Don't promise that a dashboard total is the billable quantity before checking its definition.

A purchased license count is a different unit from actual consumption. If the client buys committed licenses, explain that commercial arrangement instead of describing it as pay only for what you use. Confirm how additions or removals affect the actual supplier and client obligations before offering a reduction.

Write the Measurement Rule Before Automating Billing

The billing owner should be able to calculate the same charge from the retained source records. Put the measurement rule beside the service scope and have the account owner confirm that the client understands it. These are the decisions I'd require:

Don't collect a month of hourly readings and sum them if the agreed billable measure is a peak count. Likewise, a closing snapshot isn't a monthly average. Choose the rule the actual service and contract support, then verify the import implements it.

Keep the Calculation and Margin on the Same Basis

For a simple agreed rate, the variable charge equals billable quantity multiplied by the client unit price. Establish billable quantity using the agreed allowance and aggregation first. Apply a tiered schedule as agreed rather than forcing a simple-rate formula onto a different product.

Gross margin is revenue less the relevant delivery cost, divided by revenue. The model's product margin is 30%, so a product selling-price calculation is actual product cost divided by the remaining 70%. That percentage is a planning input for the product line, not proof that every metered service belongs in that category.

For a service with ongoing MSP delivery work, have the delivery lead estimate that work and include its cost in the pricing decision. A supplier unit cost alone doesn't cover a technician investigating failed jobs. Don't count an internal tool again if it is already allocated to the managed plan.

Use the agreed client selling price on the invoice and the actual supplier charge in the cost check. They answer different questions. A supplier price change needs the contractual pricing treatment; the model rejects passing supplier increases through at cost as the automatic answer.

Reconcile the Count Before Sending the Charge

Have the billing owner verify the customer mapping and charge period against the agreement. Keep the source record used for the calculation, including the applicable unit definition. A correct total assigned to the wrong client is still a wrong invoice.

Check whether the supplier data is final for the purpose you're using it. Don't reconstruct a past consumption period from today's active-resource list.

If the quantity or attribution cannot be established, hold the affected variable item for investigation. Give that exception a named owner and a next action. An unresolved usage line shouldn't automatically delay an otherwise correct base invoice.

Explain the Usage Period on the Invoice

Erick Simpson proposes separating standard managed services invoiced in advance from a later run that catches consumption-based charges. That is his billing option. Use it where your terms support the separation, and make the periods clear to the client.

Describe the add-on with its billable unit and measurement period. Keep the calculation available for a client who asks how the quantity was established. Don't make the account owner translate an unexplained supplier code after the invoice arrives.

Have the account owner discuss an unexpected increase with the client and the delivery lead. Establish the cause from the available records before promising to reverse it or labeling it unnecessary use. Where spending controls are needed, agree what action is authorized instead of assuming a budget alert stops consumption.

Prove the Rule With the First Billing Run

Before making the add-on routine, have the billing owner reproduce its charge from the saved evidence. Ask someone who didn't configure the import to check the calculation against the agreement. Resolve a mismatch before treating automation as approval.

Keep the base scope visible during that check. If you cannot explain why the variable item is separate, fix the offer before adding it to the recurring invoice. A count is useful when it supports an agreed charge, not when it gives you another number to sell.