Ein nützlicher Booking Ninjas Support-Fall erklärt, was passiert ist, wo es passiert ist, was Sie erwartet haben und wie das Problem das Geschäft beeinflusst.
Sie müssen die technische Ursache nicht diagnostizieren. Klare betriebliche Details sind nützlicher als zu raten, was hinter dem Bildschirm falsch ist.
Was sollten Sie einfügen?
- Eine klare Zusammenfassung. Nennen Sie das Problem oder die Anfrage in einem Satz.
- Der betroffene Workflow oder Bereich. Erklären Sie, wo im Booking Ninjas das Problem auftritt.
- Erwartete und tatsächliche Ergebnisse. Sagen Sie, was Sie erwartet haben und was stattdessen passiert ist.
- Schritte oder Beispiele. Fügen Sie die Aktionen hinzu, die zum Problem geführt haben, wenn Sie es reproduzieren können.
- Betroffene Benutzer oder Datensätze. Geben Sie genügend Kontext, um ein nützliches Beispiel zu identifizieren, ohne private Anmeldeinformationen offenzulegen.
- Screenshots oder unterstützende Beweise. Fügen Sie diese hinzu, wenn sie das Problem leichter verständlich machen.
- Geschäftliche Auswirkungen. Erklären Sie, welche Arbeit blockiert ist, wer betroffen ist und ob es eine Umgehungslösung gibt.
Beispiel: „Die Benutzer an der Rezeption können eine Reservierung nach der Einzahlung nicht bestätigen“ ist nützlicher als „Die Buchung ist kaputt.“
Wie sollten Sie Auswirkungen und Dringlichkeit beschreiben?
Beschreiben Sie, was das Problem mit dem Betrieb macht, anstatt nur „dringend“ zu schreiben. Zum Beispiel: keine Benutzer können Buchungen abschließen, ein Team ist blockiert, ein Kundenrekord ist betroffen oder das Problem kann vorübergehend umgangen werden.
Die Anleitung zum Service-Management trennt häufig Auswirkungen von Dringlichkeit. Die Auswirkungen beschreiben, wie viel des Geschäfts betroffen ist, während die Dringlichkeit beschreibt, wie schnell der Effekt wichtig ist. Beides zu kontextualisieren hilft dem Support-Team, die Situation zu verstehen, ohne sich auf ein vages Prioritätslabel zu verlassen.
Was sollten Sie vermeiden?
- Passwörter oder private Anmeldeinformationen. Platzieren Sie diese nicht in einer Fallbeschreibung oder einem Screenshot.
- Mehrere nicht verwandte Probleme in einem Fall. Getrennte Themen sind einfacher separat zu verfolgen.
- Nur ein Screenshot ohne Erklärung. Fügen Sie das erwartete Ergebnis und die Aktion hinzu, die zum Problem geführt hat.
- Nur das Wort „dringend.“ Erklären Sie die tatsächlichen geschäftlichen Auswirkungen und ob es eine Umgehungslösung gibt.
Was ist, wenn Sie bereits eine Direktnachricht gesendet haben?
Wenn Sie bereits Booking Ninjas über WhatsApp oder E-Mail kontaktiert haben und das Problem untersucht oder formal nachverfolgt werden muss, öffnen Sie einen Support-Fall und platzieren Sie den wichtigen Kontext dort.
Sie können weiterhin Direktnachrichten zur Koordination verwenden, aber der Fall sollte das Hauptdokument für das verfolgte Problem werden. Wenn bereits ein Fall existiert, verweisen Sie darauf, anstatt eine separate Nachrichtenhistorie zu erstellen.
Was passiert, nachdem Sie eingereicht haben?
Das Team überprüft den Fall und kann um weitere Informationen bitten, bevor er verstanden oder getestet werden kann. Lesen Sie Was passiert, nachdem Sie einen Support-Fall eingereicht haben? für den nächsten Teil des Prozesses.
Quellen und weiterführende Literatur
- Wie Änderungen getestet werden — erklärt, warum klare Szenarien und erwartete Ergebnisse wichtig sind, wenn eine Änderung getestet werden muss.
- Salesforce Hilfe: Best Practices für das Fallmanagement — erklärt den Wert der Erfassung relevanter Falldetails und der Beibehaltung eines strukturierten Fallprozesses.
- Atlassian: Wie Auswirkungen und Dringlichkeit zur Berechnung der Priorität verwendet werden — erklärt die allgemeine Unterscheidung zwischen geschäftlichen Auswirkungen, Dringlichkeit und Priorität.
Externe Quellen unterstützen allgemeine Praktiken im Service-Management. Booking Ninjas kann unterschiedliche interne Felder oder Workflows für seine Support-Fälle verwenden.