Contracts 2.0: The Profitability Wedge

We were winning with emerging MSPs, the small shops that picked us because we were capable and cost-efficient. That was a fine place to be and a bad place to stay. Those accounts had a ceiling, and the segment I actually wanted was the next one up: MSPs hungry to grow and obsessive about profitability, the ones building a real business rather than a comfortable side income. Winning them needed more than another feature. It needed a wedge, a reason they had to choose us specifically.

So I went looking for it in person. I spent time on the road across the US, sitting with MSPs and watching how they actually run the shop, not how they describe it in a sales call. You learn different things when you watch the back office instead of asking about it. And what kept surfacing was that none of these owners could tell you, with any confidence, which of their contracts actually made money.

Here's why, and it's the insight the trip handed me. Most MSPs sell in bundles. A Platinum plan might roll Microsoft licenses, antivirus, backup, and labor into one tidy price, billed per employee. Clean for the customer. A nightmare for knowing your real margin. Because the costs do not accrue on the unit you bill. The customer pays per employee, but the vendor bills Microsoft per user, antivirus per endpoint, backup per server, and labor by the hour. One bundle, four different cost units. To know what that contract truly earns, you have to cost each component at the unit it was actually delivered on, and only then set it against the single bundled price.

Almost nobody could do that. The diligent ones reconstructed it by hand, often paying outsourced finance teams to rebuild it in spreadsheets weeks after the fact. Everyone else simply guessed, and called the guess profit. Accurate profitability, it turned out, was not a reporting problem. It was a units problem, and it was being solved with human labor or not at all.

So that is what we built. Contracts 2.0 runs on a service-delivery map that records how every service in a bundle is actually delivered: Microsoft at the user level, antivirus at the endpoint level, backup at the server level. The plan keeps being billed however the MSP wants, per employee, per seat, whatever sells. Underneath, the engine costs each service at its true delivery unit, using the technician burden rate and accurately tracked time for labor, and computes real margin by contract, by client, by service, in real time. The output wasn't just visibility into billing errors. It was an engine that did the accurate profitability calculation automatically, the exact work those outsourced finance teams were being paid to do by hand.

That is what made it a wedge rather than a feature. The thesis underneath was simple, that every contract event should drive a revenue event, but the differentiator was accuracy nobody else could match, built around a problem only the growth-minded segment felt acutely. It let us make a positioning claim no competitor could honestly make. The product promise had always been grow efficiently. Now it was grow efficiently and know your true profitability while you do it, down to the individual contract, without a spreadsheet or a consultant. For an MSP trying to scale without quietly eroding its margins, that is the whole game.

That's the lesson I carry from it. A feature adds value for whoever already uses you. A wedge is aimed deliberately at a segment you don't yet own, built around the one thing that segment can't get anywhere else, so it changes who you can win. We led with profitability accuracy because it was the unmet, expensive, manual pain of exactly the customers we wanted, and we pointed the discovery, the costing engine, and the positioning at them all at once.

The best product surfaces are P&L surfaces. The best features are wedges. Contracts 2.0 was both, and that's why it moved the company, not just the roadmap.