Pricing Philosophy

The problem

Most MSPs price everything “per seat” or “per user” and call it a day. It’s simple — one number, one line on the invoice — but it hides a math problem that compounds every month.

Your email protection vendor charges you per mailbox. Your endpoint security vendor charges per workstation. Your server backup vendor charges per server. Your help desk costs scale per user. These are four different quantities, four different unit costs. But when you flatten all of them into a single “per seat” price, you lose the ability to see which bundles are profitable and which are quietly bleeding margin.

A client with 50 users, 60 workstations, and 45 mailboxes isn’t a uniform “50 seats” across every bundle. If you price it that way, you’re either overcharging on bundles tied to the smaller count or undercharging on bundles tied to the larger one — and you can’t tell which without going back to the spreadsheet.

ClarityCalc fixes this by keeping two concepts separate that MSPs usually conflate: the unit you’re costed against, and the unit you bill the client.

---

The concepts

Unit types — what you actually pay on

A unit type is the real-world thing a bundle costs money against. It’s determined by the vendor or the nature of the work, not by how you choose to bill.

• Email protection → costs per mailbox
• Endpoint antivirus → costs per workstation
• Server backup → costs per server
• Help desk labor → scales per user

You define unit types once in ClarityCalc and assign them to bundles in your catalog. They don’t change per client — a mailbox is a mailbox whether the client has 10 or 500.

Unit counts — facts about the client

A unit count is how many of a given unit type a specific client has. These are stored on the client profile — not on the plan, and not on the bundle.

For a client like ABC Company:

You set these once per client. Every plan and every bundle calculation pulls from them automatically. You never enter quantities per bundle row or per plan — the numbers flow from the client profile.

Seats — how you bill the client

A seat is your chosen billing unit — the single number on the client invoice that normalizes all your bundle costs into one line. Every MSP defines “seat” differently:

• Some MSPs define a seat as one user.
• Others define it as desktops + laptops (workstations).
• Others define it as total endpoints including servers.

You configure your seat definition at the organization level in ClarityCalc. The seat count for each client is then derived automatically from their unit counts.

This is the key distinction: unit types are a costing concept. Seats are a billing concept. ClarityCalc keeps them separate so the math between them is always visible and auditable.

---

How it works in ClarityCalc

The cost-to-price chain

Every bundle follows a three-step calculation:

Step 1 — Cost per client  = Sum of (cost per unit × unit count) for each component
                            using each component's own unit type
Step 2 — Cost per seat    = Cost per client ÷ Seat count
Step 3 — Price per seat   = Cost per seat ÷ (1 − target margin)
                            set in the bundle catalog, not at the plan level

Important: ClarityCalc does not apply a margin to a plan. It applies a price to each bundle. The plan’s overall margin is what you observe after adding up all your bundles — not something you configure at the plan level. Each bundle carries its own target margin, set when you define it in the catalog.

The plan total is the sum of each bundle’s revenue. The blended per-seat price and blended margin are emergent results of that composition, shown for reference.

Why step 1 matters more than it looks

Within a single bundle, there may be multiple components — catalog items and labor — each with their own unit type. ClarityCalc resolves each one independently against the client’s unit counts before summing them.

Example — Compliance Consulting bundle:

With 10 seats: cost per seat = $325.50 ÷ 10 = $32.55

The audit tool contributed $48 to that total regardless of seat count, because it’s a device license. If the client adds 2 more seats but no new desktops, the $48 spreads across 12 seats instead of 10 — and per-seat cost drops. This happens automatically. You don’t adjust anything.

Per-seat cost is therefore not simply “total cost ÷ seats.” It is “sum of each component extended by its own unit count, pooled, then divided by seats.” These produce the same result only when every component inside a bundle shares the same unit type.

Worked example — single bundle

Client: ABC Company Unit counts: 14 users, 10 desktops, 2 laptops, 10 mailboxes, 1 server Seat definition: Desktops + Laptops = Workstations Seat count: 12

Bundle: Email Protection Unit type: Mailboxes Cost per unit: $3.90/mailbox Target margin: 50% (set on this bundle in the catalog)

The MSP pays the vendor based on 10 mailboxes. The client is billed based on 12 seats. ClarityCalc bridges these two numbers transparently — you always know your true cost ($39.00), your true margin (50%), and exactly how the client price ($78.00) was derived.

Worked example — full plan

Add more bundles to the same client. Each has its own target margin set in the catalog:

Every row has a different unit type, a different unit count, and a different per-unit cost. They each carry their own margin. The plan total and blended per-seat figures are calculated from the bottom up — not configured from the top down.

If the endpoint security vendor raises their price to $2.00/workstation, ClarityCalc recalculates that row. The other three don’t change. The plan’s blended margin updates to reflect the new composition.

What you can and can’t edit per bundle

Because unit counts are facts about the client, not choices you make per bundle, ClarityCalc doesn’t let you override quantities on individual bundle rows.

The only per-row edit is a unit price override — an intentional, auditable exception to the catalog price for a specific client. Everything else flows from the catalog and the client profile.

Handling subsets the right way

A common scenario: a client has 50 workstations, but only 40 run your premium endpoint protection. The other 10 are legacy machines on a separate contract.

The tempting move is to override the quantity to 40 on the endpoint protection row. That creates a hidden exception that drifts over time and breaks your audit trail.

The right approach: create a custom unit type called “Premium Endpoints” and set its count to 40 on the client profile. Every bundle that uses that unit type calculates correctly. When a machine moves to premium coverage, you update one number in one place — the client profile — and every plan that references it recalculates automatically.

---

Design decisions

Why can’t I override quantity per bundle row? Because quantity overrides create hidden, unauditable exceptions. If a client has 50 workstations and you manually set one bundle to 40, nothing in the system records why. Six months later, nobody remembers. Custom unit types solve the same problem explicitly — the count lives on the client profile, it has a name, and every bundle that uses it stays in sync.

Why are unit counts on the client, not the plan? Because a client’s environment doesn’t change just because you’re building a new plan. They have 14 users whether you’re quoting a standard package or a premium one. Storing counts on the client means every plan for that client uses the same numbers, and updating the count once updates every active plan.

Why does ClarityCalc separate cost units from billing units? Because they’re genuinely different numbers with different sources. You pay Microsoft per mailbox. You bill the client per seat. Pretending these are the same number is what causes silent margin leaks. Keeping them separate means you can always answer “why does this bundle cost what it costs?” with a concrete, traceable calculation.

Why is margin set per bundle, not per plan? Because different bundles have different cost structures, different vendor relationships, and different risk profiles. Your backup bundle might carry 60% margin while your help desk runs at 35%. Setting one plan-level margin obscures this — you’d hit the number on paper but not know which bundles are carrying the others. Per-bundle margin makes each line item accountable on its own terms. The plan margin you see is a result, not a target.

---

Summary

ClarityCalc’s job is to make the relationship between all of these explicit, auditable, and consistent — so you never have to wonder why the numbers are what they are.

---

Related articles

• Define what counts as a seat
• Manage custom unit types
• Catalog Items vs Bundles vs Packages
• Configure organization profile and default margins
• Create bundles and attach labor and catalog items