Cost per endpoint, and the four places it lies to you

The title of this page overstates the case slightly. Cost per endpoint is not the only comparable number available; it is the only one that survives conversion from three different quoting units using nothing but information the proposals already contain. That is a lower bar than being right, and it is the bar that matters when three documents are due back to a board on Thursday.

Choosing the unit

Every comparison needs a denominator that all three bidders can be held to without their consent. Headcount fails, because per-device bidders never counted it and the shared-login problem makes it ambiguous anyway. Revenue fails for the obvious reason. Ticket volume fails because nobody has yours yet. What is left is the count of things somebody has to patch, monitor, back up and eventually replace, which is also the count that drives the provider's own cost.

This is not a novel move. It is the ordinary discipline of price analysis, where comparing proposed prices is the first technique available and the rules attach conditions to it, requiring prior prices to be adjusted for materially differing terms and conditions, quantities, and market factors before they can sit beside each other. Adjusting for differing quantities is exactly what the rest of this page does.

The inventory comes first

The denominator is yours to establish, not the bidders'. If you take the device count from a proposal you have adopted that bidder's scope as the measure of every other bidder, which is how the lowest count wins by default. Asset inventory is the first thing the NIST Cybersecurity Framework asks an organisation to establish under Identify, and it is a precondition here for the same reason: you cannot manage or price what you have not enumerated.

A three-site light manufacturer, 137 employees, counted properly:

Held out of that count deliberately: 22 shop-floor tablets on a locked-down profile, nine network appliances, and 61 personal phones enrolled for mail. Each of those is defensible to include and defensible to exclude. What is not defensible is including them for one bidder and not another, which is why the count gets fixed once, written down, and applied to all three.

The arithmetic

Bid X quoted $9,845 a month for the 143 workstations and laptops, with servers at $228 each and hypervisor hosts at $395 each on an optional schedule at the back of the document. Restating it at the common scope means pricing that schedule at the bidder's own rates, which is the only adjustment made anywhere on this page.

Bid Y quoted $12,310 covering all 157 outright, which is $78.41 per endpoint with no adjustment needed. Bid Z quoted $91.50 per named account against 118 accounts, which is $10,797 a month, and because its scope reaches every device a named user touches plus up to twelve servers, it covers the same 157 for $68.77 per endpoint. On the headline row the order is X, Z, Y. Converted, it is Z, Y, X.

Where the normalization misleads

Four cases, in rough order of how often they bite. Each one is a place where the converted number is arithmetically correct and practically wrong, and the honest response is to flag the mix rather than to keep dividing.

Servers counted as endpoints

A domain controller and a receptionist's desktop are one unit each in the denominator and are not one unit each in anybody's week. A server carries patch windows, backup verification, capacity monitoring and an outage blast radius that a workstation does not. Bid Y covers eleven of them inside its rate; Bid X prices them at nearly four times a workstation. Both can be right, and the per-endpoint figure hides which is which.

We do not publish a weighting factor for this, because we cannot source one. The ratios that circulate — three to one, five to one — trace back to vendor benchmark decks rather than to any measured labour study, and inventing a multiplier to make the arithmetic tidier would be exactly the failure this page is arguing against. What we do instead is show the server count as its own row so the mix is visible, and say plainly that an environment with eleven servers per 143 workstations is server-heavy and should be read that way.

Seasonal headcount

This manufacturer adds 34 warehouse temps from September through December. Under a per-named-account bid that is a surcharge for a third of the year, and levelling it changes the comparison materially.

That takes Bid Z from $68.77 to $75.37 against Bid Y's flat $78.41, and the gap that looked like $9.64 is $3.04. Whether the temps get named accounts at all is a question for your own operations people, and the answer changes the number by more than the negotiation will.

Bring your own device

Sixty-one personal phones are enrolled for mail. Counting them as endpoints is arguable, and it is also the single easiest way to make any bid look cheap: the denominator grows by 39 percent while the support burden grows by very little, because an enrolled phone generates a fraction of the tickets a laptop does.

Nothing changed except the counting rule. If a provider's proposal arrives with a per-endpoint figure already computed, the first question is which of these it included, and the second is whether the same rule was applied to the mailbox-only phones and to the servers.

Unstable denominators

The fourth case is the one in the tabulation above. Per-user pricing makes the denominator a function of an administrative process rather than a physical count, and administrative processes move. Nineteen shared shop-floor logins are being converted to named accounts for audit reasons, and on the day that finishes Bid Z gains 19 billable units it did not quote. Ask any per-user bidder to state the count it used, the date it was taken, and the mechanism by which it is refreshed.

What the number cannot carry

Cost per endpoint says nothing about response time, escalation depth, or whether the after-hours row above reflects a rota or one person's mobile number. It cannot price the difference between endpoint detection that is licensed and endpoint detection that somebody watches — a distinction the joint advisory treats as central when it tells customers to ensure their contractual arrangements require the provider to implement comprehensive security event management that enables appropriate monitoring and logging of provider-managed customer systems, with visibility of the provider's own presence and activity. Two bids at the same normalized rate can differ by the entire cost of the analysts.

It also cannot tell you whether the price is sustainable for the provider, which matters more than buyers expect over a 36-month term. Wage data for administrators in your metro is public and worth ten minutes. A bid that cannot cover competent people at that rate resolves itself eventually, usually as a re-scope at renewal or a quiet decline in who answers the phone.

Doing this on your own bids

The whole method is five steps and takes under an hour. Build the device inventory yourself and freeze it. Read each proposal for its denominator, its rate, and every optional schedule at the back. Restate each bid at your inventory using that bidder's own published rates for anything it excluded. Divide. Then write down, next to each figure, which of the four distortions above applies to it, because a converted number with no caveat attached is more dangerous than three unconverted proposals.

The last step is the one that gets skipped and the one that does the work. A tabulation is not a scoreboard. It is a device for making the remaining questions small enough to ask out loud, and the questions it leaves you with — why is this bidder's server rate four times that one's, what happens to the count in October, who exactly is on call — are the ones worth spending a discovery call on.