Zurück zum Blog
Support operations

So schreiben Sie Warteschlangen- und Übergabenachrichten im Kundensupport, die klare Erwartungen setzen

Nachrichten zu Wartezeiten, Warteschlangen und Übergaben sind operative Zusagen, kein Lückenfüller. Erfahren Sie, wie Sie Servicezustände definieren, glaubwürdige Zeitangaben machen und einen klaren Weg zu menschlicher Hilfe erhalten.

Support-Unterhaltung mit klaren Statusmeldungen zu Warteschlange, Übergabe und Eskalation an Menschen

Warum Schweigen Kunden zusätzlichen Aufwand verursacht

Ein Kunde, der eine Nachricht gesendet hat, aber nicht erkennen kann, ob sie eingegangen ist, sich in einer Warteschlange befindet oder weitergeleitet wurde, muss den nächsten Schritt erraten. Häufige Reaktionen sind, dieselbe Nachricht erneut zu senden, einen anderen Kanal zu versuchen, nach einem Update zu fragen oder die Unterhaltung abzubrechen. Diese Maßnahmen erhöhen das Anfragevolumen und erschweren zugleich die Bearbeitung des ursprünglichen Problems.

Eine höfliche Empfangsbestätigung reicht nicht aus, wenn sie das tatsächliche Betriebsmodell nicht widerspiegelt. Statusmeldungen sollten Kunden mitteilen, was jetzt bekannt ist, was als Nächstes geschieht und was sie tun können, wenn der Weg ungeeignet ist. Behandeln Sie sie als Teil des Beschwerdemanagements und der Servicegestaltung und überprüfen Sie sie, wenn sich der Betrieb ändert.

  • Verwenden Sie keine Wartenachricht, um eine Warteschlange, eine Übergabe oder eine Störung zu verbergen.
  • Erwecken Sie nicht den Eindruck, dass ein Mitarbeiter aktiv an einem Fall arbeitet, sofern dieser nicht tatsächlich zugewiesen wurde.
  • Bezeichnen Sie ein Problem nicht als gelöst, nur weil die Auswirkungen verringert wurden; Eindämmung und dauerhafte Behebung sind unterschiedliche Zustände.
  • Verwenden Sie in Automatisierungen, durch Mitarbeiter, in Hilfeinhalten und in Eskalationsverfahren dieselbe operative Terminologie.
Warum Schweigen Kunden zusätzlichen Aufwand verursacht

Ordnen Sie zuerst die für Kunden sichtbaren Servicezustände zu

Formulieren Sie Nachrichten erst, nachdem Sie die Zustände vereinbart haben, die Kunden tatsächlich erleben können. Die interne Weiterleitung kann komplex sein, doch kundenorientierte Zustände sollten wenige, klar unterscheidbare und handlungsorientierte Schritte umfassen. Jeder Zustand benötigt eine eindeutige Eintrittsbedingung, Zuständigkeit, Austrittsbedingung und Nachrichtenregel.

Vermeiden Sie es, interne Bezeichnungen wie Teamcodes oder Ticketstatus ohne Erklärung anzuzeigen. Ein interner Status „ausstehend“ kann beispielsweise bedeuten, dass das Team Informationen vom Kunden benötigt; ein Status „zurückgestellt“ kann bedeuten, dass es Input von einem anderen Team braucht. Kunden benötigen die praktische Bedeutung, nicht die Backoffice-Bezeichnung.

  • Eingegangen: Die Nachricht ist angekommen. Teilen Sie mit, ob eine Antwort zu erwarten ist und was als Nächstes passiert.
  • In Warteschlange: Die Anfrage wartet auf einen geeigneten Bearbeiter. Benennen Sie gegebenenfalls die Warteschlange oder den Service, ohne eine Antwortzeit zu erfinden.
  • Zugewiesen: Eine benannte Person oder ein Team ist für die nächste Antwort zuständig. Verwenden Sie dies nur, wenn die Zuweisung tatsächlich erfolgt ist.
  • Übergeben: Ein anderes Team oder ein Spezialist ist nun für die nächste Aktion zuständig.
  • Warten auf Kunden: Erklären Sie genau, welche Information oder Handlung benötigt wird und warum.
  • Verzögert: Erläutern Sie die bekannten Auswirkungen, den Zeitpunkt oder Auslöser für das nächste Update sowie gegebenenfalls einen sicheren Workaround.
  • Geschlossen: Bestätigen Sie das Ergebnis oder den Grund für den Abschluss und erklären Sie, wie der Fall wieder geöffnet oder weitere Hilfe angefordert werden kann, sofern dieser Weg besteht.
Ordnen Sie zuerst die für Kunden sichtbaren Servicezustände zu

Verwenden Sie eine fünfteilige Struktur für Statusmeldungen

Nützliche Kundensupport-Nachrichten zu Wartezeiten und Übergaben beantworten die Fragen, die Kunden sonst stellen würden: Was ist passiert? Wer ist für die nächste Aktion zuständig? Was geschieht als Nächstes? Wann sollte ich, falls bekannt, mit einem weiteren Update rechnen? Was kann ich jetzt tun? Formulieren Sie klar und situationsspezifisch.

Der Zeitbezug ist bedingt. Wenn Sie keine verlässliche Schätzung der Antwortzeit geben können, teilen Sie stattdessen mit, wann Sie den Kunden aktualisieren, oder beschreiben Sie das Ereignis, das die nächste Nachricht auslöst. Das ehrliche Fehlen einer voraussichtlichen Zeitangabe ist nützlicher als eine präzise wirkende Schätzung, die Teams nicht einhalten können.

  • Aktueller Status: „Ihre Nachricht ist eingegangen und wartet auf das Abrechnungsteam.“
  • Nächste Aktion: „Ein Spezialist für Abrechnung wird die von Ihnen übermittelten Kontodaten prüfen.“
  • Zuständigkeit: „Das Abrechnungsteam ist nun für die nächste Antwort zuständig.“
  • Zeitangabe: Nennen Sie eine voraussichtliche Zeit oder ein Zeitfenster nur, wenn dies auf aktuellen Servicedaten und dem geltenden Zeitplan beruht.
  • Alternativer Weg: Bieten Sie bei Bedarf einen passenden Self-Service-Schritt, eine andere Kontaktmöglichkeit oder einen Eskalationsweg an.

Wählen Sie bewusst eine Zeitangabe, ein Zeitfenster oder keine Schätzung

Eine voraussichtliche Zeitangabe ist eine Zusage, keine Höflichkeitsfloskel. Verwenden Sie sie nur, wenn historische Nachfrage, Daten zur Bearbeitungszeit und der Zeitplan des Kanals sie stützen und wenn das Team versäumte Zusagen überwachen kann. Ein Zeitfenster ist oft sicherer, wenn die Arbeit von einer Triage, einem Spezialisten oder einer externen Abhängigkeit abhängt.

Verzichten Sie auf eine Antwortzeitschätzung, wenn die Dauer wirklich unbekannt ist, die Warteschlange stark schwankt oder ein Vorfall noch bewertet wird. Ersetzen Sie sie durch eine glaubwürdige Update-Zusage, etwa einen angegebenen Prüfzeitpunkt, oder durch ein ereignisbasiertes Versprechen wie: „Wir aktualisieren diese Unterhaltung, sobald wir den Umfang bestätigt haben.“ Versprechen Sie keinen Lösungszeitpunkt, wenn Sie lediglich eine weitere Mitteilung zusagen können.

  • Verwenden Sie eine konkrete Zeitangabe, wenn Kapazität und der relevante Zeitplan der Geschäftszeiten sie verlässlich machen.
  • Verwenden Sie ein Zeitfenster, wenn Schwankungen zu erwarten sind: „Wir erwarten, innerhalb des nächsten Geschäftstags zu antworten.“
  • Verwenden Sie einen Update-Zeitpunkt, wenn die Dauer unbekannt ist: „Wir veröffentlichen hier bis 16:00 Uhr Ortszeit ein Update, auch wenn die Untersuchung noch läuft.“
  • Verwenden Sie ein ereignisbasiertes Update, wenn eine Uhrzeit nicht glaubwürdig ist: „Wir aktualisieren Sie, wenn die Prüfung durch den Spezialisten abgeschlossen ist.“
  • Sagen Sie niemals „in Kürze“, „so schnell wie möglich“ oder „ein Mitarbeiter wird gleich bei Ihnen sein“, es sei denn, Ihre Betriebspraxis gibt diesen Formulierungen eine definierte und überwachte Bedeutung.

Formulieren Sie Warteschlangennachrichten ohne Antwort zu garantieren

Eine Warteschlangennachricht sollte den Eingang bestätigen und den nächsten Bearbeitungsschritt beschreiben, ohne die Verfügbarkeit zu übertreiben. „Ein Mitarbeiter wird sich bald um Sie kümmern“ kann als Garantie verstanden werden, insbesondere außerhalb der Betriebszeiten oder bei hohem Anfrageaufkommen. Die Aussage wird auch irreführend, wenn die Unterhaltung später an eine andere Stelle weitergeleitet wird.

Benennen Sie die Servicebedingung eindeutig. Wenn das Team nicht besetzt ist, sagen Sie es. Wenn sich die Unterhaltung in einer Warteschlange befindet, sagen Sie das. Wenn eine Antwort nur für bestimmte Anfragearten verfügbar ist, stellen Sie die Empfangsbestätigung nicht als allgemeine Support-Abdeckung dar.

  • Sichereres Muster: „Wir haben Ihre Nachricht erhalten. Unser Support-Team prüft neue Nachrichten während der [veröffentlichten Zeiten]. Wir antworten Ihnen hier, sobald Ihre Anfrage einen verfügbaren Mitarbeiter erreicht.“
  • Muster bei hohem Anfrageaufkommen: „Wir haben Ihre Anfrage erhalten. Antworten dauern heute länger als üblich. Bitte senden Sie dieselben Angaben nicht erneut; sie sind dieser Unterhaltung beigefügt.“
  • Muster außerhalb der Betriebszeiten: „Unser Live-Support-Team ist derzeit nicht erreichbar. Ihre Nachricht ist zur Prüfung erfasst, sobald der nächste planmäßige Betreuungszeitraum beginnt.“
  • Fehlermodus: Eine allgemeine Empfangsbestätigung wird angezeigt, obwohl die Weiterleitung fehlgeschlagen ist. Ergänzen Sie ein Überwachungs- und Fallback-Verfahren, damit diese Nachricht nicht mit einer erfolgreichen Fallerstellung verwechselt wird.

Sorgen Sie dafür, dass Übergaben Kontext und Zuständigkeit erhalten

Eine Übergabenachricht sollte verhindern, dass Kunden sich fragen, ob sie weitergereicht wurden oder von vorn beginnen müssen. Erklären Sie in kundengerechter Sprache, warum die Übergabe erfolgt, benennen Sie die neue Zuständigkeit so konkret wie für Kunden hilfreich und bestätigen Sie, welche Informationen mit der Unterhaltung übertragen werden.

Bitten Sie Kunden nicht, Angaben zu wiederholen, die bereits in der Unterhaltung vorliegen. Ein neues Team benötigt möglicherweise eine Klarstellung, sollte aber zunächst den Verlauf prüfen und eine gezielte Frage stellen. Wenn die Übergabe noch nicht abgeschlossen ist, sagen Sie nicht, dass ein anderes Team den Fall bereits übernommen hat.

  • Vorlage für Übergaben: „Ich übergebe diese Unterhaltung an unser [Team], da es für [Thema] zuständig ist. Das Team kann die Angaben sehen, die Sie bereits geteilt haben. Die nächste Antwort erscheint in dieser Unterhaltung.“
  • Vorlage für Spezialistenprüfung nach erfolgreicher Übergabe: „Ihre Anfrage benötigt eine Prüfung durch einen Spezialisten. Wir haben die Unterhaltung mit den bereits bereitgestellten, für die Prüfung erforderlichen Informationen an das [Team] übergeben. Wir aktualisieren Sie hier, sobald die Prüfung abgeschlossen ist.“
  • Vorlage für Klärung: „Das [Team] hat die Unterhaltung geprüft und benötigt eine Angabe, um fortzufahren: [konkrete Frage].“
  • Fehlermodus: Eine Übergabe wird angekündigt, aber kein Ziel nimmt sie an. Definieren Sie eine Zuständigkeit und einen Alarmweg für nicht rechtzeitig angenommene Übergaben.

Trennen Sie Automatisierung von einer Antwort durch eine benannte Person

Kunden sollten zwischen einer automatisierten Empfangsbestätigung und einer von einem Mitarbeiter verfassten Nachricht unterscheiden können. Das schützt Vertrauen und hilft ihnen einzuschätzen, ob eine sofortige Antwort sinnvoll ist. Automatisierung kann den Eingang bestätigen, validierte Informationen erfassen, einen bekannten nächsten Schritt bereitstellen, einen Ablauf verzweigen und an Menschen übergeben; sie sollte nicht vorgeben, eine Person zu sein.

Wenn ein Mensch hinzukommt, machen Sie diesen Übergang deutlich. Ein benannter Mitarbeiter kann bestätigen, dass er die vorherigen Nachrichten geprüft hat, und die nächste Aktion nennen. Wenn ein automatisierter Ablauf Informationen erfasst, erklären Sie, warum jede angeforderte Angabe benötigt wird, und vermeiden Sie die Erhebung von Daten, die für die Anfrage nicht notwendig sind.

  • Automatisierte Empfangsbestätigung: „Automatisierte Nachricht: Wir haben Ihre Anfrage erhalten und prüfen den richtigen Weg dafür.“
  • Nachricht beim Hinzukommen eines Mitarbeiters: „Hallo, ich bin Sam vom Support. Ich habe die von Ihnen geteilten Angaben geprüft. Ich werde jetzt [konkrete nächste Aktion] prüfen.“
  • Verwenden Sie in Automatisierungen keinen menschlichen Namen, keine Tippanzeige und keine Ich-Form, wenn dies vernünftigerweise den Eindruck erwecken könnte, dass eine Person die Unterhaltung gelesen hat.
  • Bieten Sie eine Möglichkeit, einen Ablauf zu stoppen oder zu umgehen, wenn der Kunde Unterstützung benötigt, die der Ablauf nicht sicher leisten kann.

Planen Sie für Zeiten außerhalb der Abdeckung, unerwartete Verzögerungen und Vorfälle

Zeitpläne, Feiertage und Weiterleitungsregeln müssen mit der Sprache übereinstimmen, die Kunden sehen. Prüfen Sie jeden Kanal, jede Abteilung und jeden Betreuungszeitraum. Eine Nachricht, die eine Antwort an Werktagen verspricht, ist unzutreffend, wenn ein lokaler Feiertag oder ein anderer Zeitplan für das zugewiesene Team gilt.

Kommunizieren Sie bei einem Vorfall die bekannten Auswirkungen, den aktuellen Fortschritt bei der Eindämmung, gegebenenfalls einen sicheren Workaround und den Zeitpunkt der nächsten Mitteilung. Eine frühe Benachrichtigung kann kurz sein, wenn eine schnelle Information wichtig ist; aktualisieren Sie sie, sobald Fakten bestätigt sind. Sagen Sie erst dann, dass der Service wiederhergestellt ist, wenn Sie Belege dafür haben, dass die Auswirkungen beendet sind, und nicht bereits dann, wenn ein Workaround sie lediglich verringert.

  • Außerhalb der Betriebszeiten: Geben Sie an, dass keine Live-Betreuung verfügbar ist, und nennen Sie den nächsten Betreuungszeitraum nur, wenn er für diesen Service zutrifft.
  • Unerwartete Verzögerung: Erklären Sie die Verzögerung, ohne dem Kunden die Schuld zu geben oder vagen technischen Jargon zu verwenden; nennen Sie einen Update-Zeitpunkt oder alternativen Weg.
  • Serviceunterbrechung: Nennen Sie die betroffene Funktion, die bekannten Auswirkungen für Kunden, einen Workaround, falls verfügbar, und die Zusage für das nächste Update.
  • Eskalieren Sie intern, wenn eine operative Nachricht nicht mehr der Realität entspricht, etwa bei einem versäumten Update-Zeitpunkt, einer fehlgeschlagenen Weiterleitungsregel oder einer anhaltenden Warteschlange.

Häufig gestellte Fragen

Wie lang sollte eine Kunden-Wartenachricht sein?

In der Regel ein bis drei kurze Sätze. Nennen Sie den aktuellen Status, die nächste Aktion und nur eine Zeitangabe, die der Service tatsächlich erfüllen kann. Fügen Sie einen alternativen Weg hinzu, wenn der Kunde dringende oder andersartige Hilfe benötigen könnte.

Sollte jede Warteschlangennachricht eine Zeitangabe enthalten?

Nein. Verwenden Sie eine Zeitangabe nur, wenn sie für den jeweiligen Kanal, das Team und den Zeitplan glaubwürdig ist. Wenn die Dauer unbekannt ist, nennen Sie stattdessen einen konkreten Zeitpunkt für das nächste Update oder das Ereignis, das ein Update auslöst.

Was sollte eine Übergabenachricht enthalten?

Erklären Sie, warum die Übergabe erforderlich ist, wer für die nächste Aktion zuständig ist, bestätigen Sie, dass der Gesprächsverlauf mit dem Fall übertragen wird, und teilen Sie mit, wo die nächste Antwort erscheint. Bitten Sie den Kunden nicht, bereits bereitgestellte Informationen zu wiederholen.

Wann sollte einem Kunden eine Eskalation zu einem Menschen angeboten werden?

Bieten Sie einen menschlichen Weg an oder erhalten Sie ihn, wenn die Automatisierung die Anfrage nicht sicher bearbeiten kann, wenn der Kunde blockiert ist, wenn ein Fehler oder eine Verzögerung wesentliche Folgen hat, wenn wiederholte Kontakte zeigen, dass das Problem ungelöst bleibt, oder wenn eine Richtlinie eine Spezialistenprüfung verlangt. Machen Sie den Weg und den erwarteten nächsten Schritt klar.

Wie können Teams testen, ob diese Nachrichten funktionieren?

Vergleichen Sie die Formulierung vor der Einführung mit tatsächlichen Weiterleitungen, Zeitplänen und Servicelevels. Prüfen Sie nach der Einführung wiederholte Kontakte, Abbrüche, Übergaben, Zeiten bis zur ersten Antwort und Zuweisung, Bewertungen und Feedback zu Unterhaltungen. Überprüfen Sie Stichproben verfehlter Schätzungen, nicht angenommener Übergaben und Eskalationen und überarbeiten Sie dann die Nachricht oder den Betrieb, der die Abweichung verursacht.

Welche Prüfungen zur Barrierefreiheit gelten für Statusmeldungen im Web?

Verwenden Sie einfache Sprache, stellen Sie sicher, dass Nachrichten beim Vorlesen durch assistive Technologien genügend Kontext haben, und testen Sie dynamische Updates ohne unerwünschte Fokusbewegungen. In Weboberflächen kann role=status Statusupdates assistiven Technologien zurückhaltend mitteilen. Halten Sie wiederkehrende Mechanismen für menschlichen Kontakt, Selbsthilfe und automatisierten Kontakt in einer konsistenten relativen Reihenfolge, wenn sie auf verschiedenen Seiten erscheinen, und lassen Sie die Sprache der Seite und abweichender Textpassagen programmatisch bestimmen, wie es WCAG 2.2 verlangt.

Quellen und weiterführende Literatur

Primäre und maßgebliche Referenzen zur Prüfung der faktischen Grundlage dieses Leitfadens.

  1. ISO 10002:2018 — Quality management: Customer satisfaction: Guidelines for complaints handling in organizations — International Organization for Standardization
  2. Lifecycle of an incident — Google Cloud Documentation
  3. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative
  4. ARIA22: Using role=status to present status messages — W3C Web Accessibility Initiative
  5. Set up and manage user support — GOV.UK Service Manual
  6. Error message — GOV.UK Design System
  7. About open vs. pending and on-hold tickets — Zendesk Help
  8. Setting your schedule with business hours and holidays — Zendesk Help
  9. Analyzing your messaging tickets — Zendesk Help