SLA Reporting in HubSpot: The Metric It Won't Give You

Why the metric that matters is rarely a standard report

HubSpot reports on objects and durations well: how many tickets came in, how long they stayed open, which status they carry. An attainment rate is a different animal. It is not a property of a ticket — it is a ratio between two sets that somebody has to define. No standard report makes that definition for you.

Every rate needs two deliberate decisions: which records count at all (the population) and what counts as success (the numerator). Both are business decisions, not technical ones. Skip them and you still get a number — it just answers a different question than the one leadership asked.

In HubSpot the tool for those decisions is the custom formula: your own calculation, either inside the Custom Report Builder or as a calculated property driven by a workflow. The rest of this article walks one such metric from question to dashboard KPI, then shows the same mechanic solving an entirely different problem.

Building the SLA rate: five decisions before the first formula

Five things get decided before a single formula exists. They read like configuration, but they are the actual work — each one changes what the number ends up saying.

1. Data source: tickets — the SLA hangs off the ticket, not the contact and not the deal.
2. Weekly evaluation by creation date — not by close date, or slow cases drift into the wrong week.
3. Count completed SLAs only — a case still in flight has neither met nor missed its deadline.
4. Separate on-time from late completions — that is the numerator, and it needs its own calculation.
5. Exclude open or unfinished SLA statuses — the condition most often forgotten.

The last one matters most, and its effect is quietly destructive. Leave open cases in the population and the rate drops automatically when volume is high and climbs when volume is low. It then measures workload, not compliance. A metric that falls under pressure while the team hits every deadline gets ignored within two months, and rightly so.

Those five decisions produce three calculations: a counter for all completed first-response SLAs, a counter for the ones completed on time, and the percentage attainment derived from both.

The error that produces 0 % — and is syntactically valid

This is where the expensive mistake happens. The formula saves without complaint, the report renders, and the result reads 0 % week after week. Not “no data” — zero percent, which looks like a team that missed every single deadline.

The cause is not a data gap. Inside the formula, HubSpot needs the internal status code, not the visible status label. Comparing against the label — the text you see in the interface — produces a condition that is syntactically valid and matches no record at all. HubSpot reports nothing for that; an empty result set is not an error, it is an answer.

How to spot it: the output is exactly zero, not variably low. A genuinely poor attainment rate looks different — it moves, it has good weeks, it differs by period. A flat zero across every timeframe is nearly always a formula finding and nearly never a performance finding.

Switching the comparison to the internal value makes the real weekly attainment rates visible. The general rule behind it reaches far beyond SLAs: formulas compare against internal values. Labels are a display layer and can change without anything changing in the record.

From calculation to dashboard

A finished metric gets used twice, in two different shapes. As a weekly trend it shows causes: which week it tipped, whether that lines up with holiday cover, a campaign or a release. As a single-number KPI it creates commitment: one figure on a dashboard that a team can be held to.

Preparing both from the same calculation costs almost nothing extra and prevents the most common reporting argument — that the trend and the headline number come from different definitions and therefore refuse to agree.

Same mechanic, different problem: delivery and payment schedules

Custom formulas are not a reporting feature. They are a calculation feature, and the second use case looks nothing like the first: multi-stage delivery and payment schedules attached directly to the deal, implemented with custom-mode formulas inside one central HubSpot workflow.

• Automatic calculation of the expected close date based on the deal stage.
• Automatic calculation of the delivery date derived from the expected close date.
• An individual delivery schedule with up to ten delivery and payment tranches, each with its own delivery date, payment date and payment amount.
• Controlled if … then … else 0 logic so that only the tranches actually in use are calculated.
• Automatic recalculation of the entire schedule as soon as the underlying deal data changes.

The else 0 clause is not cosmetic; it is what keeps the construction manageable. Without it, every unused tranche yields an empty value that propagates through everything downstream. With it, a three-tranche plan stays a three-tranche plan even though the structure allows ten.

The difference from a maintained spreadsheet is not convenience, it is consistency: move the close date and the whole schedule recalculates. A spreadsheet would quietly go stale, and nobody would know from when.

What that work buys can be shown from our own published projects — both were about taking recurring manual effort out of HubSpot:

Both figures come from published case studies on this site and appear there in the wording quoted. They evidence a direction, not a guarantee: what a given rebuild returns depends on how much manual work was in it to begin with.

When the effort pays — and when it does not

Not every question justifies its own calculation. The line is not formula complexity, it is repetition: a number needed once is an export. A number asked for every week is a field.

One warning from the same experience that produced the 0 % error: every calculation is a definition somebody has to be able to read six months later. What the population excludes, and why, belongs in the report description — not in the head of the person who built it.