HubSpot for MSPs: Why the Service Agreement, Not the Deal, Is the Object to Run On

A managed service provider looks at its CRM in month fourteen of a three-year agreement and finds the deal that created it, closed at $8,400 a month, sitting exactly as it was on the day it was signed. In the intervening year the client has added forty seats and closed a site, tickets from one location have tripled, and nobody has raised the rate. The deal record is a true statement about a day in the past and describes nothing about the business being run today.

This article sets out the object model a managed service provider needs in HubSpot, and the argument is narrow: the agreement rather than the deal is the object the business is run from. It begins with what HubSpot's four standard objects miss, then introduces the service agreement and the site, then covers the two measures that only make sense on an agreement — seat drift and effective hourly rate — and the renewal and margin reporting that follow from having them.

Three terms are used precisely. A service agreement is the standing contract a client is under, with a term, a rate and a seat count. A site is a physical location that contract covers. Seat drift is the gap between the seats a client is contracted for and the seats they are actually consuming.

The Four Objects and What They Miss

HubSpot's contacts, companies, deals and tickets describe a business that sells something and then supports it. That is a fair description of a great many software companies and a poor one of a managed service provider, which sells a standing obligation and supports a set of physical places and machines.

A deal closes. That is the whole point of a deal, and it is why it is the wrong home for a relationship that has not ended. Every measure an MSP actually manages — seats in use, ticket volume, effective rate, months to renewal — is a property of something continuing, and a closed deal is by definition a record of something that finished.

Tickets are closer, and they carry the support history properly (HubSpot tickets). What they cannot do is aggregate against the thing being paid for, because nothing in the standard model represents it.

The Service Agreement as the Running Object

The agreement is a custom object, associated to the company, carrying the term, the contracted seat count, the monthly rate and the renewal date (HubSpot custom objects).

Its defining property is that it does not close. A client on their third consecutive agreement has three records with three terms, and the history of what they were paying and for how many seats is readable without reconstructing it from won deals.

The deal keeps its own job and becomes smaller. It records the sale: what was quoted, what was negotiated, when it was signed, and what the estimating was measured against. It stops pretending to be the client's current state, which it was never able to describe accurately after the first amendment.

That division is the whole of the model. Everything below is a consequence of it.

Site, and Why It Is Not the Company

The second custom object is the site, and the reason it is separate from the company is that an MSP's economics are per location rather than per legal entity.

A client with one head office and four branches is one company and five sites, and the branches are where the cost is. Tickets associate to the site as well as to the company, which is what makes ticket volume by location reportable at all (HubSpot associations).

Without it, a client generating three times the expected ticket volume from one badly-cabled warehouse looks like a client generating three times the expected ticket volume. The first is a fixable problem at one address. The second is an unprofitable account, and firms cancel those.

Seat Drift

Seat drift is the difference between contracted seats and actual seats, and it is the number an MSP's CRM is least likely to be holding anywhere.

It requires two properties on the agreement rather than one: contracted_seats, set at signature and changed only by amendment, and an actual count synced from the tooling that knows (HubSpot properties). One field holding "seats" cannot express the gap, because it has already resolved it to whichever number was written last.

Drift runs in both directions and both are worth seeing. Upward is unbilled work, where the client has grown into more support than they are paying for. Downward is a renewal risk, where a client is paying for capacity they have stopped using and will notice at renewal even if nobody else does.

Effective Hourly Rate

The second measure the agreement makes possible is the monthly rate divided by the hours actually delivered against it.

A contract at $8,400 a month consuming twelve support hours is earning $700 an hour. The same contract consuming ninety hours is earning $93, and nothing in a deal record would ever say so. Both figures are computable once tickets aggregate to an agreement and time is recorded against them.

This is the number that identifies which accounts are worth renewing at the current rate and which need repricing, and it is invisible in the standard model because there is nothing for the hours to aggregate to.

The Reporting That Follows

Four reports, none of which can be built without the two custom objects (HubSpot custom reports).

Agreements by months to renewal, which is a pipeline the business genuinely has and usually manages in a spreadsheet.

Seat drift by client, sorted by the size of the gap, which is an unbilled revenue list on one side and a churn risk list on the other.

Effective hourly rate by agreement, which is the repricing conversation, ranked.

Ticket volume by site type, which separates a demanding client from a demanding building, and which is the report that changes what an MSP does next more than the other three do.

Deriving the Return

The return on this model is unusual in that most of it is not new revenue. It is revenue already being earned and not invoiced, which makes it arithmetic against records rather than a projection against assumptions, and two of the four reports above produce it directly.

Unbilled seat drift is the first and the more defensible of the two, because it counts work that has already been delivered:

recoverable = (actual seats − contracted seats) × per-seat monthly rate × months undetected

Every term is a value the model holds rather than a figure somebody supplies, which is the distinction that makes this worth computing at all. Whether the amount is actually collectable is a contract question rather than a reporting one: it depends on the agreement carrying a true-up or amendment clause, and an agreement without one turns the same number into a renewal negotiation instead of an invoice.

Repricing headroom is the second, and it is a forward figure rather than a recovery:

headroom = (hours delivered × target effective hourly rate) − current monthly rate

A positive result is an account priced below what it costs to serve, and the size of the result is what decides whether the conversation is a rate rise, a scope reduction or a decision not to renew.

The arithmetic below uses illustrative inputs rather than measured ones, because the point is the shape of the calculation and every input is a number a given provider already has:

Those two lines are computed differently and should not be added together without saying so. The first is money the business has already earned and can invoice or negotiate for once; the second recurs annually but only after a conversation that the client can decline.

Against that sits a cost with three parts: building the two custom objects and their properties, syncing an authoritative seat count from whichever system actually knows it, and the standing discipline that contracted seats change by amendment rather than by editing a field. The third is the one that erodes, and it erodes silently, because an edit looks like tidying up and destroys the drift calculation that the whole return depends on.

The ROI calculator works the same inputs if you would rather not do the arithmetic by hand.

The Business Case

What the model buys is a renewal conversation held from evidence: what the client contracted for, what they have consumed, what it has cost to serve them, and what the rate should be.

What it costs is two custom objects, a sync for the actual seat count, and the discipline that contracted seats change only by amendment. The last is the one that erodes, because editing a number is easier than raising an amendment and the edit destroys the drift calculation silently.

The case is strongest for providers with per-seat agreements across multiple client locations, which is most of the mid-market. It is weakest for project-based IT consultancies, where work genuinely is a series of deals that close and the standard model describes the business correctly.

Limits of This Model

This describes the object model rather than the tooling around it. Which system holds the authoritative seat count, and how often it syncs, is a decision about the MSP's own stack and not one this model makes.

It assumes agreements are per client. Providers selling through a master agreement with schedules beneath it need the schedule modelled as the agreement, and the master as the relationship above it.

The figures in the return section are illustrative inputs run through a stated formula, not a measured result at a named provider, and they are labelled that way because a plausible number presented as evidence is worse than no number. Nothing here establishes that the model improves margin. The narrower claim is that seat drift and effective hourly rate cannot be computed at all without somewhere for hours and seats to aggregate, and that a closed deal is not that place.

In Summary

An MSP sells a standing obligation, and HubSpot's standard objects describe a business that sells and then supports. The gap is an object that does not close.

Add two: the service agreement, carrying term, contracted seats, rate and renewal date; and the site, because the economics are per location and the tickets need somewhere to aggregate that is not the legal entity.

The deal stays, and gets smaller. It records the sale rather than the current state, which it was never able to describe accurately after the first amendment.

The two numbers to build first are seat drift and effective hourly rate. Neither exists in the standard model, and between them they answer which accounts to reprice and which to worry about.

A full portal build on this model, from object design through to the reporting, is recorded in the HubSpot for MSPs and IT services walkthrough.