Viele Supportteams definieren Service Level Agreements, um Reaktions- und Lösungszeiten verbindlich zu machen. In der Praxis scheitert die Wirkung eines SLA aber selten daran, dass ein Zeitwert fehlt. Häufiger ist unklar, für welche Tickets welche Frist gilt, wann die Uhr pausiert und wer bei einer drohenden Überschreitung handeln muss.
Der HubSpot Help Desk kann SLA-Ziele nach Ticket-Eigenschaften, Arbeitszeiten und Pausenbedingungen anwenden. Damit entsteht jedoch nicht automatisch ein guter Supportprozess. Entscheidend ist die fachliche Übersetzung: Welche Fälle sind wirklich kritisch? Welche Zeit beginnt zu laufen? Und welche Konsequenz folgt aus dem Status „bald fällig“?
Ein einheitliches SLA für alle Tickets ist leicht zu verstehen und zu verwalten. Für viele mittelständische Unternehmen reicht es als Einstieg aus, etwa wenn alle Anfragen über denselben Kanal eingehen und ähnliche Erwartungen bestehen.
Komplexer wird es, sobald sich Tickets nach Priorität, Quelle, Kundengruppe, Produkt oder Supportprozess unterscheiden. Eine Chat-Anfrage kann eine andere Reaktionszeit benötigen als eine E-Mail. Ein kritischer Produktionsausfall ist nicht mit einer allgemeinen Produktfrage vergleichbar. Auch für strategisch wichtige Kunden kann eine andere Vereinbarung gelten.
In HubSpot lassen sich SLA-Ziele auf alle Tickets, anhand einer einzelnen Ticket-Eigenschaft oder – je nach Subscription – anhand einer Kombination mehrerer Eigenschaften anwenden. Das ermöglicht differenzierte Regeln, erhöht aber zugleich das Risiko widersprüchlicher Konfigurationen.
Bevor SLA-Ziele eingerichtet werden, sollte das Unternehmen seine Supportfälle in wenige belastbare Klassen einteilen. Ein mögliches Modell besteht aus drei Dimensionen:
Diese Dimensionen sollten nicht automatisch zu einer großen Matrix kombiniert werden. Jede zusätzliche Regel erhöht den Pflegeaufwand und erschwert die Erklärung gegenüber dem Supportteam. Sinnvoller ist ein Modell, das reale Unterschiede abbildet und mit wenigen Regeln auskommt.
Ein Beispiel: Kritische Störungen erhalten ein kurzes Ziel für die erste Antwort und ein separates Ziel für die Lösung. Normale E-Mail-Anfragen bekommen ein längeres Antwortfenster. Für Tickets, bei denen der Kunde am Zug ist, wird der Timer pausiert. Damit wird der Prozess fachlich sauberer, ohne jede denkbare Kombination als eigene Regel abzulegen.
Bei mehreren SLA-Regeln kann ein Ticket mehr als eine Bedingung erfüllen. In diesem Fall entscheidet die Reihenfolge der Regeln, welche SLA-Vorgabe angewendet wird. Das ist kein nebensächliches Detail, sondern ein zentraler Bestandteil der Konfiguration.
Die spezifischste Regel sollte deshalb in der Regel vor allgemeineren Regeln stehen. Eine Vorgabe für „kritische Tickets aus dem Chat“ gehört beispielsweise vor eine allgemeine Regel für alle Chat-Tickets. Zusätzlich sollte eine Fallback-Regel definiert werden, damit nicht passende Tickets nicht ohne Zielwerte bleiben.
Die Regelstruktur muss dokumentiert werden. Empfehlenswert sind ein kurzer Zweck pro Regel, die verwendeten Eigenschaften und ein Beispiel-Ticket. So kann ein neues Teammitglied nachvollziehen, warum ein Ticket eine bestimmte Frist erhält, ohne die Konfiguration durch Versuch und Irrtum zu rekonstruieren.
Ein SLA ist nur dann aussagekräftig, wenn klar ist, welche Zeit tatsächlich gemessen wird. HubSpot kann Ziele für die Zeit bis zur ersten Antwort, bis zur nächsten Antwort und bis zum Abschluss abbilden. Zusätzlich können Arbeitszeiten, Zeitzonen und Pausenbedingungen berücksichtigt werden.
Die Pausenlogik ist besonders wichtig. Wenn ein Ticket auf eine Rückmeldung des Kunden wartet, sollte diese Zeit nicht automatisch als interne Verzögerung gewertet werden. Dafür braucht es jedoch einen eindeutigen Ticketstatus wie „Warten auf Kunde“ und eine verbindliche Arbeitsweise im Team. Ein Pausenstatus, den Mitarbeitende uneinheitlich setzen, macht die Kennzahl unzuverlässig.
Auch die Geschäftszeiten müssen zum tatsächlichen Supportversprechen passen. Ein SLA während der Bürozeiten ist nicht dasselbe wie eine Rund-um-die-Uhr-Zusage. Unternehmen sollten deshalb vor der Einrichtung klären, ob die Frist kalendarisch oder innerhalb definierter Servicezeiten läuft und welche Zeitzone gilt.
Viele Implementierungen beginnen direkt mit Zeitwerten. Das eigentliche Ticketmodell ist zu diesem Zeitpunkt jedoch noch nicht sauber definiert. Status, Priorität, Quelle und Verantwortlichkeit werden dann uneinheitlich verwendet oder nachträglich verändert.
Die Folge: Ein Ticket erhält zwar eine Frist, aber die zugrunde liegende Klassifizierung ist nicht belastbar. Ein „dringendes“ Ticket wird nicht nach objektiven Kriterien gesetzt. Ein Ticket bleibt im Status „in Bearbeitung“, obwohl der Kunde auf eine Information wartet. Oder ein Kanal wird technisch angebunden, ohne dass klar ist, welchem Team und welcher Pipeline die Anfragen zugeordnet werden.
Die bessere Reihenfolge lautet: erst Supportprozess und Ticketstatus definieren, dann Eingangsquellen und Standardwerte konfigurieren, anschließend SLA-Regeln einrichten und zuletzt Eskalationen sowie Reports ergänzen.
Ein SLA bringt wenig, wenn das Team erst nach Ablauf einer Frist bemerkt, dass ein Ticket überfällig ist. In HubSpot können SLA-Statuswerte in Workflows verwendet werden, um interne Benachrichtigungen oder weitere Aktionen auszulösen.
Eine sinnvolle Eskalationslogik muss nicht kompliziert sein. Bei „bald fällig“ kann zunächst der zuständige Bearbeiter informiert werden. Bei „überfällig“ erhält zusätzlich die Teamleitung eine Benachrichtigung. Für kritische Tickets kann ein Wechsel des Verantwortlichen oder eine Eskalation in ein spezielles Team vorgesehen werden.
Wichtig ist, nicht jede Warnung an alle zu senden. Zu viele Benachrichtigungen führen dazu, dass echte Eskalationen untergehen. Die Zuständigkeit, der Eskalationszeitpunkt und die erwartete Reaktion sollten deshalb pro Supportklasse festgelegt werden.
Die Einhaltung von Antwort- und Lösungszeiten ist eine wichtige Kennzahl, aber kein vollständiges Bild der Servicequalität. Ein Team kann SLA-Ziele erreichen und trotzdem unklare oder unvollständige Antworten geben. Umgekehrt kann eine Überschreitung entstehen, weil ein Fall fachlich komplex war oder auf eine externe Abhängigkeit wartete.
Für eine belastbare Bewertung sollten mindestens folgende Fragen getrennt betrachtet werden:
Der Help Desk stellt dafür Übersichten und Analysefunktionen bereit. Die Aussagekraft hängt jedoch davon ab, ob Ticketstatus, Kategorien und Pausen konsistent gepflegt werden. Reporting ist daher nicht der letzte Schritt einer SLA-Einführung, sondern ein Test für die Qualität des zugrunde liegenden Prozesses.
SMARTTEC empfiehlt, SLA-Ziele nicht als isolierte Einstellung zu behandeln. Starten Sie mit einem begrenzten Pilotprozess, beispielsweise für technische Supportanfragen aus einem klar definierten Kanal. Dokumentieren Sie die Ticketklassen, setzen Sie wenige Zielwerte und beobachten Sie zunächst, ob Statuswechsel, Pausen und Zuständigkeiten im Alltag funktionieren.
Erst danach sollten weitere Kundengruppen, Kanäle oder Eskalationsstufen ergänzt werden. Prüfen Sie außerdem bei jeder Regel, ob sie eine echte geschäftliche Unterscheidung abbildet oder nur eine theoretische Ausnahme behandelt. Wenige verständliche Regeln sind in der Praxis meist wertvoller als eine vollständig ausdifferenzierte, aber schwer pflegbare Matrix.
Zu berücksichtigen ist auch die Lizenzierung: Der Help Desk mit den genannten SLA-Funktionen ist laut HubSpot-Dokumentation für Service Hub Professional und Enterprise verfügbar. Für SLA-Regeln auf Basis einer Kombination mehrerer Ticket-Eigenschaften ist Service Hub Enterprise erforderlich. Für den Zugriff auf erweiterte Help-Desk-Funktionen wie SLAs ist außerdem ein zugewiesener Service Seat relevant. Stand: Oktober 2026.
Ein SLA ist kein einzelner Zeitwert, sondern eine Vereinbarung aus Klassifizierung, Frist, Arbeitszeit, Pausenlogik, Zuständigkeit und Eskalation. HubSpot kann diese Bausteine im Help Desk abbilden. Der fachliche Erfolg entsteht aber erst, wenn die Regeln zum tatsächlichen Supportprozess passen.
Wer mit einem klaren Ticketmodell beginnt, die Regelreihenfolge dokumentiert und aus Warnungen konkrete Handlungen macht, schafft eine belastbare Grundlage für verlässlichen Kundenservice. Wer dagegen nur kurze Fristen einträgt, misst am Ende vor allem die Qualität seiner Konfiguration – nicht die Qualität des Supports.