AI-Prognosen für Support-Volumen und Personalplanung

AI-Prognose des Support-Volumens: Ein Prognosekalender wird mit der Servicekapazität abgeglichen.

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

Die Prognose des Support-Volumens bedeutet, vorherzusagen, wie viele Kundenkontakte in jedem Intervall eintreffen (meist 30 Minuten oder eine Stunde), und diese Vorhersage dann in die Zahl der Mitarbeitenden umzurechnen, die Sie in der Schicht brauchen, um ein Service-Level-Ziel zu erreichen. Es sind zwei Aufgaben, die zusammenhängen: eine Prognose der Nachfrage und eine Personalberechnung, die aus der Nachfrage Menschen macht. AI verbessert vor allem die erste Aufgabe. Die zweite ist weiterhin klassische Warteschlangenmathematik, und sie ist unerbittlich, wenn die Prognose danebenliegt.

Das ist der Teil, den Manager gern übersehen. Eine um 5% zu niedrige Prognose erzeugt kein Serviceproblem von 5%, sie kann eine Warteschlange erzeugen, die davonläuft. Dieser Leitfaden behandelt, wie die Personalrechnung funktioniert (Erlang C und seine Grenzen), wie Sie die Prognosegenauigkeit ehrlich messen, wann Machine Learning eine einfache Baseline (Ausgangswert) schlägt und wie die Deflection (Anfragenvermeidung) durch AI sowohl das Volumen als auch die Zusammensetzung des Rests verändert. Er gehört zur Collection AI for Customer Service. Der Überblick zu AI im Kundenservice ist daher der richtige Einstieg für das größere Bild.

Wichtige Fakten

  • Das Erlang-C-Modell nimmt Poisson-Ankünfte, exponentiell verteilte Bedienzeiten und eine konstante Ankunftsrate innerhalb jedes Intervalls an und ignoriert Blockierung, Abbruch und Wiederholungsversuche (Gans, Koole und Mandelbaum).
  • Das Beispiel desselben Papers: Ein Center, das für 95% Auslastung geplant ist und dessen Ankunftsrate 5% höher ausfällt, sieht die Auslastung auf 99,75% steigen, und die Wartezeiten explodieren oder die Abbrüche übersteigen den Plan bei Weitem (Gans, Koole und Mandelbaum).
  • Die Shrinkage im Contact Center liegt typischerweise zwischen 25% und 40% der geplanten Zeit, mit Durchschnittswerten um 30-35% (NICE).
  • Hinweis aus dem Lehrbuch zur Prognose: Einfache Benchmarks wie Seasonal Naive sollten geschlagen werden, bevor eine ausgefeiltere Methode überhaupt in Betracht kommt (Hyndman und Athanasopoulos, FPP3).
  • In einem großen Vergleich statistischer und Machine-Learning-Methoden wurden die Machine-Learning-Methoden bei beiden Genauigkeitsmaßen und über alle untersuchten Prognosehorizonte hinweg übertroffen und brauchten weit mehr Rechenleistung (Makridakis et al., PLOS ONE).

Von der Prognose zum Personalbedarf: Was Erlang C leistet

Erlang C ist das Arbeitspferd der Personalplanung im Contact Center. Sie geben eine Ankunftsrate, eine durchschnittliche Bearbeitungszeit und ein Ziel vor, und es sagt Ihnen, wie viele Mitarbeitende Sie in diesem Intervall brauchen. Der Überblick von Gans, Koole und Mandelbaum zum Fachgebiet beschreibt die gängige Praxis: Erlang C für jedes Halbstundenintervall rechnen, jedes als stationären Zustand behandeln und mit der prognostizierten Ankunftsrate und Bedienzeit eine Ziel-Personalstärke für den Zeitraum ermitteln. Diese Werte pro Intervall fließen dann in das Schichtplanungsmodell ein (Gans, Koole und Mandelbaum).

Von der Support-Prognose zur Personalplanung: Eine Servicewarteschlange mit Reservepersonal.

Vier Begriffe leisten die meiste Arbeit:

  • Verkehr (in Erlang) ist die Arbeitslast. Kontakte im Intervall mal durchschnittliche Bearbeitungszeit, geteilt durch die Intervalllänge. 120 Kontakte mit je 300 Sekunden in einer Halbstunde von 1.800 Sekunden sind 120 x 300 / 1.800 = 20 Erlang. Einfach gesagt: Sie brauchen 20 Mitarbeitende, nur um Schritt zu halten.
  • Service Level ist der Anteil der Kontakte, die innerhalb eines Schwellenwerts beantwortet werden, etwa 80% in 20 Sekunden.
  • Auslastung (Occupancy) ist der Anteil der Arbeitszeit der Mitarbeitenden, den sie mit der Bearbeitung von Kontakten verbringen. Bei 25 Mitarbeitenden, die 20 Erlang tragen, beträgt die Auslastung 20 / 25 = 80%.
  • Shrinkage ist der Anteil der bezahlten Zeit, in der Mitarbeitende nicht verfügbar sind: Pausen, Schulungen, Meetings, Abwesenheit. NICE definiert sie als Stunden, die durch unproduktive Tätigkeiten verloren gehen, geteilt durch die gesamten geplanten Stunden, und unterteilt sie in interne (geplante) und externe (ungeplante) Shrinkage (NICE).

Ein durchgerechnetes Beispiel

Angenommen, eine Warteschlange erwartet in einer Halbstunde 120 Kontakte bei 300 Sekunden durchschnittlicher Bearbeitungszeit, und Sie wollen 80% innerhalb von 20 Sekunden beantworten. Mit den üblichen Erlang-C-Formeln ergeben sich diese Zahlen:

Mitarbeitende in der Warteschlange Auslastung Service Level (beantwortet in 20 s) Durchschnittliche Antwortgeschwindigkeit
22 91% 50,3% 85 Sekunden
23 87% 66,0% 42 Sekunden
24 83% 77,2% 22 Sekunden
25 80% 85,0% 13 Sekunden
26 77% 90,4% 7 Sekunden

Vierundzwanzig Mitarbeitende verfehlen das Ziel, fünfundzwanzig erreichen es. Rechnen Sie nun die Shrinkage hinzu. Bei 30% Shrinkage bedeuten 25 produktive Mitarbeitende 25 / (1 - 0,30) = 35,7, Sie würden also 36 Personen für diese Halbstunde einplanen.

Und hier ist das Prognoserisiko im selben Beispiel. Wenn das Volumen 5% höher ausfällt als geplant (126 Kontakte statt 120) und Sie 25 eingeplant haben, sinkt das Service Level von 85,0% auf etwa 76,5%. Eine Abweichung von 5% beim Volumen brachte Sie unter das Ziel. Bei 24 Mitarbeitenden drückt dieselbe Abweichung von 5% das Service Level auf etwa 65%. Die Kurve ist steil, und genau davor warnt das Paper von Gans: Weil die Leistung eine konvexe Funktion der Ankunftsrate ist, fällt die tatsächliche Leistung bei einer unsicheren Prognose typischerweise schlechter aus als der Plan, nicht gleich gut (Gans, Koole und Mandelbaum).

Wo Erlang C an Grenzen stößt

Erlang C ist ein Modell, und das Modell hat bekannte Grenzen. Die Liste des Überblicks selbst sollten Sie griffbereit haben: konstante Raten innerhalb eines Intervalls, Poisson-Ankünfte, exponentielle Bedienzeiten, und Blockierung, Abbruch und Wiederholungsversuche werden ignoriert (Gans, Koole und Mandelbaum). In der Praxis heißt das:

  • Kein Abbruch. Erlang C tut so, als würde jeder Kunde so lange warten, wie es dauert. Echte Kunden legen auf oder schließen den Chat. Derselbe Überblick weist darauf hin, dass ohne Abbruch eine Ankunftsrate über der Kapazität die Warteschlange unbegrenzt wachsen lässt, während Modelle mit Abbruch stabil bleiben und es erlauben, Kapazität gegen Abbruch und Verzögerung abzuwägen.
  • Bekannte Ankunftsraten. Es behandelt die Prognose als Wahrheit. Wie das Paper es ausdrückt, wird die Ankunftsrate aus historischen Daten vorhergesagt und ist nicht mit Sicherheit bekannt, und das zu ignorieren kann riskant sein.
  • Ein Kontakt nach dem anderen. Die klassische Formel passt auf Kanäle mit einem einzelnen Kontakt wie das Telefon. Mitarbeitende im Chat und Messaging führen mehrere Konversationen gleichzeitig, und E-Mail ist asynchron, daher passen Teams meist mit einem Parallelitätsfaktor an oder verwenden andere Modelle. Betrachten Sie die obige Tabelle als den Fall Telefon.
  • Identische Mitarbeitende. Neue Kolleginnen und erfahrene Kräfte bearbeiten Kontakte nicht gleich schnell, und die Bearbeitungszeit verschiebt sich mit der Themenmischung.

Nichts davon macht Erlang C nutzlos. Es macht es zu einer guten ersten Schätzung, die einen Puffer und eine Rückkopplungsschleife braucht. Viele Teams schlagen einen Sicherheitsaufschlag auf die Erlang-Zahl, und die beste Prognosearbeit konzentriert sich darauf, die Unsicherheit zu verkleinern, die dieser Aufschlag abdecken muss.

Die Prognosegenauigkeit messen

Bevor Sie Prognosemethoden vergleichen, einigen Sie sich auf den Maßstab. Hyndman und Athanasopoulos definieren die Standardmaße in Forecasting: Principles and Practice (FPP3):

Prognosefehler und Verzerrung im Support messen: Ein Messschieber prüft verschobene Intervalle.

Maß Was es ist Gut für Worauf zu achten ist
MAE Mittelwert der absoluten Fehler, in Kontakten Leicht zu erklären für Ops-Verantwortliche Skalenabhängig, daher lässt sich eine kleine nicht mit einer großen Warteschlange vergleichen
RMSE Wurzel des mittleren quadratischen Fehlers Große Abweichungen stärker gewichten Ebenfalls skalenabhängig; schwerer zu interpretieren
MAPE Mittlerer absoluter prozentualer Fehler Vergleich von Warteschlangen unterschiedlicher Größe Nicht definiert, wenn das tatsächliche Volumen null ist, und extrem nahe null, etwa in nächtlichen Halbstunden; bestraft negative Fehler stärker als positive
MASE Fehler im Verhältnis zu einem naiven Benchmark Jede Methode in einer Zahl mit der Baseline vergleichen Für Nicht-Analysten weniger vertraut

Zwei praktische Folgen. Erstens verhält sich MAPE genau bei den Intervallen schlecht, von denen Support-Teams reichlich haben: ruhige nächtliche Zeitfenster mit wenigen Kontakten. Berichten Sie MAPE für Tages- oder Stundensummen und nutzen Sie MAE oder MASE auf Halbstundenebene. Zweitens definiert FPP3 MASE so, dass ein Wert unter 1 bedeutet, dass Sie den Benchmark auf den Trainingsdaten schlagen, und bei saisonalen Reihen ist dieser Benchmark die Methode Seasonal Naive (FPP3). Das ist die Zahl, die Sie Ihrem WFM-Verantwortlichen vorlegen sollten: „Sind wir besser als das wiederholte Muster der letzten Woche?“

Messen Sie außerdem die Verzerrung, nicht nur den Fehler. Eine Prognose, die an einem Tag 8% zu hoch und am nächsten 8% zu niedrig liegt, hat denselben MAE wie eine, die immer 8% zu hoch liegt, aber die zweite ist ein systematisches Problem der Überbesetzung. Verfolgen Sie auch den vorzeichenbehafteten Fehler.

Wann Machine Learning eine einfache Baseline schlägt

Beginnen Sie mit der Baseline. Die Methode Seasonal Naive aus FPP3 setzt jede Prognose auf den zuletzt beobachteten Wert derselben Saison (dieser Dienstag um 10:00 Uhr sieht aus wie der letzte Dienstag um 10:00 Uhr), und die Position des Buchs ist, dass solche Methoden als Benchmarks dienen und eine neue Methode, die sie nicht schlägt, nicht in Betracht kommt (FPP3). Für eine stabile Warteschlange mit starkem Wochenrhythmus ist ein Seasonal Naive oder ein klassisches statistisches Modell oft schwer zu schlagen. Eine große Studie zu statistischen und Machine-Learning-Methoden stellte fest, dass die ML-Methoden bei der Genauigkeit über alle Horizonte übertroffen wurden und dabei weit mehr Rechenleistung brauchten (Makridakis et al., PLOS ONE). Behalten Sie dieses Ergebnis im Kopf, wenn Anbieter mit „AI-gestützter Prognose“ werben.

Saisonale Baseline im Vergleich zu ML: Was unterscheidet sie? Ein Rad mit wiederkehrendem Muster und ein ereignisbewusster Planer.

Wo also zahlt sich ML aus? Dort, wo die Historie allein nicht reicht und äußere Signale die Schwankungen erklären:

  • Bekannte Treiber. Produkt-Releases, Abrechnungsläufe, Marketing-Versendungen, Ausfälle und Preisänderungen erzeugen Volumen, das das Muster der letzten Woche nicht vorhersagen kann. ML-Modelle können diese als Eingaben aufnehmen (ein Kalender geplanter Ereignisse, ein Störungskennzeichen, die Zahl der Kunden, die gerade eine Rechnung erhalten haben).
  • Viele Warteschlangen gleichzeitig. Wenn Sie nach Sprache, Tier und Kanal prognostizieren, kann ein Modell, das gemeinsame Muster über Reihen hinweg lernt, den dünnen helfen, bei denen jede Reihe wenig Historie hat.
  • Korrektur im Tagesverlauf. Ein Modell, das die ersten Stunden des Tages beobachtet und den Rest neu prognostiziert, kann eine Spitze früh erkennen. Das ist ein Muster der Anomalieerkennung: einen Live-Datenstrom aufnehmen, ihn mit einer Baseline vergleichen, den Ausreißer markieren und eine Planerin alarmieren.
  • Kontaktgründe. Wenn die Intent-Erkennung jeden Kontakt nach Grund taggt, können Sie „Rechnungsstreit“ und „Passwort zurücksetzen“ getrennt prognostizieren, was weit nützlicher ist als eine Gesamtzahl.

Ein solider Weg zur Entscheidung: Lassen Sie die Baseline und das ML-Modell nebeneinander auf mindestens einigen Wochen zurückgehaltener Daten laufen, vergleichen Sie nach MASE und setzen Sie ML nur dort ein, wo es durchgängig gewinnt, nicht im Durchschnitt. Ein Modell, das in gewöhnlichen Wochen gewinnt und in den entscheidenden Wochen (Launches, Ausfälle) verliert, hilft nicht.

Wie die AI-Deflection Volumen und Zusammensetzung verändert

Sobald ein AI Agent einen Teil Ihres eingehenden Verkehrs löst, beschreibt Ihre Historie nicht mehr Ihre Zukunft. Zwei Dinge ändern sich.

AI-Deflection verändert die Support-Arbeitslast: Kleine Fälle werden herausgefiltert, anspruchsvolle bleiben übrig.

Das Volumen sinkt, aber nicht eins zu eins. Wenn die AI einen Teil der Konversationen übernimmt, sieht die menschliche Warteschlange weniger Kontakte. Das hängt aber davon ab, wie Sie die Lösung zählen. Aufgefangen ist nicht dasselbe wie gelöst, und Kunden, denen nicht geholfen wurde, kommen über einen anderen Kanal zurück, oft als wiederholter Kontakt.

Die Mischung wird schwieriger. Die einfachen Kontakte verschwinden zuerst: Passwort zurücksetzen, Bestellstatus, einfache Anleitungsfragen. Was bleibt, ist länger, komplexer und emotionaler, daher steigt die durchschnittliche Bearbeitungszeit. Nehmen Sie das durchgerechnete Beispiel noch einmal und nehmen Sie an, die AI entfernt 30% des Volumens (aus 120 Kontakten werden 84), während die verbleibenden Kontakte 30% länger dauern (390 statt 300 Sekunden). Die Arbeitslast beträgt 84 x 390 / 1.800 = 18,2 Erlang, und das Ziel 80/20 braucht 23 Mitarbeitende. Das sind zwei weniger als 25, eine Reduktion der Mitarbeitenden um 8% bei einer Reduktion der Kontakte um 30%. Mit 30% Shrinkage sind das etwa 33 eingeplante statt 36.

Die Erkenntnis: Prognostizieren Sie Volumen und Bearbeitungszeit getrennt, nach Kontaktgrund. Trainieren Sie nach jedem Launch oder jeder Änderung des AI Agent neu oder setzen Sie die Baseline neu, denn die Historie vor dem Launch ist jetzt ein anderes System. Und wenn Mitarbeitende Tools wie AI Agent Assist erhalten, die die Bearbeitungszeit bei den verbleibenden Kontakten verkürzen, zeigt sich das in der AHT, nicht im Volumen. Verfolgen Sie sie daher als eigene Eingabe.

So bauen Sie das auf, Schritt für Schritt

  1. Saubere Historie ziehen. Mindestens ein Jahr Kontaktzahlen nach Intervall, Kanal und Kontaktgrund sowie die Bearbeitungszeiten. Markieren Sie Ausfälle, Launches und Feiertage, damit das Modell daraus lernen kann. Support-Daten für AI vorbereiten behandelt die Bereinigungsarbeit.
  2. Die Prognosegranularität festlegen. Tagessummen für die monatliche Einstellungsplanung, stündlich oder halbstündlich für die Schichtplanung. Nutzen Sie nicht ein Modell für beides.
  3. Eine Baseline setzen. Seasonal Naive je Warteschlange. Halten Sie ihren MAE und MASE fest. Das ist die Zahl, die es zu schlagen gilt.
  4. Treiber ergänzen. Führen Sie geplante Ereignisse, Abrechnungskalender und Störungskennzeichen ein. Probieren Sie ein statistisches Modell mit externen Regressoren, bevor Sie ein schwereres ML-Modell nehmen.
  5. Backtest durchführen. Vergleichen Sie Methoden auf zurückgehaltenen Wochen, darunter mindestens einer Launch- oder Ausfallwoche. Wählen Sie pro Warteschlange, nicht global.
  6. In Personalbedarf umrechnen. Rechnen Sie Erlang C (oder ein Simulationstool, wenn Sie Abbruch und die Bearbeitung mehrerer Kontakte brauchen) pro Intervall und teilen Sie dann durch (1 - Shrinkage), um die einzuplanende Personalstärke zu erhalten.
  7. Einen Puffer und eine Schleife im Tagesverlauf ergänzen. Planen Sie in Spitzen etwas über der Erlang-Zahl und geben Sie den Planern einen Alarm, wenn das tatsächliche Volumen deutlich über der Prognose liegt, damit sie Personal verschieben, Überstunden anbieten oder Arbeit auf asynchrone Kanäle verlagern können.
  8. Monatlich prüfen. Verfolgen Sie MASE, Verzerrung und die Trefferquote beim Service Level je Warteschlange. Setzen Sie die Baseline neu, sobald sich der Umfang des AI Agent ändert.

Fallstricke, die Sie vermeiden sollten

MAPE allein verwenden. Es verbirgt die Verzerrung und versagt bei Intervallen mit geringem Volumen. Kombinieren Sie es mit MAE, MASE und dem vorzeichenbehafteten Fehler.

Nur die Gesamtzahl der Kontakte prognostizieren. Eine flache Gesamtzahl verbirgt die Verschiebung der Zusammensetzung. Prognostizieren Sie nach Kontaktgrund und Kanal.

Der Erlang-Zahl als exakt vertrauen. Sie ist eine Schätzung auf Basis von Annahmen, die echte Warteschlangen verletzen. Halten Sie einen Puffer vor und beobachten Sie die Abbrüche.

Auf den Tagesdurchschnitt planen. Das Service Level wird in den Spitzenintervallen gewonnen oder verloren. Planen Sie Intervall für Intervall.

Die Verschiebung der Shrinkage ignorieren. Schulungswochen, Grippesaison und die Einarbeitung neuer Kräfte verändern die Shrinkage. Ein fester Wert von 30% im Modell ist eine Vermutung.

Die Baseline überspringen. Wenn Sie nicht zeigen können, dass die AI-Prognose Seasonal Naive schlägt, zahlen Sie für Komplexität. Nutzen Sie die Entscheidung automatisieren oder unterstützen, um den Geltungsbereich der AI-Deflection abzustecken, bevor Sie Personalpläne darauf kürzen.

Häufig gestellte Fragen zu AI-Prognosen für das Support-Volumen

Was ist Erlang C im Kundensupport?

Erlang C ist eine Warteschlangenformel, die schätzt, wie viele Mitarbeitende Sie in einem Intervall brauchen, um ein Service Level zu erreichen, gegeben das Kontaktvolumen und die durchschnittliche Bearbeitungszeit. Sie nimmt Poisson-Ankünfte und exponentielle Bedienzeiten an und ignoriert Abbruch und Wiederholungsversuche. Betrachten Sie ihr Ergebnis daher als Ausgangspunkt mit einem Puffer.

Wie genau muss eine Prognose des Support-Volumens sein?

Es gibt keine allgemeingültige Zahl, denn das hängt davon ab, wie nah an der Kapazität Sie arbeiten. Je näher Ihre Auslastung an 100% liegt, desto stärker schmerzt eine kleine Abweichung: In einem vielzitierten Überblick landet ein Center, das für 95% Auslastung geplant ist und 5% mehr Volumen bekommt, bei 99,75% Auslastung. Messen Sie Ihren eigenen Fehler und Ihre Verzerrung je Warteschlange und setzen Sie Ziele von dort aus.

Was ist Shrinkage und warum ist sie für die Personalplanung wichtig?

Shrinkage ist der Anteil der bezahlten Zeit, in der Mitarbeitende nicht für die Bearbeitung von Kontakten verfügbar sind, wegen Pausen, Schulungen, Meetings und Abwesenheit. NICE beziffert die typische Shrinkage im Contact Center auf 25% bis 40%. Sie teilen die produktiven Mitarbeitenden, die Erlang C liefert, durch (1 minus Shrinkage), um die Personalstärke zu erhalten, die Sie tatsächlich einplanen müssen.

Ist Machine Learning besser als einfache Methoden für die Prognose des Support-Volumens?

Nicht automatisch. Die Prognoseliteratur sagt, dass neue Methoden mit einfachen Benchmarks wie Seasonal Naive verglichen werden sollten, und eine große Vergleichsstudie stellte fest, dass Machine-Learning-Methoden bei der Genauigkeit übertroffen wurden und viel mehr Rechenleistung brauchten. ML hilft tendenziell, wenn äußere Treiber (Launches, Abrechnungsläufe, Störungen) die Schwankungen erklären. Testen Sie es daher Warteschlange für Warteschlange gegen die Baseline.

Welches Genauigkeitsmaß für Prognosen sollte ich verwenden?

Verwenden Sie mehr als eines. MAE ist leicht zu erklären, MASE sagt Ihnen, ob Sie einen naiven Benchmark schlagen (unter 1 heißt ja), und MAPE eignet sich, um Warteschlangen unterschiedlicher Größe zu vergleichen, versagt aber bei Intervallen nahe null. Verfolgen Sie auch den vorzeichenbehafteten Fehler, damit Sie sehen, ob Sie durchgängig zu hoch oder zu niedrig liegen.

Wie verändert die AI-Deflection die Personalprognose?

Sie senkt das Kontaktvolumen, erhöht aber meist die Bearbeitungszeit bei den verbleibenden Kontakten, weil die einfachen verschwunden sind. Prognostizieren Sie Volumen und Bearbeitungszeit getrennt nach Kontaktgrund und setzen Sie die Baseline nach jeder Änderung am Umfang des AI Agent neu.

About the author

Linh Ngo

Linh Ngo

Customer Success Operations Manager

Linh Ngo is Customer Success Operations Manager at Rework, focused on AI-led process automation for operations teams, especially order fulfillment and finance workflows. Linh writes about process management and the AI productivity tools that take manual steps out of daily operations, so teams can see where work stalls and fix the process before adding headcount.