So gestalten Sie einen WebChat-Fallback, wenn der Chat nicht verfügbar oder schwer nutzbar ist

Ein Fallback ist Teil des Services, nicht nur ein Kontaktlink für den Notfall

Ein WebChat-Fallback ist der praktische Weg, den Kundinnen und Kunden nutzen können, wenn eingebetteter Chat nicht verfügbar, nicht barrierefrei, für die Aufgabe ungeeignet oder schlicht nicht ihre bevorzugte Form der Hilfe ist. Er sollte zu einem Service führen, der das Anliegen tatsächlich weiterbearbeiten kann, statt zu einer allgemeinen Seite, auf der die Customer Journey von vorn beginnt.

Das ist nicht nur bei Behinderungen relevant. Menschen haben möglicherweise keinen zuverlässigen Internetzugang, keine digitale Sicherheit, nicht die nötigen Fähigkeiten, kein Vertrauen oder keine Motivation, eine Aufgabe online abzuschließen. Ein Supportbetrieb sollte diese Umstände als normale Servicebedingungen einplanen, nicht als Ausnahmefälle.

Platzieren Sie den Fallback dort, wo der Bedarf entsteht: neben dem Launcher oder Chat-Einstiegspunkt, in Chat-Fehlerzuständen, an Schritten mit hoher Reibung und innerhalb der jeweiligen Transaktion. Verwenden Sie überall, wo der Hilfemechanismus wiederholt wird, dieselbe relative Platzierung und Formulierung, damit Kundinnen und Kunden ihn zuverlässig finden können.

• Behandeln Sie die Route als unterstützten Service mit Ziel, Verantwortlichkeit, Zeiten und Abschlussprozess.
• Machen Sie sie verfügbar, bevor Kundinnen und Kunden einen Chat-Ablauf abgeschlossen oder unnötige Informationen preisgegeben haben.
• Nennen Sie verfügbare Alternativen klar, etwa Telefon, barrierefreies Webformular, Rückrufanfrage oder einen servicespezifischen persönlichen Weg.
• Machen Sie Chat nicht zum einzigen Weg, ein Problem mit dem Chat selbst zu melden.

Ermitteln Sie, wo Chat ausfallen oder schwer nutzbar werden kann

Beginnen Sie mit einer End-to-End-Fehlerkarte. Ein Widget kann nicht laden; es kann laden, aber per Tastatur schwer bedienbar sein; Kundinnen und Kunden können durch Authentifizierung, Datei-Upload, Validierung oder eine automatisierte Antwort blockiert werden; oder das Gespräch erreicht eine Warteschlange, in der keine passend qualifizierte Person verfügbar ist. Jeder Punkt benötigt einen festgelegten nächsten Schritt.

Trennen Sie Fehler, für die Ihr Website-Team gestalten kann, von Bedingungen, die es nicht vollständig kontrollieren kann. Ihr Team steuert Sichtbarkeit und Barrierefreiheit der alternativen Route, Formulierung, Formulardesign, erhobene Daten, Routing-Regeln und Personalrichtlinien. Browserunterstützung, Netzwerkbedingungen und die Verfügbarkeit von Drittkanälen können die Erfahrung beeinflussen, entbinden aber nicht von der Pflicht, eine nutzbare Alternative bereitzustellen.

Berücksichtigen Sie die Wahl der Kundinnen und Kunden in der Karte. Eine Person, die lieber anrufen möchte, einen Dolmetscher benötigt oder im Chat nicht sicher fortfahren kann, ist keine fehlgeschlagene Conversion. Sie fordert einen passenden Serviceweg an.

• Das Widget erscheint nicht, weil Skripte blockiert sind, die Verbindung langsam ist oder der Browser nicht unterstützt wird.
• Launcher, Bedienelemente, Fokusbewegung oder Nachrichteneingabe können mit Tastatur oder assistiver Technologie nicht wirksam genutzt werden.
• Anmeldung, Identitätsprüfungen oder Einmalcode-Verfahren verhindern den Fortschritt.
• Datei-Upload, Eingabevalidierung oder Rückmeldung zur Übermittlung sind unklar oder schlagen wiederholt fehl.
• Die Automatisierung versteht die Anfrage nicht, kann eine Antwort nicht validieren oder erreicht einen Fall außerhalb ihres Zuständigkeitsbereichs.
• Während des von Kundinnen und Kunden benötigten Zeitraums ist keine geschulte Person verfügbar.
• Das Anliegen erfordert einen Kanal mit Fähigkeiten, die Chat nicht sicher bereitstellen kann, etwa einen servicespezifischen Termin oder persönliche Unterstützung.

Legen Sie einen Mindeststandard für jede Fallback-Route fest

Nutzen Sie vier Prüfungen: sichtbar, verständlich, bedienbar und verfügbar. Kundinnen und Kunden sollten die Route sehen können, ohne einen Chat abzuschließen, verstehen, was als Nächstes geschieht, sie ohne Zeigegerät oder unnötige Hürden bedienen können und einen Service erreichen, der tatsächlich besetzt ist oder ein klares Ergebnis außerhalb der Öffnungszeiten bietet.

Fordern Sie in einem barrierefreien Fallback-Formular nur an, was zur Bearbeitung der Supporttransaktion erforderlich ist. Geben Sie jedem Bedienelement eine sichtbare zugeordnete Beschriftung, stellen Sie bei Bedarf Anweisungen bereit und verlassen Sie sich nicht auf Platzhaltertext, um Pflichtangaben zu vermitteln. Tritt ein Fehler auf, benennen Sie das betroffene Feld, erklären Sie Problem und Korrektur und verlinken Sie gegebenenfalls zum Feld.

Testen Sie Formulare sowohl auf dem Server als auch im Browser. Clientseitige Prüfungen können umgangen werden, und die Browserunterstützung variiert. Geben Sie nach dem Absenden eine eindeutige Bestätigung, dass die Anfrage eingegangen ist, oder ein klares Fehlerergebnis und einen Weg zum Fortfahren, wenn die Übermittlung nicht abgeschlossen werden kann.

• Tastatur: Alle Routen-Bedienelemente, Felder und Absendeaktionen funktionieren ohne Maus, und der sichtbare Fokus bleibt erkennbar.
• Zoom und Umbruch: Bei einer Breite entsprechend 320 CSS-Pixeln gehen keine Informationen oder Funktionen verloren, und die gewöhnliche Nutzung erfordert kein Scrollen in zwei Dimensionen.
• Authentifizierung: Fordern Sie keinen Test kognitiver Fähigkeiten, sofern keine alternative Methode oder unterstützende Möglichkeit verfügbar ist.
• Rückmeldung: Meldungen zu Erfolg, Fehler und nächsten Schritten sind klar und barrierefrei verfügbar.
• Konsistenz: Wiederkehrende Hilferouten erscheinen auf relevanten Seiten an einer konsistenten relativen Stelle.

Wählen Sie eine Route, die zur Aufgabe und zur Kundin oder zum Kunden passt

Es gibt keine universell richtige Alternative. Wählen Sie Routen auf Grundlage von Nutzerforschung, Servicerisiko und Betriebskapazität. Telefon kann für dringende oder komplexe Anliegen am besten sein; eine Rückrufanfrage kann Wartezeit reduzieren; ein barrierefreies Formular eignet sich für nicht dringende Fälle, die eine schriftliche Dokumentation benötigen; und ein persönlicher oder servicespezifischer Weg kann nötig sein, wenn praktische Unterstützung erforderlich ist.

Veröffentlichen Sie eine Route nicht nur, weil sie an anderer Stelle in der Organisation existiert. Bestätigen Sie, dass sie die betreffende Art von Anliegen annimmt, ein empfangendes Team hat, Kundeninformationen schützt und ein Ergebnis kommunizieren kann. Ein Fallback, der in einem unbeobachteten Postfach landet, erzeugt einen zweiten Fehler.

Wenn Chat und Fallback Teil desselben Prozesses sind, vermeiden Sie, Kundinnen und Kunden nach Informationen zu fragen, die sie bereits angegeben haben. Vorbehaltlich angemessener Datenschutzkontrollen sollten erneut benötigte Informationen zur Auswahl verfügbar oder vorausgefüllt sein. Übertragen Sie sensible Informationen nicht automatisch, nur weil sie im Chat eingegeben wurden.

• Telefon: Nutzen Sie es für dringende, sensible oder hochkomplexe Anliegen; veröffentlichen Sie Anrufzeiten und gegebenenfalls Vorkehrungen zur Barrierefreiheit.
• Barrierefreies Webformular: Nutzen Sie es für strukturierte, nicht dringende Anfragen; geben Sie nach erfolgreicher Übermittlung eine Referenz oder Bestätigung aus.
• Rückrufanfrage: Nutzen Sie sie, wenn Kundinnen und Kunden nicht in einer Warteschlange warten sollten; erfassen Sie eine geeignete Kontaktmethode und nur die erforderlichen Angaben zur Terminplanung.
• Persönliche oder spezialisierte Route: Nutzen Sie sie, wenn eine Aufgabe lokale, praktische oder regulierte Unterstützung erfordert.
• Notfall- oder Schutzroute: Heben Sie diese, wo relevant, von regulärem Support ab; Formulierung und Verantwortlichkeit müssen vom zuständigen Serviceteam genehmigt sein.

Formulieren Sie Texte, die den nächsten Schritt zeigen, ohne nicht haltbare Zusagen zu machen

Fallback-Texte sollten die Situation anerkennen, die verfügbare Aktion nennen und erklären, was danach geschieht. Vermeiden Sie, Kundinnen und Kunden die Schuld zu geben, Fachjargon und vage Formulierungen wie „Versuchen Sie es später erneut“, wenn keine andere Wahl besteht. Vermeiden Sie Zusagen zu Antwortzeiten, sofern das zuständige Team diese nicht zuverlässig einhalten kann und die Formulierung genehmigt hat.

Nutzen Sie kanalspezifische Texte. Eine Telefonoption benötigt Nummer und Zeiten. Eine Rückrufanfrage benötigt den erwarteten Bestätigungsmechanismus und mögliche Einschränkungen. Ein Formular benötigt eine Aussage darüber, was Kundinnen und Kunden einreichen können, sowie eine eindeutige Erfolgsmeldung. Ein Zustand außerhalb der Öffnungszeiten benötigt die nächste verfügbare Aktion, keine Sackgasse.

• Beispiel für eine Widget-Fehlermeldung: „Chat ist derzeit nicht verfügbar. Sie können Support über unser barrierefreies Formular anfragen oder uns während [Zeiten] unter [Nummer] anrufen.“
• Beispiel für einen Ausstieg aus der Automatisierung: „Ich konnte dies im Chat nicht lösen. Wählen Sie ‚Hilfe von einer Person anfordern‘, um Ihre Angaben an das Supportteam zu senden, oder nutzen Sie [alternative Route].“
• Beispiel für eine Formularbestätigung: „Ihre Anfrage ist eingegangen. Bewahren Sie diese Bestätigung für Ihre Unterlagen auf. Wenn Ihr Anliegen dringend ist, rufen Sie [Nummer] an.“
• Vermeiden Sie: „Wir antworten in Kürze“, sofern „in Kürze“ keine operativ festgelegte und überwachte Bedeutung hat.

Übertragen Sie Kontext sorgfältig – mit Grenzen für Einwilligung und Verifizierung

Die Übertragung von Kontext kann den Aufwand für Kundinnen und Kunden verringern, muss aber angemessen sein. Definieren Sie für jede Fallback-Route einen kleinen Übergabedatensatz: Anliegenkategorie, eine kurze von Kundinnen und Kunden verfasste Zusammenfassung, Schritt in der Journey, relevante Fallreferenz und bevorzugte Kontaktmethode können ausreichen. Legen Sie fest, was nie automatisch kopiert wird, etwa unnötige Anhänge, sensible Freitexte oder Zugangsdaten.

Teilen Sie Kundinnen und Kunden mit, was an das nächste Team gesendet wird, und geben Sie ihnen gegebenenfalls die Möglichkeit, dies zu prüfen oder zu ändern. Wenn eine andere Abteilung, ein anderes System oder ein anderer Zweck beteiligt ist, sollten Datenschutzprüfende entscheiden, ob eine neue Einwilligung, ein neuer Hinweis oder eine andere Rechtsgrundlage erforderlich ist. Eine Fallback-Route ist kein Grund, mehr Daten zu erheben, als die Aufgabe benötigt.

Empfangende Mitarbeitende müssen die Identität über den genehmigten Prozess der Organisation prüfen, bevor sie Kontoinformationen offenlegen oder sensible Anfragen bearbeiten. Eine Fallreferenz kann helfen, die Bearbeitung zu finden; sie ist nicht automatisch ein Identitätsnachweis.

• Definieren Sie die minimalen Übergabefelder und die Aufbewahrungsregel für jede Route.
• Bitten Sie Kundinnen und Kunden niemals, Passwörter, Authentifizierungscodes oder andere Zugangsdaten über Chat oder ein Fallback-Formular zu senden.
• Halten Sie eine kundenseitige Erklärung dazu bereit, welche Informationen übertragen werden und warum.
• Lassen Sie Mitarbeitende das ursprüngliche Gespräch nur sehen, wenn ihre Rolle und der Fall dies erfordern.
• Stellen Sie einen manuellen Weg bereit, wenn Kontext nicht sicher oder technisch übertragen werden kann.

Schaffen Sie eindeutige Ausstiege aus der Automatisierung und einen Weg zur menschlichen Eskalation

Die Automatisierung sollte einen Ausstieg anbieten, bevor Frustration zum Abbruch wird. Definieren Sie Auslöser für einen unterstützten Weg: wiederholt missverstandene Absicht, wiederholte Fehler bei validierten Antworten, eine ausdrückliche Anfrage nach einer Person, ein Thema mit hohem Risiko, eine Anfrage außerhalb des Zuständigkeitsbereichs oder ein automatisierter Ablauf, der einen erforderlichen Schritt nicht abschließen kann.

Die Eskalationsroute muss eine empfangende Warteschlange oder einen alternativen Kanal benennen und darf nicht nur eine beruhigende Nachricht anzeigen. Legen Sie fest, was die Automatisierung übergibt, was Kundinnen und Kunden als Nächstes tun müssen und was geschieht, wenn gerade keine Person verfügbar ist. Wenn eine Übergabe nicht besetzt werden kann, bieten Sie stattdessen die genehmigte Route für Rückruf, Formular oder Telefon an.

Menschliches Urteilsvermögen bleibt für Ausnahmen, mehrdeutige Anfragen, Beschwerden, Hinweise auf Vulnerabilität und Fälle erforderlich, in denen Richtlinien oder Sicherheit eine Prüfung verlangen. Mitarbeitende benötigen Anweisungen zum Annehmen, Weiterleiten und Abschließen von Fallback-Anfragen, einschließlich des Vorgehens, wenn die Anfrage in der falschen Abteilung eingegangen ist.

• Auslöser: Kundin oder Kunde wählt „Mit einer Person sprechen“ oder eine gleichwertige Option; Aktion: Bieten Sie eine besetzte Übergabe oder eine klar gekennzeichnete alternative Route an.
• Auslöser: zwei oder mehr erfolglose Versuche mit derselben validierten Antwort; Aktion: Erklären Sie die Blockade und bieten Sie Hilfe an, ohne einen weiteren Versuch zu erzwingen.
• Auslöser: sensibles, dringendes oder richtliniendefiniertes Anliegen; Aktion: Unterdrücken Sie ungeeignete Automatisierung und leiten Sie zur zuständigen Serviceroute.
• Auslöser: außerhalb der Öffnungszeiten; Aktion: Zeigen Sie die aktuelle Verfügbarkeit und die nächste unterstützte Aktion, ohne anzudeuten, dass Live-Hilfe vorhanden ist.

Weisen Sie Verantwortlichkeiten über Warteschlangen, Zeitpläne und Abteilungen hinweg zu

Jede Fallback-Anfrage benötigt vom Eingang bis zur Lösung eine rechenschaftspflichtige verantwortliche Person. Ordnen Sie das Betriebsmodell nach Anfrageart, Kanal, internem Team, Abdeckungszeiten, Eskalationskontakt und Abschlussstandard. Unterscheiden Sie das Team, das die Darstellung auf der Website verantwortet, von dem Team, das das Serviceergebnis verantwortet; dies muss nicht dasselbe sein.

Ein gemeinsamer Posteingang kann nützlich sein, wenn WebChat- und WhatsApp-Gespräche koordiniert bearbeitet werden müssen, aber nicht jeder Fallback muss in denselben Arbeitsbereich eingehen. Telefonische, persönliche und spezialisierte Routen können eigene Systeme und Kontrollen haben. Entscheidend sind eine dokumentierte Übergabe und eine Möglichkeit, Anfragen zu erkennen, die keine verantwortliche Antwort erhalten haben.

Planen Sie für Nachfrageänderungen, geschulte Abdeckung, Datenschutz und Rückkopplungsschleifen. Ist eine Route außerhalb der Betriebszeiten nicht verfügbar, legen Sie die Formulierung außerhalb der Öffnungszeiten und die Verantwortlichkeit für dann eingehende Anfragen fest und testen Sie sie.

• Benennen Sie für jede Route eine Serviceverantwortung, eine tägliche Warteschlangenverantwortung und eine Eskalationsverantwortung.
• Dokumentieren Sie Öffnungszeiten, Sprachabdeckung, spezialisierte Abdeckung und die Bearbeitung außerhalb der Öffnungszeiten.
• Definieren Sie Routing-Regeln für Anfragen beim falschen Team, doppelte, unvollständige und dringende Anfragen.
• Geben Sie Mitarbeitenden Vorlagen, Anweisungen zur Verifizierung und einen klaren Weg für Bedenken zur Barrierefreiheit oder zum Datenschutz.
• Prüfen Sie ungelöste Anfragen und wiederkehrende Fehlermuster mit den Teams, die sie beheben können.