SLA-Reporting in HubSpot: was HubSpot nicht mitliefert

Warum die wichtigste Kennzahl selten ein Standardreport ist

HubSpot liefert Standardreports für Objekte und Zeiten: wie viele Tickets es gab, wie lange sie offen waren, in welchem Status sie stehen. Eine Erfüllungsquote ist etwas anderes. Sie ist keine Eigenschaft eines Tickets, sondern ein Verhältnis zwischen zwei Mengen, die jemand festlegen muss. Genau diese Festlegung nimmt kein Standardreport ab.

Eine Quote braucht immer zwei bewusste Entscheidungen: welche Vorgänge überhaupt zählen (die Grundgesamtheit) und woran Erfolg gemessen wird (der Zähler). Beide Entscheidungen sind fachlich, nicht technisch. Wer sie nicht trifft, bekommt trotzdem eine Zahl — nur misst sie dann etwas anderes als das, wonach die Geschäftsleitung gefragt hat.

In HubSpot heißt das Werkzeug für diese Entscheidungen Custom Formula: eine eigene Kalkulation, entweder im Custom Report Builder oder als berechnetes Feld im Workflow. Der Rest dieses Artikels führt eine solche Kennzahl von der Frage bis zum Dashboard-KPI durch und zeigt danach, dass dieselbe Mechanik ein völlig anderes Problem löst.

Die SLA-Quote bauen: fünf Festlegungen vor der ersten Formel

Bevor eine Zeile Formel entsteht, sind fünf Dinge zu entscheiden. Sie klingen nach Konfiguration, sind aber die eigentliche Arbeit — jede einzelne verändert, was die Zahl am Ende aussagt.

1. Datenquelle Tickets — die SLA hängt am Ticket, nicht am Kontakt und nicht am Deal.
2. Wöchentliche Auswertung nach Erstellungsdatum — nicht nach Abschlussdatum, sonst wandern langsame Fälle in die falsche Woche.
3. Nur abgeschlossene SLAs zählen — ein noch laufender Vorgang hat die Frist weder eingehalten noch gerissen.
4. Trennung zwischen fristgerecht und verspätet abgeschlossenen SLAs — das ist der Zähler, und er braucht eine eigene Kalkulation.
5. Ausschluss laufender oder nicht abgeschlossener SLA-Status — die Bedingung, die am häufigsten vergessen wird.

Der letzte Punkt ist der wichtigste, und sein Effekt ist heimtückisch. Lässt man laufende Vorgänge in der Grundgesamtheit, sinkt die Quote automatisch, wenn viel los ist, und steigt, wenn wenig los ist. Sie misst dann den Bearbeitungsstand, nicht die Einhaltung. Eine Kennzahl, die bei hoher Last fällt, obwohl das Team jede Frist hält, wird nach zwei Monaten zu Recht ignoriert.

Aus den fünf Festlegungen ergeben sich drei Kalkulationen: ein Zähler für alle abgeschlossenen First-Response-SLAs, ein Zähler für die fristgerecht abgeschlossenen, und die prozentuale Berechnung der Erfüllungsquote aus beiden.

Der Fehler, der 0 % erzeugt — und syntaktisch korrekt ist

An dieser Stelle passiert der Fehler, der am meisten Zeit kostet. Die Formel speichert ohne Fehlermeldung, der Report baut sich auf, und das Ergebnis lautet Woche für Woche 0 %. Nicht „keine Daten“, sondern null Prozent — was aussieht, als hätte das Team jede einzelne Frist gerissen.

Die Ursache ist keine Datenlücke. HubSpot benötigt innerhalb der Formel den internen Statuscode, nicht das sichtbare Statuslabel. Wer gegen das Label vergleicht — also gegen den Text, der in der Oberfläche steht — formuliert eine Bedingung, die syntaktisch gültig ist und trotzdem auf keinen einzigen Datensatz zutrifft. HubSpot meldet dafür nichts; eine leere Treffermenge ist kein Fehler, sie ist ein Ergebnis.

Woran man es erkennt: das Resultat ist exakt null, nicht schwankend niedrig. Eine echte schlechte Quote sieht anders aus — sie bewegt sich, sie hat Ausreißer nach oben, sie unterscheidet sich zwischen den Wochen. Eine durchgängige Nullreihe über jeden Zeitraum hinweg ist fast immer ein Formelbefund und fast nie ein Leistungsbefund.

Nach Anpassung auf den internen Wert lassen sich die tatsächlichen wöchentlichen Erfüllungsquoten darstellen. Die allgemeine Regel dahinter gilt weit über SLAs hinaus: In Formeln wird gegen interne Werte verglichen. Labels sind Anzeigeebene und können sich ändern, ohne dass sich am Datensatz etwas ändert.

Von der Kalkulation zum Dashboard

Eine fertige Kennzahl wird zweimal gebraucht, in zwei verschiedenen Formen. Als wöchentlicher Verlauf zeigt sie Ursachen: in welcher Woche es gekippt ist, ob es mit einem Urlaub, einer Kampagne oder einem Release zusammenfällt. Als übergreifender Single-Number-KPI erzeugt sie Verbindlichkeit: eine Zahl, die in einem Dashboard steht und auf die sich ein Team festlegen kann.

Beide aus derselben Kalkulation aufzubereiten ist wenig Zusatzarbeit und verhindert den häufigsten Streit im Reporting — dass Verlauf und Kennzahl aus unterschiedlichen Definitionen stammen und deshalb nicht zueinander passen.

Dieselbe Mechanik, anderer Anwendungsfall: Liefer- und Zahlungspläne

Custom Formulas sind kein Reporting-Werkzeug. Sie sind ein Rechenwerkzeug, und der zweite Anwendungsfall sieht völlig anders aus als der erste: mehrstufige Liefer- und Zahlungspläne direkt am Deal, umgesetzt über Custom-Mode-Formeln innerhalb eines zentralen HubSpot-Workflows.

• Automatische Berechnung des erwarteten Abschlussdatums abhängig von der Deal-Phase.
• Automatische Berechnung des Delivery Dates auf Grundlage des Expected Close Dates.
• Ein individueller Delivery Schedule mit bis zu zehn Liefer- und Zahlungsabschnitten, jeder mit eigenem Delivery Date, Payment Date und Payment Amount.
• Kontrollierte if … then … else 0-Logik, damit nur die tatsächlich belegten Tranchen rechnen.
• Automatische Neuberechnung des gesamten Zeit- und Zahlungsplans, sobald sich die zugrunde liegenden Deal-Daten ändern.

Die else 0-Klausel ist dabei nicht Kosmetik, sondern das, was die Konstruktion beherrschbar macht. Ohne sie produziert jede unbelegte Tranche einen leeren Wert, der sich durch alle nachfolgenden Berechnungen zieht. Mit ihr bleibt ein Plan mit drei Tranchen ein Plan mit drei Tranchen, obwohl die Struktur zehn zulässt.

Der Unterschied zu einer gepflegten Tabelle ist nicht Komfort, sondern Konsistenz: verschiebt sich das Abschlussdatum, rechnet der ganze Plan nach. Eine Tabelle würde still veralten, und niemand wüsste, ab wann.

Was dieser Aufwand einbringt, lässt sich an eigenen, veröffentlichten Projekten zeigen — beide Male ging es genau darum, wiederkehrende Handarbeit aus HubSpot herauszunehmen:

Beide Zahlen stammen aus veröffentlichten Case Studies auf dieser Website und stehen dort im zitierten Wortlaut. Sie belegen die Richtung, nicht eine Garantie: was ein bestimmter Umbau in einem bestimmten Team bringt, hängt davon ab, wie viel Handarbeit vorher drinsteckte.

Wann sich der Aufwand lohnt — und wann nicht

Nicht jede Frage rechtfertigt eine eigene Kalkulation. Die Grenze verläuft nicht an der Komplexität der Formel, sondern an der Wiederholung: eine Zahl, die einmal gebraucht wird, ist ein Export. Eine Zahl, nach der jede Woche gefragt wird, ist ein Feld.

Und eine Warnung, die aus derselben Erfahrung stammt wie der 0-%-Fehler: jede Kalkulation ist eine Definition, die jemand in sechs Monaten lesen können muss. Was die Grundgesamtheit ausschließt und warum, gehört in die Beschreibung des Reports — nicht in den Kopf der Person, die ihn gebaut hat.