Omnichannel Routing: Tickets automatisch zum richtigen Agenten
Wer viele Kanäle bedient, kennt das alte Muster: Trigger schieben Tickets in Gruppen-Views, und die Agenten picken sich raus, was sie mögen. Das Einfache zuerst, das Mühsame bleibt liegen. Omnichannel Routing dreht das um. Zendesk verteilt aktiv, statt eine Warteschlange zum Selbstbedienen hinzustellen.
Was Omnichannel Routing ist
Omnichannel Routing weist neue und offene Tickets aus E-Mail (inklusive Webformular, Side Conversations und API), Messaging und Anrufen aktiv einem konkreten Agenten zu, nach dessen Verfügbarkeit und Kapazität. Nicht der Agent zieht das Ticket, das System schiebt es.
Der Kern ist ein einheitlicher Agentenstatus: Statt sich pro Kanal getrennt online zu setzen, hat der Agent einen Status für E-Mail, Voice und Messaging zusammen. Wer auf «Online» steht und Platz hat, bekommt automatisch Arbeit. Auf Professional lassen sich zusätzlich bis zu fünf eigene Status wie «In der Sitzung» definieren, auf Enterprise bis zu 100.
Voraussetzungen: aktivierter Agent Workspace, ein Suite-Plan ab Team, und für Messaging eine aktive Chat- bzw. native Messaging-Integration; Talk nicht in der Lite-Edition. Bei neu erstellten Zendesk-Konten ist das Routing inzwischen von Haus aus aktiv; die folgende Umstellung betrifft vor allem bestehende Instanzen. Beim Einschalten werden alle Agenten erst einmal offline gesetzt und müssen ihren Status neu wählen. Das kündigt man dem Team vorher an.
Nicht alles fliesst durch das Routing: Light Agents bekommen keine zugewiesenen Tickets, und eine von einem Bot geführte Messaging-Unterhaltung landet erst im Routing, sobald sie an einen Menschen eskaliert.
public/werkstatt/bauplaene/omnichannel-routing/queues.png
Queues, Skills, Kapazität
Verteilt wird über Queues. Ist niemand frei, wartet das Ticket in der Queue, bis ein Agent Kapazität hat.
- Standard-Queue (Gruppen-basiert): Das Ticket geht an die Gruppe, die auf dem Ticket steht. Reicht für einfache Setups.
- Custom Queues (ab Professional): eigene Bedingungen, dazu Primary- und Secondary-Gruppen. Secondary ist der Überlauf, der erst greift, wenn in den Primary-Gruppen niemand frei ist. Das zugewiesene Gruppenfeld des Tickets wird dann ignoriert. Bis zu 199 Custom Queues sind möglich.
- Subqueues (nur Enterprise): eine Custom Queue in bis zu fünf Teile aufteilen, mit Prozentanteilen, die zusammen 100 % ergeben. Innerhalb einer Subqueue wird zufällig zugewiesen.
Ein Fallstrick beim Mischen: Ein Ticket, das auf eine Custom Queue passt, wird über diese verteilt, nicht über die Standard-Queue, und das unabhängig von der Priorität. Wer beides parallel betreibt, sollte die Bedingungen der Custom Queues sauber abgrenzen, sonst greift die Standard-Queue seltener als gedacht.
Innerhalb der Queue bestimmt die Reihenfolge, wer zuerst drankommt. Sortieren nach Zeit bis zum SLA-Verstoss gibt es ab Growth, nach Priorität und Zeitstempel ab Professional. Tickets mit einem SLA-Ziel kommen dabei vor Tickets ohne. Zugewiesen wird dann an den verfügbaren Agenten mit der meisten freien Kapazität für diesen Kanal; bei Gleichstand an den, der am längsten kein Ticket aus diesem Kanal bekommen hat.
Die Kapazität setzt man pro Kanal: etwa 3 Chats und 5 E-Mails gleichzeitig. Für Anrufe ist der Wert immer 0 oder 1, mehr als ein Telefonat gleichzeitig geht nicht. So blockiert ein Anruf nicht die E-Mail-Bearbeitung. Skills (ab Professional) hängen das Ticket zusätzlich an das passende Können: Nur wer den Skill hat, kommt infrage.
Setz die Werte am Anfang eher tief an und zieh sie nach, wenn das Team Luft hat. Zu hohe Kapazität schiebt Arbeit an Leute, die schon voll sind. Welchen Agenten das System bei freier Wahl nimmt, hängt zudem von der Bewertungsmethode ab: nach Anzahl der freien Plätze oder nach Prozent der noch offenen Kapazität. Bei ungleich grossen Kapazitäten pro Person verteilt die Prozent-Variante gleichmässiger.
Was passiert, wenn niemand annimmt
Ein zugewiesenes Ticket bleibt nicht liegen, nur weil der Agent gerade nicht am Platz ist. Bei E-Mail und Messaging hat er ein Zeitfenster, um anzunehmen, standardmässig 30 Sekunden. Nimmt er nicht an, wird das Ticket neu zugewiesen, an den nächsten passenden Agenten. Das ist der operative Gewinn gegenüber «Ticket liegt in einer View»: Es gibt keine stille Warteschlange, in der etwas vergessen wird.
Anrufe laufen anders. Ein Anruf lässt sich nicht nachträglich umverteilen. Er wird der Reihe nach (Round-Robin) an verfügbare Agenten geklingelt, bis einer abnimmt oder die maximale Wartezeit erreicht ist. Das ist auch der Grund, warum die Talk-Kapazität nur 0 oder 1 kennt.
Trigger-basiert vs. Omnichannel: der eigentliche Unterschied
Trigger verschwinden nicht. Sie laufen weiter bei jedem neuen oder geänderten Ticket und erledigen weiterhin Gruppe setzen und, für E-Mail, das Auto-Routing-Tag vergeben. Das ist die Vorarbeit.
Der Unterschied liegt danach. Der klassische Weg endet bei der Gruppe: Das Ticket landet in einer View, und die Zuweisung an eine Person ist Handarbeit oder Selbstbedienung. Omnichannel Routing macht diesen letzten Schritt selbst: Es wählt aus der Gruppe den konkreten Agenten, der gerade am freiesten ist. Kein Rosinenpicken, keine liegengebliebenen unbeliebten Tickets, gleichmässigere Last.
Für die Umstellung heisst das: Dünn den Trigger-Satz aus. Für die Zuweisung braucht es nur zwei Dinge zuverlässig, das Auto-Routing-Tag und eine Standard-Priorität (etwa «Normal»), damit jedes Ticket ein Ordnungskriterium in der Queue hat. Richte eine Fallback-Queue mit niedrigster Priorität ein, in der Tickets landen, die auf keine andere Queue passen; so fällt nichts durch. Und leg dir eine View «wartende Tickets» an, damit die Teamleitung sieht, was gerade in den Queues hängt.
Kurz: Trigger bereiten das Ticket vor (Gruppe, Tag, Priorität), Omnichannel Routing bringt es zur richtigen Person. Für Betriebe mit mehreren Kanälen und echtem Volumen ist das der Punkt, an dem Verteilung vom Zufall zur Regel wird.
Predictive Routing als nächster Schritt
Wer Queues, Kapazität und Trigger sauber stehen hat, kann eine Stufe draufsetzen. Predictive Routing schätzt aus dem Nachrichtentext Intent, Sprache und Sentiment und leitet danach weiter, bisher nur für Messaging. Es lohnt sich als Ergänzung zu einer stabilen Basis, nicht als Ersatz für sie. Die Reihenfolge also: erst die Grundverteilung zum Laufen bringen, dann Skills, dann Predictive.