Zum Hauptinhalt springen

SLA-Breach-Watchdog: gebrochene Tickets automatisch eskalieren

Am Ende dieses Rezepts sitzt kein Support-Ticket still über seine Deadline hinaus — im Moment, in dem ein Ticket seine SLA bricht, flaggt Copera die Zeile, fasst zusammen, was der Kunde braucht, und eskaliert an Owner und Support-Lead, automatisch. Weil Ihre Tickets, Ihre SLA-Timer und Ihr Team-Chat in einem Workspace leben, erreicht die Eskalation die richtige Person im Moment, in dem die Uhr abläuft, statt Stunden später in einem Report, den niemand rechtzeitig liest.

Bereitschaft: Jetzt verfügbar (gebaut als Automation). Die Version, in der ein einzelnes benanntes Teammitglied SLAs über jedes Board beobachtet und von allein eskaliert, rollt im Early Access aus.

Was es tut​

Im Moment, in dem der SLA-Countdown-Timer eines Tickets sein Ziel überschreitet — Resolve within 4 hours, First response within 30 minutes, was auch immer Ihre Vereinbarung sagt — handelt dieser Watchdog. Er wartet nicht, bis ein Mensch den roten Timer auf dem Board bemerkt; er feuert auf dem Breach selbst und treibt die Eskalation für Sie.

Ein Breach ist kein Mystery-Event, nach dem Sie pollen müssen. Auf Ihrem Ticket-Board wird ein Countdown-SLA-Timer bereits amber bei 75 % des Ziels, red bei 90 % und red-pulsing im Moment des Breaches. Dieser Watchdog verwandelt diesen finalen, unübersehbaren Zustand in Aktion. Wenn ein Ticket bricht, er:

  • Flaggt die Zeile Escalated und stempelt die exakte Breach-Zeit, damit der Miss im Record ist und in jedem Filter und jeder View erscheint.
  • Fasst den Fall zusammen — ein AI-Schritt verdichtet Subject, Description und die letzten Replies zu einer einzeiligen „hier ist, was der Kunde braucht und warum es stecken geblieben ist“, damit niemand das Ticket öffnen muss, um es zu verstehen.
  • Eskaliert an den Owner mit einer Direktnachricht, die er nicht verpassen kann, und holt Ihren Support-Lead ins Boot, indem er das gebrochene Ticket und einen Link in einen Support-Leads-Kanal postet.

Der entscheidende Unterschied zu einem Deadline Concierge, der vor einem Due Date nudgt, ist, dass ein Watchdog auf dem Breach feuert — dem Punkt, an dem ein Versprechen an einen Kunden tatsächlich gebrochen wurde und jemand die Recovery jetzt besitzen muss:

Das SignalWas der Watchdog tutWer davon hört
SLA-Timer bricht (Ziel überschritten)Flaggt Escalated, stempelt die Breach-Zeit, entwirft eine einzeilige SummaryDer Ticket-Owner (Direktnachricht) und der Support-Lead (Kanal)
Optional: nahender Breach (Frühwarnung)Warnt, solange der Countdown noch amber ist, bevor das Versprechen brichtDer Ticket-Owner, privat
Optional: Urgent-Tier (Condition auf Priority)Alarmiert einen Lead sofort und entwirft eine Kunden-E-MailDer Lead, plus ein Draft zum Senden durch einen Menschen

So bauen Sie es selbst​

Jedem Ticket einen SLA-Timer geben

Fügen Sie auf Ihrem Support-Board eine Countdown-SLA-Spalte mit einer Ziel-Dauer hinzu (z. B. 4 Stunden bis Resolve). Konfigurieren Sie sie so, dass sie startet, wenn ein Ticket Open oder In Progress betritt, bei Waiting for Customer pausiert und bei Resolved oder Closed stoppt — damit die Uhr nur läuft, solange Ihr Team wirklich verantwortlich ist. Hängen Sie einen Business-Kalender an, wenn Ihre SLA Arbeitsstunden zählt, nicht Übernacht. Dieser Live-Timer ist das Signal, auf dem der ganze Watchdog läuft.

Trigger: SLA breached

In Automations fügen Sie einen SLA breached-Trigger auf der Support-Tabelle hinzu. Er feuert für ein spezifisches Ticket im exakten Moment, in dem sein SLA-Timer sein Ziel überschreitet — kein Polling, kein geplanter Scan, keine Lücke zwischen Breach und Response.

Condition: nach Severity routen (optional)

Fügen Sie direkt nach dem Trigger eine Condition hinzu, damit die Response proportional bleibt. Ein Compare-Check — Priority equals Urgent or High — kann den Flow teilen: dringende Breaches nehmen die volle Eskalation unten, routinemäßige nur den Owner. Überspringen Sie das, wenn jeder Breach dieselbe Behandlung verdient.

AI step: Fall zusammenfassen

Fügen Sie einen AI → Summarize-Schritt hinzu, der das Ticket — Subject, Description und letzte Replies — zu einer einzeiligen Notiz verdichtet: was der Kunde braucht und warum es stecken blieb. Das macht die Eskalation sofort lesbar: Owner und Lead sehen die Situation, ohne das Ticket zu öffnen.

Actions: Breach flaggen und stempeln

Fügen Sie eine Set field-Aktion hinzu, um den Ticket-Status auf Escalated zu setzen, und eine Set date to now-Aktion, um eine Breached at-Spalte zu stempeln. Jetzt ist der Miss auf dem Board sichtbar, sortierbar und zählbar — Sie können aus diesen zwei Feldern allein eine View alles bauen, was diese Woche gebrochen hat.

Actions: an Owner und Lead eskalieren

Fügen Sie eine Send direct message-Aktion an den zugewiesenen Owner des Tickets mit Summary und Link zur Zeile hinzu — ein Ping, den er in einem Klick umsetzen kann. Fügen Sie dann eine Post channel message-Aktion in Ihren support-leads-Kanal hinzu, damit Leadership den Breach in Echtzeit sieht. Lieber eine leisere Eskalation? Tauschen Sie den Kanal-Post gegen Send notification oder Assign user(s), die einen Manager auf die Zeile ziehen.

tipp

Fangen Sie es, bevor es bricht. Der Watchdog oben feuert auf dem Breach. Um vorher zu warnen, stempeln Sie ein Resolution due-Datum, wenn ein Ticket öffnet (eine Set date relative-Aktion — Erstellungszeit plus Ihr SLA-Fenster), und fügen Sie eine zweite Automation mit einem Date reached-Trigger eine gewählte Zeit vor diesem Datum hinzu — z. B. 30 Minuten vor einer 4-Stunden-SLA. Sie sendet dem Owner eine Direktnachricht, solange der Countdown noch amber ist, damit viele Breaches nie passieren. Dasselbe Board, eine Extra-Automation, ein komplettes Frühwarnsystem.

tipp

Ein Trigger pro Automation — also mit Conditions tiern. Eine Automation hat genau einen Trigger, aber ein Condition-Block kann verzweigen. Einmal auf SLA breached triggern, dann branchen: Urgent → in den Leads-Kanal posten, Manager zuweisen und eine Kunden-E-Mail draften; alles andere → nur den Owner DM. Ein Watchdog, eine Response skaliert danach, wie sehr der Breach wirklich zählt.

Oder fragen Sie einfach Ask Copera AI​

Sie müssen den Graphen nicht von Hand zusammenbauen. Öffnen Sie Ask Copera AI und beschreiben Sie den Watchdog:

„Baue auf unserem Support-Board eine Automation: Wenn die SLA eines Tickets bricht, fasse zusammen, was der Kunde braucht, setze den Ticket-Status auf Escalated, sende dem zugewiesenen Owner eine Direktnachricht, dass es gebrochen ist, und poste das Ticket mit Link in den #support-leads-Kanal.“

Ask Copera AI plant, entwirft, validiert und legt den Automation-Graphen für Sie an — den SLA-breached-Trigger, den Summarize-Schritt und die Set-field- und Messaging-Aktionen — und gibt ihn zur Review zurück. Mit dem Standard-Berechtigungsmodus Ask before acting zeigt es eine Review-Karte, bevor die Automation angelegt wird, damit Sie Wording und Routing freigeben, bevor etwas live geht.

Es handhabt auch den einmaligen Sweep on demand: „Welche Tickets auf dem Support-Board haben ihre SLA gebrochen und sind nicht resolved? Fasse jedes zusammen und DM die Owner.“ Es liest das Board, listet die aktuellen Breaches und benachrichtigt jeden Owner — ohne auf das nächste Event zu warten. Siehe Was Copera AI kann für die volle Liste der Aktionen.

Machen Sie es zu einem festen Teammitglied​

Early Access

Stehende KI-Teammitglieder rollen schrittweise aus. Wenn eines Ihren Workspace erreicht, kann ein benanntes „SLA Watchdog“-Teammitglied das end-to-end besitzen: SLA-Timer über jedes Support-Board beobachten, jeden Breach an seinen Owner eskalieren, den richtigen Lead ins Boot holen, die View gebrochener Tickets aktuell halten und die Misses der Woche reporten — alles nach eigenem Zeitplan, unter eigener Identität. Bis dahin erledigt die Automation oben das heute. Alles hier lässt sich jetzt als Automation bauen.

Tipps​

tipp

Pausieren Sie die Uhr, wenn der Ball beim Kunden liegt. Konfigurieren Sie die SLA-Spalte so, dass sie bei Status Waiting for Customer pausiert, damit der Timer nie Zeit zählt, die nicht die Schuld Ihres Teams ist — und der Watchdog nie dafür feuert. Sie können den Timer auch aus einer Automation mit der SLA timer control-Aktion starten, pausieren oder stoppen, wenn eine Status-Änderung allein nicht reicht.

tipp

Lesen Sie den Raum mit Sentiment. Fügen Sie vor der Eskalation einen AI → Sentiment- oder AI → Classify-Schritt hinzu, damit der Breach eines wütenden oder VIP-Kunden direkt an einen Manager geht, während ein routinemäßiger nur den Owner pingt. Der Breach ist der Trigger; der Ton entscheidet, wie laut der Alarm ist.

tipp

Halten Sie alles Kunden-Facing hinter einem Draft. Interne Direktnachrichten und Kanal-Posts können direkt durchgehen — niemand draußen sieht sie. Aber wenn eine Stufe Ihrer Eskalation dem Kunden eine Entschuldigung oder ein Update mailt, nutzen Sie Draft- oder Approval-Zustellung auf der Send or draft email-Aktion, damit ein Mensch das Wording zuerst freigibt.

tipp

Setzen Sie ein Spend-Cap auf den Watchdog. Weil er bei jedem Breach eine AI-Summary laufen lässt, geben Sie der Automation ein Spend-Cap pro Automation und beobachten Sie das Usage-Dashboard. Ein rauer Tag voller Breaches kann dann nie über ein Budget Ihrer Wahl laufen — der Run stoppt einfach und meldet es.

Häufig gestellte Fragen​

Kann Copera ein Ticket automatisch eskalieren, wenn seine SLA gebrochen wird?​

Ja. Ein SLA breached-Trigger feuert im Moment, in dem der SLA-Countdown-Timer eines Tickets sein Ziel überschreitet. Die Automation kann die Zeile als Escalated flaggen, die Breach-Zeit stempeln, dem zugewiesenen Owner eine Direktnachricht senden und das Ticket in einen Support-Leads-Kanal posten — ohne dass jemand die Uhr beobachtet.

Woher weiß Copera, dass eine SLA gebrochen wurde?​

Jedes Ticket trägt einen Countdown-SLA-Timer mit einer Ziel-Dauer, z. B. Resolve within 4 hours. Wenn die verstrichene Zeit dieses Ziel überschreitet, bricht der Timer und feuert die Automation. Wenn die SLA-Spalte einen Business-Kalender nutzt, wird der Breach in Arbeitsstunden gemessen, sodass er nie für Nächte oder Wochenenden feuert, an denen Ihr Team nicht am Ball war.

Eskaliert der Watchdog vor oder nach dem SLA-Bruch?​

Der Kern-Watchdog feuert auf dem Breach selbst. Um ihn früher zu fangen, fügen Sie eine Companion-Automation mit einem Date reached-Trigger eine gewählte Zeit vor dem Resolution-due-Datum hinzu, damit der Owner eine Warnung bekommt, solange der Countdown noch amber ist und Zeit zur Erholung bleibt.

Wer wird benachrichtigt, wenn ein Ticket seine SLA bricht?​

Wen Sie wählen. Das übliche Muster sendet dem zugewiesenen Owner des Tickets eine Direktnachricht und postet in einen Support-Leads-Kanal, aber Sie können auch eine In-App-Benachrichtigung senden, einen Manager der Zeile zuweisen oder eine E-Mail entwerfen — und dringende Breaches mit einer Condition auf Priority anders routen.

Kann es priorisieren, welche Breaches am härtesten eskaliert werden?​

Ja. Setzen Sie direkt nach dem Trigger eine Condition, die Priority oder Tier des Tickets prüft. Dringende Breaches können einen Lead alarmieren und eine Kunden-E-Mail entwerfen, während routinemäßige nur den Owner benachrichtigen — ein Watchdog, eine gestufte Antwort.

Verwandte Themen​