Ticket-Konsole · die Zentrale für den Kundenservice

Die Ticket-Konsole ist das Arbeitsfenster, in dem Ihr Team die Anfragen abarbeitet: links die Warteschlange mit gespeicherten Ansichten, in der Mitte das Gespräch mit dem Kunden, rechts der Kontext mit SLA-Uhren und KI. Hier finden Sie ebenso den E-Mail-Eingang, die Makros, das Routing, die Automatisierungen, die Störungen, die Wissensdatenbank und die Kennzahlen des Teams.

Die Ticket-Konsole ist die Servicezentrale von SellioCRM: ein einziger Ort, um Anfragen in der Warteschlange abzuarbeiten, von der ersten E-Mail des Kunden bis zur Zufriedenheitsumfrage. Sie nutzt dasselbe Objekt Ticket wie das CRM, alles, was Sie ohnehin erfassen (Betreff, Firma, Kontakt, Kategorie, Kanal), gilt also weiterhin und erscheint in der 360-Grad-Ansicht des Kunden.

Öffnen Sie sie über das seitliche Menü, in der Gruppe Kundenservice, unter Ticket-Konsole. Das Objekt Tickets bleibt in derselben Gruppe, für alle, die lieber mit dem Formular, der Statustafel und den Listenansichten arbeiten.

Aufbau in drei Bereichen

Die Konsole öffnet sich in drei Bereichen und ist für Menschen gemacht, die den ganzen Tag Anfragen bearbeiten: links die Ansichten und Warteschlangen mit Zählern, in der Mitte das Gespräch mit dem Kunden, rechts der Kontext des Tickets. Auf dem Handy wird der Ansichtsbereich zu einer Auswahl oben in der Liste, damit er keinen Platz wegnimmt.

Die Warteschlange und die gespeicherten Ansichten

• Die linke Spalte bringt fertige Ansichten mit der Anzahl der Anfragen in jeder einzelnen: Offen, Nicht zugewiesen, Meine, Wartend (auf den Kunden oder auf Dritte) und Heute gelöst.
• Gespeicherte Ansichten: Legen Sie einen benannten Filter nach Status, Priorität, Zuweisung und Gruppe an, zum Beispiel Dringend im Support-Team. Er erscheint in der Liste mit einem eigenen Zähler.
• Über der Warteschlange liegen die Suche (nach Betreff oder Anfragendem), der Prioritätsfilter und die Sortierung: neueste, älteste, nach Priorität oder nach SLA-Frist.
• Jede Zeile zeigt den Betreff, den Anfragenden, den Status, die Priorität, den Zuständigen und den SLA-Zustand, mit farbigen Kennzeichen zum schnellen Erfassen.
• Massenaktionen: Setzen Sie oben das Häkchen, um mehrere Anfragen auszuwählen und Status oder Zuständigen in einem Zug zu setzen.

Die Agentenkonsole

Wenn Sie ein Ticket öffnen, erscheint das Gespräch in der Mitte in zeitlicher Reihenfolge, und die Eigenschaften stehen rechts: Anfragender, Eingangskanal, Etiketten, Status, Priorität, Kategorie, Zuständiger und Gruppe. Jede Änderung an einer Eigenschaft wird sofort gespeichert.

1. Wählen Sie im Editor Kunde antworten, um etwas zu schreiben, das der Kunde sieht, oder Interne Notiz, um etwas festzuhalten, das nur das Team sieht.
2. Die interne Notiz erscheint in einer anderen Farbe hervorgehoben, damit sie nicht mit dem verwechselt wird, was dem Kunden gesagt wurde.
3. Klicken Sie auf Anhängen, um Dateien zusammen mit der Nachricht zu verschicken (bis zu 25 MB je Datei). Bei einer öffentlichen Antwort gehen die Links zu den Anhängen ebenso im Text der E-Mail an den Kunden.
4. Schreiben Sie den Text und klicken Sie auf Senden (oder auf Notiz hinzufügen).

• Ticketnummer: Jede Anfrage erhält eine fortlaufende Nummer je Organisation, im Format #000123. Sie ist unveränderlich und erscheint in der Warteschlange, oben im Ticket und in der Antwort-E-Mail.
• Verlauf: Der Reiter Verlauf führt die öffentlichen und die internen Nachrichten sowie die Änderungsereignisse (Anlage, Status, Priorität, Zuständiger und weitere Eigenschaften) der Reihe nach zusammen.
• Erwähnungen und Follower: Nutzen Sie in einer internen Notiz Erwähnen, um eine Kollegin oder einen Kollegen hinzuzuziehen. Die Person erhält eine Benachrichtigung und folgt dem Ticket ab diesem Moment. Jede Person kann über den Eigenschaftsbereich folgen oder das Folgen beenden und wird bei jeder Aktualisierung informiert.

Makros und Variablen

1. Klicken Sie auf Makros verwalten, um gespeicherte Antworten mit Titel und Text anzulegen.
2. Optional legt das Makro fest, welcher Status und welche Priorität bei seiner Anwendung gesetzt werden.
3. Wählen Sie im Editor unter Makro anwenden das gewünschte Makro: Der Text wandert in das Antwortfeld, und sofern konfiguriert, werden Status und Priorität gesetzt.

Makros und Antworten verstehen Variablen in doppelten geschweiften Klammern, die beim Versand gefüllt werden: {{protocol}}, {{ticket_subject}}, {{requester_name}}, {{agent_name}} und {{org_name}}, unter anderem. Unter Kanäle und Routing legen Sie eine Signatur des Kundenservice fest, die an die öffentlichen Antworten angehängt wird; die persönliche Signatur des Agenten hat Vorrang, sofern sie vorhanden ist.

SLA: Fristen, Pause, Arbeitszeiten und Feiertage

Der SLA-Zustand erscheint in der Warteschlange und im Ticket: Im Zeitplan oder SLA verletzt, solange es offen ist, und Fristgerecht gelöst oder Verspätet gelöst, nachdem es gelöst wurde. Rechts zählen die Uhren für die erste Antwort, die nächste Antwort und die Lösung rückwärts und wechseln die Farbe: grün, gelb kurz vor der Frist und rot, wenn sie abläuft. Sobald Sie den Status auf Gelöst oder Geschlossen setzen, wird das Lösungsdatum automatisch gestempelt.

• Automatische Pause: Wenn Sie das Ticket auf Wartet auf Kunde oder Wartet auf Dritte setzen, pausiert die Lösungsuhr und ein Kennzeichen SLA pausiert erscheint. Zurück in einem aktiven Status läuft die Uhr weiter. Die Wartezeit zählt weder gegen Ihr Ziel noch in den Kennzahlen.
• Nächste Antwort: Jede Richtlinie kann ein Ziel für die nächste Antwort haben. Die Uhr startet, sobald der Kunde antwortet, und beginnt bei jeder neuen öffentlichen Antwort des Agenten von vorn.
• Geschäftszeiten: Im Reiter SLA und Zeiten legen Sie Tage, Uhrzeiten und die Zeitzone fest (geben Sie eine Zone wie Europe/Berlin an, damit die Sommerzeit berücksichtigt wird). Schalten Sie die Einschränkung ab, um durchlaufend zu zählen (Betrieb rund um die Uhr).
• Feiertage: Erfassen Sie Feiertage nach Datum. An diesen Tagen gilt der Betrieb als geschlossen, und die Frist rückt auf den nächsten Werktag.
• Richtlinien: Jede Richtlinie greift nach Priorität, Gruppe oder Kategorie (leer bedeutet beliebig) und legt Ziele in Arbeitsminuten fest. Sie werden in der Reihenfolge der Liste geprüft, und die erste aktive, die passt, gilt. Passt keine Richtlinie, gelten die Stunden je Priorität aus Einstellungen, Kundenservice.
• Verletzungsrisiko: Ein geschätzter Balken zeigt, ob das Ticket ein geringes, mittleres oder hohes Risiko hat, die Frist zu reißen, samt Begründung.

E-Mail-Eingang: Aus der E-Mail wird ein Ticket

1. Öffnen Sie die Ticket-Konsole und wechseln Sie in den Reiter Kanäle und Routing.
2. Klicken Sie auf Support-Adresse erzeugen. Das CRM zeigt eine Adresse im Format support+ihr-code@domain.
3. Leiten Sie bei Ihrem E-Mail-Anbieter das Support-Postfach an diese Adresse weiter.
4. Fertig: Neue E-Mails eröffnen Tickets, und die Antworten des Kunden landen im selben Gespräch.

Der Absender wird über die E-Mail-Adresse einem Kontakt zugeordnet; beim ersten Mal wird der Kontakt angelegt, und der Kanal des Tickets lautet E-Mail. Jede Antwort an den Kunden trägt den Code des Tickets im Betreff, im Format [#XXXXXXXX]. Antwortet der Kunde und lässt den Code stehen, landet die Nachricht im selben Gespräch, statt ein neues Ticket zu eröffnen; war das Ticket gelöst oder geschlossen, wird es wieder geöffnet.

Automatische Eingangsbestätigung: Aktivieren Sie unter Kanäle und Routing die Eingangsbestätigung und schreiben Sie den Text mit den Variablen. Sobald eine E-Mail ein neues Ticket eröffnet, erhält der Anfragende sofort die Bestätigung mit der Ticketnummer. Sie ist anfangs ausgeschaltet.

Tickets zusammenführen und Nebengespräche

Wenn aus demselben Anliegen zwei Tickets geworden sind, öffnen Sie das Ticket, das bestehen bleiben soll, und klicken Sie auf Zusammenführen. Die Nachrichten des anderen wandern in das führende Ticket, und das andere wird mit einem Hinweis geschlossen, der zeigt, wohin es gegangen ist.

Sie müssen mit einem Lieferanten oder mit einem anderen Team sprechen, ohne dass der Kunde mitliest? Nutzen Sie die Nebengespräche direkt unter dem Hauptgespräch: Geben Sie einen Betreff und die Beteiligten per E-Mail an, schreiben Sie die Nachricht, und das CRM verschickt sie. Alles wird im Ticket festgehalten, getrennt vom Gespräch mit dem Kunden.

Automatische Zuweisung und Automatisierungen

Legen Sie unter Kanäle und Routing für jedes Team fest, wie die Tickets verteilt werden, sobald sie in der Gruppe ankommen: Round Robin (im Wechsel zwischen den Agenten) oder Nach Auslastung (zuerst der Agent mit den wenigsten offenen Tickets). Lassen Sie es auf Aus, um immer von Hand zuzuweisen.

Im Reiter Automatisierungen legen Sie Regeln nach dem Muster wenn sich etwas ändert, dann handle an. Jede Regel hat ein Ereignis (das Ticket wird angelegt, oder eine Eigenschaft ändert sich), optionale Bedingungen zu Status, Priorität, Kategorie, Gruppe und Zuständigem sowie eine oder mehrere Aktionen.

• Aktionen: Status, Priorität oder Kategorie setzen; einem Agenten oder einer Gruppe zuweisen; ein Makro anwenden; den Zuständigen benachrichtigen; die ganze Gruppe benachrichtigen; die Zufriedenheitsumfrage verschicken.
• Die Regeln laufen genau im Moment der Anlage oder der Änderung, an jeder Stelle im CRM: in der Konsole, beim Bearbeiten des Datensatzes oder über eine Integration.
• Ziehen Sie am Griff links neben dem Namen, um die Reihenfolge zu ändern; die Regeln werden von oben nach unten geprüft.
• Zeitgesteuerte Automatisierungen: Sie laufen in festen Abständen von allein und handeln nach der Frist, etwa ein Ticket eskalieren, das seit X Arbeitsstunden ohne erste Antwort ist, warnen, wenn die Frist bald reißt, oder die seit N Tagen gelösten Tickets schließen. Jede greift höchstens einmal je Ticket.
• Ausgehende Webhooks: Informieren Sie unter Kanäle und Routing externe Systeme über jedes Ereignis des Tickets (angelegt, aktualisiert, gelöst, neue Nachricht), an eine signierte URL oder an die Nachrichtenkanäle, die im Integrationen-Hub bereits verbunden sind.

Künstliche Intelligenz im Ticket

Bei aktiver KI wertet der rechte Bereich das Ticket aus und schlägt vor: Kategorie und Dringlichkeit, Stimmung des Kunden mit einem Wert von 0 bis 100, Zusammenfassung des Verlaufs, ähnliche Tickets und Artikel aus der Wissensdatenbank. Im Editor entwirft die Schaltfläche Antwort vorschlagen (KI) aus dem Gespräch heraus eine Antwort, in der Sprache Ihrer Oberfläche. Die KI schickt dem Kunden nie etwas von allein: Sie prüfen, bearbeiten und entscheiden.

Wissensdatenbank und Help Center

Ihre Wissensdatenbank speist ein öffentliches Selbstbedienungsportal mit einer Suche über Titel, Inhalt und Etiketten. Am Ende der Seite schlägt das Formular Ich brauche weiterhin Hilfe passende Artikel vor, während die Person tippt (Deflection), und eröffnet, falls es doch nötig ist, ein Ticket direkt in Ihrem CRM.

• Unter Marketing, Wissensdatenbank, erlaubt der Reiter Artikel das Schreiben, Bearbeiten und Einreichen zur Prüfung; der Reiter Prüfung ist die Freigabewarteschlange (Freigeben und veröffentlichen oder Mit Begründung ablehnen); der Reiter Importieren legt aus einer URL einen Entwurf an; der Reiter Feedback zeigt anhand der Stimmen der Leser die nützlichsten Artikel und die, die Aufmerksamkeit brauchen.
• Jedes Speichern legt eine Fassung im Verlauf ab, und Sie können eine frühere Fassung wiederherstellen.
• Jeder Artikel hat eine Sprache, und die öffentliche Suche kann nach der Sprache des Lesers filtern.
• Im Reiter SLA und Zeiten bauen Sie die Formulare für die Ticketeröffnung im Portal: Neben Name, E-Mail, Betreff und Nachricht fügen Sie eigene Felder vom Typ Text, Liste oder E-Mail hinzu, auch mit bedingter Anzeige. Markieren Sie eines als Standard, damit das Help Center es verwendet.

Störungen und Statusseite

1. Öffnen Sie in der Konsole den Reiter Störungen und legen Sie eine Störung mit Titel und Schweregrad an.
2. Verknüpfen Sie die Tickets, die von demselben Ereignis betroffen sind.
3. Veröffentlichen Sie Aktualisierungen im Verlauf der Störung und informieren Sie alle Betroffenen auf einmal, per E-Mail an die Anfragenden der verknüpften Tickets.
4. Halten Sie beim Lösen die Ursache und die Nachbetrachtung fest.
5. Markieren Sie die Störung als öffentlich, um Ihren Kunden eine offene Statusseite zu zeigen.

Zufriedenheit und Kennzahlen

Sobald Sie ein Ticket lösen oder schließen, verschickt das CRM automatisch eine Zufriedenheitsumfrage per E-Mail an den Anfragenden, mit einer Note von 1 bis 5 und einem Kommentar. Das geschieht genau einmal je Ticket. Antwortet der Kunde, erscheint die Note im Block Zufriedenheit der Konsole und wird in den Feldern des Tickets selbst gespeichert. Schalten Sie das unter Automatisierungen, Zufriedenheitsumfrage ein oder aus, und nutzen Sie Umfrage erneut senden, wenn Sie noch einmal fragen möchten.

Im Reiter Kennzahlen verfolgen Sie den Zeitraum von 7, 30 oder 90 Tagen: angelegte, gelöste und offene Tickets, durchschnittliche Zeit bis zur ersten Antwort, durchschnittliche Lösungszeit, Anteil innerhalb des SLA, mittlere Zufriedenheit samt Rücklaufquote, Backlog, Lösung beim ersten Kontakt, Wiedereröffnungsquote und Auslastung je Team, aufgeschlüsselt nach Kanal und nach Kategorie sowie mit einer Tabelle je Agent. Die Indikatoren zeigen die Veränderung gegenüber dem vorherigen Zeitraum und ein kleines Tagesdiagramm, und die Berichte lassen sich als PDF oder XLSX exportieren.

Häufige Fragen

• Der Versand der Umfrage hängt an der E-Mail-Adresse des Anfragenden, sei es aus dem Feld des Tickets oder aus dem verknüpften Kontakt, und daran, dass der E-Mail-Versand eingerichtet ist.
• Wenn Sie unter Einstellungen, Datenschutz die Daten einer betroffenen Person exportieren oder anonymisieren, werden die Inhalte der Nachrichten und der Bewertungen dieses Anfragenden ebenfalls einbezogen oder anonymisiert.
• Integrationen mit externen Helpdesks legen Tickets automatisch im CRM an; sind sie einmal angelegt, bearbeiten Sie sie hier wie jedes andere Ticket.
• In der mobilen App verfolgen Sie ebenfalls die Warteschlange, eröffnen ein Ticket, antworten und ändern den Status.
• Damit der Kunde seine eigenen Tickets selbst verfolgen, beantworten und wieder eröffnen kann, lesen Sie den Artikel zum Kundenportal.

Über- und untergeordnete Fälle, Regeln für Autoantworten und Kanalzuordnung

Ein Fall kann jetzt an einem anderen hängen. Sie setzen den übergeordneten Fall, und die untergeordneten erscheinen als Liste, mit einer Sicherung, die eine Schleife oder eine zu tiefe Kette ablehnt, und einer Warnung, wenn Sie einen Fall schließen wollen, der noch offene Unterfälle hat. Die Autoantwort ist jetzt eine Sache von **Regeln** statt eines festen Textes: jede Regel hat eigene Bedingungen (Kanal, Kategorie, Priorität, Geschäftszeiten, nur erste Nachricht, Stichwörter) und eine eigene Nachricht, und die erste passende gewinnt. Die Schleifensicherung lässt sich absichtlich nicht abschalten: einem automatischen Postfach zu antworten heißt, zwei Anrufbeantworter für immer miteinander reden zu lassen. Und der Kanal des Falls kommt nun aus einer **Zuordnungstabelle**, die Sie steuern: ein Fall, der im Help Desk per Telefon ankam, wird nicht mehr als „Portal“ erfasst, und Ihre Kanalberichte hören auf zu lügen.

Wo Sie das finden: Übergeordneter und untergeordnete Fälle erscheinen am Ticket selbst, im Bereich **Verwandte Fälle**. Die Regeln stehen unter **Einstellungen → Automatische Antworten**, die Zuordnung unter **Einstellungen → Ticketkanäle**; beides ist für die Kontoverwaltung.

Der Fall hat eine dritte Registerkarte, **Kontext**, und dort hört die Konsole auf, Sie auf einen anderen Bildschirm zu schicken. Sie zeigt die Felder des Tickets selbst (auch die von Ihnen angelegten), die verknüpften Datensätze, Aktivitäten und Aufgaben, die Dateien, über- und untergeordnete Fälle sowie die anderen offenen Tickets desselben Kunden. Wenn Sie ein Canvas für das Objekt Ticket entworfen haben, gilt dieses Layout auch hier, Sie zeichnen also nichts doppelt.

Ein Ticket mit einem Ergebniscode schließen

Ein Ticket zu lösen hieß bisher, freien Text in das Feld Lösung zu schreiben. Das beschreibt, was passiert ist, klassifiziert es aber nicht: Zwei Agenten schreiben dasselbe Ergebnis auf zehn Arten, und niemand kann beantworten, wie viele Tickets im letzten Monat ein Produktfehler und wie viele eine Fehlkonfiguration waren. Das Feld Kategorie hilft auch nicht, denn es klassifiziert das Thema beim Öffnen des Tickets, nicht das Ergebnis beim Schließen.

Deshalb ist das Ergebnis jetzt eine kurze Liste, die Sie selbst steuern, unter **Einstellungen → Ergebniscodes**. Jeder Code hat eine Bezeichnung, einen Geltungsbereich und einen Schalter dafür, ob die Auswahl eine Erklärung verlangt (nutzen Sie ihn bei „Sonstiges“, das sonst gar nichts erklärt). Dieselbe Liste gilt für Tickets und für Telefonanrufe, so behalten Sie ein Vokabular statt zwei, die dasselbe sagen.

1. Öffnen Sie Einstellungen → Ergebniscodes und klicken Sie auf Standardliste erzeugen, oder schreiben Sie Ihre eigene Liste.
2. Schalten Sie „Ergebnis beim Lösen verlangen“ ein, wenn die Regel greifen soll.
3. Wählen Sie in der Konsole das Ergebnis im Feld Abschluss rechts aus, bevor Sie das Ticket lösen.

Drei Verhaltensweisen sollten Sie kennen, denn sie sind Absicht:

• **Die Pflicht einzuschalten, bevor es Codes gibt, blockiert nichts.** Sonst würde sie an dem Tag, an dem jemand das Häkchen setzt, jedes Ticket im Unternehmen einfrieren, ohne dass es etwas zur Auswahl gäbe.
• **Die Pflicht setzt der Server durch, nicht der Bildschirm.** Schließen aus der Liste, per Makro, über die API oder im Terminal läuft durch dieselbe Prüfung.
• **Ein bereits benutzter Code lässt sich nicht löschen, nur deaktivieren.** Löschen würde jedem damit geschlossenen Ticket die Bedeutung nehmen, und Ihre alten Berichte würden still zu lügen beginnen.

Textbaustein: fertige Sätze hinter einem getippten Kürzel

Bisher war der einzige fertige Text in der Konsole das Makro, und ein Makro setzt auch einen Status und eine Priorität: einen Satz einzufügen veränderte das Ticket, ohne dass jemand darum gebeten hätte. Ein Textbaustein schreibt nichts außer dem Text. Genau deshalb darf er leicht und persönlich sein und über ein getipptes Kürzel erreichbar.

1. Tippen Sie im Editor :: gefolgt vom Anfang eines Kürzels, zum Beispiel ::hi.
2. Tippen Sie weiter, um die Liste einzugrenzen, oder tippen Sie nur ::, um die ganze Bibliothek zu sehen.
3. Wählen Sie einen Satz aus der Liste, oder tippen Sie das Kürzel zu Ende und bestätigen Sie, um den exakt passenden einzufügen.
4. Lesen Sie den Text vor dem Senden: Variablen in doppelten geschweiften Klammern wie {{protocol}}, {{ticket_subject}}, {{requester_name}}, {{agent_name}} und {{org_name}} werden beim Senden der Antwort eingesetzt, genau wie bei Makros.

Es gibt drei Bibliotheken: **persönlich** (nur Sie sehen sie), **Team** (wer in diesem Team ist) und **Unternehmen** (alle, die antworten). Dasselbe Kürzel darf in mehreren vorkommen, und die Ihnen nächste gewinnt: Ihr persönlicher Satz schlägt den des Teams, und der des Teams schlägt den des Unternehmens. So behalten Sie Ihre eigene Fassung von ::hi, ohne jemanden zu bitten, den Standard des Hauses zu ändern.

• **Ein Kürzel hat keine Leerzeichen und keinen Doppelpunkt** und ist höchstens 40 Zeichen lang. Ein Kürzel mit Leerzeichen ließe sich nach :: nie tippen, deshalb wird es beim Speichern abgelehnt, statt ein Satz zu werden, der nie erscheint.
• **Das Kürzel ist innerhalb seiner eigenen Bibliothek eindeutig.** Dasselbe ::hi darf als persönlicher und als Unternehmenssatz bestehen; zwei Unternehmenssätze nicht.
• **Die Suche ignoriert Groß- und Kleinschreibung sowie Akzente** und schaut auf das Kürzel, dann auf den Titel, dann auf den Ordner. Der Textkörper wird nie durchsucht: ein häufiges Wort träfe die halbe Bibliothek, und das Kürzel verlöre seinen Sinn.
• **Die Reihenfolge ist immer dieselbe**: Kürzel, das mit dem Getippten beginnt, dann Kürzel, das es enthält, dann Titel, dann Ordner. Eine Liste, die zwischen zwei Aufrufen die Reihenfolge wechselt, ließe Sie den falschen Satz aus dem Muskelgedächtnis wählen.
• **Der Ordner ist freier Text** und gruppiert die Bibliothek nur auf dem Bildschirm. Es gibt keine getrennte Kategorienverwaltung zu pflegen.

Ihre persönlichen Sätze gehören Ihnen: anlegen, ändern und löschen, ohne jemanden zu fragen. Team- und Unternehmenssätze sind Standard des Hauses, denn sie ändern, was morgen alle an Kundschaft schicken, und gehören daher denen, die die Einstellungen verwalten. Niemand bearbeitet den persönlichen Satz einer anderen Person, auch die Verwaltung nicht.

Ticket-E-Mails: eigener Text je Ereignis, Sprache, Kategorie und Warteschlange

Fünf Momente des Tickets können einen eigenen Text tragen: **eröffnet**, **aktualisiert**, **gelöst**, **Umfrage** und **Abschluss**. Jede Vorlage ist in einer Sprache geschrieben und kann wahlweise auf eine Kategorie, auf eine Warteschlange oder auf beides beschränkt werden.

Die Auswahl folgt einer erklärten Reihenfolge, und sie liest sich am besten in zwei Hälften: das System entscheidet zuerst, **was gesagt wird**, und erst danach, **in welcher Sprache**. Die Familien werden von der spezifischsten zur allgemeinsten besucht: Warteschlange und Kategorie, dann Warteschlange, dann Kategorie, dann die allgemeine. Die Warteschlange wiegt schwerer als die Kategorie, weil die Warteschlange das antwortende Team ist und der Text seine Stimme; die Kategorie ist nur das Thema.

• **Ein leerer Filter ist ein Platzhalter, ein gefüllter muss passen.** Eine Vorlage ohne Kategorie gilt für jede Kategorie. Eine Vorlage mit Kategorie gilt nur für diese und vertritt nie den allgemeinen Text.
• **Sprache innerhalb der gewählten Familie**: zuerst die exakte (pt-BR), dann dieselbe Grundsprache (pt-PT dient pt-BR), dann die Ersatzsprache, und das ist Englisch, solange Sie nichts anderes sagen.
• **Eine Familie ohne eine dieser drei Sprachen wird übersprungen**, und die nächste, weniger spezifische wird versucht. Den allgemeinen Text in der Sprache der lesenden Person zu schicken ist besser als den richtigen Text in einer Sprache, die sie nicht liest.
• **Spezifität kommt vor Sprache.** Gibt es die Familie Rechnungswesen nur auf Englisch und die allgemeine auf Portugiesisch, erhält eine Person, die auf Portugiesisch schreibt, den Text zum Rechnungswesen auf Englisch. Die Lösung ist, die portugiesische Zeile derselben Familie zu ergänzen, und genau das verlangt die Tabelle von Ihnen.

Maßgeblich ist die Sprache **der anfragenden Person**, die die E-Mail liest, nicht die der Agentin oder des Agenten. Betreff und Text nehmen dieselben Variablen wie Makros und Textbausteine, und die Vorschau zeigt, welche Vorlage gewonnen hat und in welcher Sprache, bevor irgendetwas hinausgeht.

Swarm: Leute zu einem schweren Fall holen und festhalten, was dabei herauskam

Eine Swarm-Sitzung hält das Ritual fest, das bisher verstreut in internen Notizen lebte: wer geholt wurde, in welcher Rolle, für welche Frage, bis wann, und was am Ende feststand. **Sie hält die Sitzung fest; sie öffnet keinen Slack-Kanal und startet keine Videokonferenz.** Das Gespräch findet weiter dort statt, wo es ohnehin stattfindet (interne Notiz, Erwähnung, Follower, interner Chat); neu ist nur die Erinnerung daran.

1. Öffnen Sie am Ticket einen Swarm und schreiben Sie den Grund. Eine Frist ist optional und darf nicht in der Vergangenheit liegen.
2. Wer die Sitzung öffnet, ist **Berichterstattung** und folgt ab da dem Ticket.
3. Holen Sie die nötigen Personen als **Fachkraft** (ohne Obergrenze) oder als **Protokoll** (ein einziger Platz). Wer geholt wird, erhält einen Hinweis mit dem Grund und folgt ab da dem Ticket.
4. Schließen Sie die Sitzung mit dem **Ergebnis**. Es wird als interne Notiz an das Ticket zurückgeschrieben, damit die nächste Person am Fall es liest, ohne sonst etwas zu öffnen.

• **Eine offene Sitzung je Ticket.** Zwei würden die Aufmerksamkeit halbieren, und das Ergebnis hätte keinen einzigen Ort.
• **Berichterstattung und Protokoll sind Einzelplätze, solange sie besetzt sind**; Fachkräfte haben keine Obergrenze, denn Leute zu holen ist genau der Sinn eines Swarms.
• **Die Berichterstattung verlässt die Sitzung nicht.** Der Ausweg ist, sie mit dem Ergebnis zu schließen, und sei es „es stand nichts fest“.
• **Schließen verlangt das Ergebnis** und beendet die Teilnahme aller, damit die Personenminuten nicht von allein weiterwachsen.
• **Wer gegangen ist, bleibt im Protokoll sichtbar.** Wer teilgenommen hat, muss auch morgen noch stimmen.

Geplantes Nachfassen und persönliche Erinnerung

Zwei Aktionen, die sich ähneln und nicht dasselbe sind. Das **Nachfassen** ist eine Aufgabe zum Ticket: sie kann bei einer anderen Person liegen und erscheint in der Tagesliste wie jede Aufgabe. Die **Erinnerung** gehört immer Ihnen und meldet sich zur gewünschten Zeit, nicht erst in der Zusammenfassung am Tagesende.

1. Wählen Sie am Ticket Nachfassen planen oder Mich erinnern.
2. Schreiben Sie den Zeitpunkt in eigenen Worten: morgen 9 Uhr, in 2 Stunden, Freitag, nächste Woche, oder ein Datum wie 2026-09-10 14:30. Die zehn Sprachen des Produkts werden verstanden.
3. Beim Nachfassen wählen Sie die Art (Aufgabe, Anruf, E-Mail oder Termin) und, wenn Sie wollen, die Person, die es übernimmt. Die Erinnerung ist immer eine Aufgabe und immer Ihre.

• **Ein Tag ohne Uhrzeit wird 09:00 Uhr** in der Zeitzone der Organisation, derselbe Standardwert wie im Rest des Produkts.
• **Eine Dauer behält die aktuelle Uhrzeit**, denn eine Dauer trägt sie schon in sich. Minuten und Stunden zählen in Echtzeit; Tage und Wochen gehen über den Kalender, damit die Sommerzeit sie nicht verschiebt.
• **Eine bereits vergangene Uhrzeit wandert auf den nächsten Tag**, wie in jeder Erinnerungs-App. Ein Tag in der Vergangenheit wird dagegen abgelehnt statt erraten: zu raten, welchen Tag Sie meinten, wäre erfunden.
• **Weiter als 365 Tage voraus wird abgelehnt.** Das ist der Filter für den falschen Finger, das 2027, das 2026 getippt wurde und das niemand je sähe.

Der Bildschirm wiederholt die Uhrzeit, die tatsächlich **gespeichert** wurde, und nicht Ihre Worte, sobald 09:00 Uhr für Sie angenommen oder die Uhrzeit auf den nächsten Tag geschoben wurde. Zwei verschiedene Antworten auf „wann ist das fällig“ sind genau die Verwirrung, die dieses Echo verhindert.

Arbeitsregisterkarten: mehrere Fälle gleichzeitig offen

Die Konsole öffnete bisher einen Fall zur Zeit, und ein anderer ersetzte den vorigen. Wer viel bearbeitet, hat drei oder vier Fälle laufen (einer wartet auf die Kundschaft, einer auf die Technik, einer wird gerade geschrieben), und jeder Wechsel kostete den Entwurf und die Stelle im Scrollverlauf. Die Leiste der Arbeitsregisterkarten sitzt über dem Gespräch und erscheint, sobald etwas Zweites offen ist.

• **Ein einfacher Klick öffnet eine Vorschau-Registerkarte**, kursiv dargestellt, und die nächste Vorschau nimmt ihren Platz ein. Hineinschreiben oder Anheften macht sie dauerhaft. Sonst würde das Durchsehen von zwanzig Fällen zwanzig Registerkarten öffnen.
• **Derselbe Fall öffnet nie zweimal.** Ein erneuter Klick aktiviert nur die Karte, mit dem Entwurf und der Unterregisterkarte, die Sie dort gelassen haben.
• **Der blaue Punkt zeigt eine geschriebene, nicht gesendete Antwort** in dieser Karte. Das müssen Sie vor dem Schließen sehen, nicht danach.
• **Jede Karte merkt sich ihre Unterregisterkarte** (Gespräch, Verlauf oder Kontext), damit Sie dort weitermachen, wo Sie waren, und nicht am Anfang.
• **Höchstens acht Karten.** Darüber fällt die älteste Karte ohne Entwurf weg; haben alle einen Entwurf, gibt die Grenze nach, denn geschriebene Arbeit zu verlieren ist schlimmer als eine lange Leiste.
• **Das Schließen der aktiven Karte aktiviert die rechte Nachbarin**, und die linke, wenn es rechts keine gibt, so wie im Browser.

**Gespeicherte schließen** schließt alle Karten ohne Entwurf und behält die mit Entwurf: Aufräumen nimmt nie geschriebene Arbeit mit. Die Karten leben in Ihrem eigenen Browser, auf diesem Gerät, also gehören sie Ihnen und nicht dem Team.

Kundenkontext: Gesundheit, Wert, Plan und Servicehistorie

Die Registerkarte Kontext eines Falls öffnet mit einem Block, der beantwortet, bevor Sie eine einzige Zeile schreiben, ob es diesem Kunden gut geht, wie viel er wert ist, in welchem Plan er ist und wie oft er schon enttäuscht wurde. Nichts davon tippt jemand ein: Alles wird aus dem zusammengesetzt, was das Produkt über dieses Konto ohnehin schon führt.

• **Gesundheit** zeigt den Score und, wichtiger noch, **die Faktoren dahinter**. Eine Zahl allein sagt Ihnen nichts, womit Sie arbeiten können; die Faktoren sagen, ob das Problem bei der Nutzung, beim Service, beim Geld oder in der Beziehung liegt.
• **Wert** bringt den gewonnenen Umsatz, den wiederkehrenden Umsatz und die letzte Bewegung, damit eine Erweiterung im vergangenen Monat und eine Reduzierung im vergangenen Monat nicht gleich aussehen.
• **Plan** sagt, welcher Plan, seit wann und wann er verlängert wird, und weist darauf hin, wenn die Verlängerung bereits als gefährdet markiert ist.
• **Servicehistorie** zählt die früheren Fälle, wie viele davon das SLA gerissen haben, die Zufriedenheit genau dieses Kunden und ob gerade ein kritischer Fall offen ist.

Unter dem Block erscheint die gesamte Unterhaltung mit diesem Kontakt in einer einzigen Linie, gleich über welchen Kanal: Chat, SMS, WhatsApp, E-Mail und Fälle gemeinsam, in ihrer Reihenfolge. Es ist dieselbe Historie, die der Kontaktdatensatz zeigt, hereingeholt in die Konsole, damit niemand den Bildschirm wechseln muss, nur um sich zu erinnern, was schon gesagt wurde.

Supervision: derselbe Betrieb, gesehen von denen, die ihn koordinieren

Die Konsole beantwortet „Was mache ich als Nächstes?“ für die Person, die antwortet. Die Supervision beantwortet eine andere Frage, für eine andere Person: Kommt der Betrieb gerade hinterher? Es ist ein eigener Bildschirm, gebaut, um an der Wand offen zu bleiben, und er aktualisiert sich von selbst.

• **Kommt der Betrieb hinterher?** Offene Vorgänge je Warteschlange, wie viele ohne Verantwortlichen sind, wie viele auf uns warten und wie viele in der nächsten Stunde ihre Frist reißen werden. Zu wissen, was gleich reißt, ist nicht dasselbe wie zu wissen, was schon gerissen ist, und das Panel hält beides auseinander.
• **Wer ist überlastet und wer ist frei?** Offene Vorgänge je Person gegen die Obergrenze dieser Person, wer aus der Rotation ausgetreten ist und wer die Warteschlange leitet.
• **Wo ist der Engpass?** Die Warteschlange mit der längsten Wartezeit, der Kanal, der am meisten hereinbringt, und die Warteschlange, aus der niemand etwas ziehen kann, weil sie eine Fähigkeit verlangt, die niemand im Team hat.
• **Was ist in der letzten Stunde passiert?** Der Zuweisungsverlauf lässt sich ohnehin nur ergänzen, also zeigt das Panel ihn einfach.

Die Supervision ist für die, die administrieren, und das ist Absicht: Sie zeigt die Auslastung jeder Person und wer außerhalb der Rotation steht. Menschen zu beobachten ist eine erklärte Handlung der Führung, kein Nebeneffekt davon, einen Bildschirm zu öffnen. Das Panel ist nur zum Lesen, also weist dort nichts neu zu und priorisiert dort nichts um: Es zeigt hin, und die Arbeit geschieht dort, wo sie ohnehin wohnt.

Servicekatalog: ein Schaufenster statt des leeren Falls

Wer heute etwas Internes braucht, öffnet einen leeren Fall und schreibt hin, woran er sich erinnert. Der Katalog ersetzt das durch ein Schaufenster: eine Liste dessen, was man anfordern kann, jeder Eintrag mit seinem eigenen Formular, seiner Warteschlange und seiner Priorität. Die Anforderung öffnet einen echten Fall, bereits ausgefüllt.

1. Unter Einstellungen → Servicekatalog stellt die administrierende Person den Katalog zusammen: Kategorien, Einträge und die Fragen, die jeder Eintrag stellt.
2. Jede Person öffnet denselben Bildschirm, wählt eine Leistung und füllt deren Formular aus.
3. Das System öffnet einen Fall in der Warteschlange des Eintrags, mit dessen Priorität und den Antworten darin, in demselben Format, das das Portal schon verwendet.
4. Verlangt der Eintrag eine Genehmigung, wird die Anfrage sofort geöffnet und die offene Genehmigung blockiert ihre Lösung: Niemand schließt sie, bevor jemand entschieden hat.

• **Einen Eintrag zu deaktivieren storniert nicht, was bereits angefordert wurde.** Es heißt „fordert das nicht mehr an“, niemals „storniert, was gerade läuft“: Bereits offene Fälle bleiben offen, mit derselben Warteschlange und derselben Frist.
• **Ein Eintrag, der schon einmal angefordert wurde, lässt sich nicht löschen, nur deaktivieren.** Ihn zu löschen würde die Historie über das lügen lassen, was angefordert wurde.
• **Die Anforderung friert eine Momentaufnahme des Formulars ein.** Ändern Sie die Fragen später, zeigt die alte Anforderung weiterhin die Fragen, die diese Person tatsächlich beantwortet hat.
• **Der Status einer Anforderung ist keine Kopie.** Er wird jedes Mal aus der Genehmigung selbst gelesen und kann deshalb nie von dem abweichen, was das Genehmigungssystem an anderer Stelle entschieden hat.

Servicekatalog: die Anforderung erfüllen

Ein Katalogeintrag kann einen Erfüllungsplan tragen: das, was passieren muss, nachdem jemand den Service angefordert hat, und in welcher Reihenfolge. Jeder Schritt wird zu einer **echten Aufgabe**, mit zuständiger Person, Fälligkeit, Erinnerung und einem Platz in der täglichen Aufgabenliste derjenigen Person, die sie erledigen muss, und die Abhängigkeit zwischen den Schritten ist dieselbe, die Aufgaben ohnehin schon haben. Der Plan wird in die Anforderung eingefroren, wenn die Erfüllung **startet**, nicht in dem Moment, in dem der Service angefordert wird: Den Eintrag später zu bearbeiten schreibt nie eine bereits laufende Anforderung um, und die neue Fassung gilt ab dem nächsten Start.

Wer die Arbeit koordiniert, bekommt die Erfüllungswarteschlange: Was offen ist, bei wem und seit wann. Eine genehmigte Anforderung, die noch niemand gestartet hat, steht **ganz oben**, mit ihrem Alter in Sichtweite, denn Genehmigen startet nichts, jemand muss den Plan noch zum Laufen bringen. Ein Eintrag, der auf keine Genehmigung wartet, startet, sobald er angefordert wird.

1. Zeichnen Sie den Plan im Katalogeintrag: Betreff, Aufgabenart, Fälligkeit in Tagen ab dem Start, wer sie bekommt und, wo es darauf ankommt, der vorherige Schritt, von dem sie abhängt.
2. Fordert jemand den Service an, öffnet sich das Ticket wie eh und je. Verlangt der Eintrag eine Genehmigung, wartet die Erfüllung auf die Entscheidung; gibt es keine Genehmigung abzuwarten, startet sie sofort.
3. Beim Start der Erfüllung wird der Plan in die Anforderung eingefroren, und die Aufgaben entstehen in der Reihenfolge der Abhängigkeiten, jede mit zuständiger Person und Fälligkeit.
4. Das Anforderungspanel im Ticket zeigt jeden Schritt, bei wem er liegt, die Fälligkeit und was bereits erledigt ist. Die Schritte tauchen auch im Verlauf des Tickets auf, weil sie ganz normale Aufgaben sind, die am Fall hängen.
5. Klicken Sie auf „Geliefert“, wenn der Service die Person tatsächlich erreicht hat. Ein noch offener Pflichtschritt blockiert das, mit dem Grund in Sichtweite; ein als nicht erforderlich markierter Schritt blockiert nie.
6. Aus Versehen markiert? Nehmen Sie die Lieferung mit einer Notiz zurück. Das ist ein neuer Eintrag: Die frühere Lieferung bleibt im Verlauf, nichts wird gelöscht.

Geräte des Kunden: In diesem Fall geht es um genau dieses Gerät

Ein Ticket kann jetzt auf das **Gerät** des Kunden zeigen, auf die installierte Einheit mit ihrer Seriennummer, und nicht mehr nur auf das verkaufte Produktmodell. Im Ticket wählen Sie es aus der installierten Basis des Kunden aus und suchen dabei über die Seriennummer, denn so benennt der Kunde es am Telefon. Verknüpfen lässt sich nur ein Gerät, das dem Kunden dieses Tickets gehört, und von da an erzählt die Historie des Geräts selbst den Serviceverlauf: verknüpfte, wieder gelöste und abgeschlossene Fälle stehen auf derselben Zeitleiste wie die Installation, die Standortwechsel und die Wartungen.

Die Ausfallzeit wird von **Menschen** erfasst, oder direkt aus dem Ticket heraus. Es gibt hier keine Telemetrie und kein Maschinensignal, also sind Verfügbarkeit, MTTR und MTBF genau so viel wert wie die Disziplin derer, die sie erfassen. Der Bildschirm sagt das laut, statt die Zahl zu schmücken.

• Garantie und Abdeckung: Das Garantiekennzeichen (in Garantie, läuft ab, abgelaufen) und der Servicevertrag stehen da, bevor Sie gegenüber dem Kunden den Mund aufmachen.
• Standort: Das Gerät zu bewegen hält fest, wohin es ging, die Standorthistorie ist also die Lesart dieser Bewegungen und kein einzelnes Feld, das die Vergangenheit vergisst.
• Austausch mit Abstammung: Ein Austausch mustert die alte Einheit aus und legt die neue an, die Konto, Vertrag und Standort erbt, mit je einem Ereignis auf beiden Seiten, das auf die andere zeigt.
• Lebenszyklus: aktiv, in Wartung, in RMA, ausgemustert und abgeschrieben. Abgeschrieben kommt nicht zurück, denn die Abschreibung ist eine buchhalterische Tatsache; der Weg zurück führt über ein neues Gerät mit der Abstammung des alten.
• Ausfallzeit: eine Störung öffnen und schließen, geplant oder ungeplant. Dasselbe Gerät fällt nie zweimal gleichzeitig aus, und überlappende Störungen werden zusammengeführt, bevor summiert wird, damit die Verfügbarkeit nie negativ wird.
• Verfügbarkeit: der Prozentsatz im Zeitfenster, mit dem geplanten Anteil getrennt vom ungeplanten, denn ein mit dem Kunden vereinbartes Wartungsfenster ist kein gebrochenes Versprechen. MTTR und MTBF bleiben ohne genügend Messwerte leer.
• Risiko und nächste Maßnahme: Kritikalität, Alter, wiederholte Ausfälle, Abdeckung und gemessene Verfügbarkeit ergeben zusammen einen erklärbaren Wert, und die Logik sagt dazu, was sie mangels Daten annehmen musste.

Wissensdatenbank: Verantwortung, Prüfung und Nutzung

Die Wissensdatenbank hat die Ebene bekommen, die beantwortet, wer für welchen Artikel geradesteht und ob man ihm noch trauen kann: eine verantwortliche Person, eine prüfende Person, ein Prüfzyklus in Tagen und daraus der Artikel, dessen **Prüfung überfällig** ist. Die Governance-Übersicht ist live, sie wird beim Öffnen berechnet und hängt damit nie davon ab, ob der nächtliche Lauf durchgelaufen ist. In die Pflicht genommen wird nur der veröffentlichte Artikel: Ein Entwurf wird noch geschrieben, und ein archivierter ist aus dem Verkehr.

Sichtbarkeit heißt nicht mehr nur veröffentlicht oder nicht. Jeder Artikel hat jetzt ein Publikum: **extern** ist das, was Help Center und Portal jedem mit dem Link zeigen, und **intern** verlässt das CRM nie. Jeder Artikel entsteht als extern, genau so, wie er sich vorher verhalten hat, es ändert sich also nichts, bis Sie es anders entscheiden.

• Verantwortliche und prüfende Person sind Menschen aus Ihrem Team, je Artikel gesetzt. Ohne verantwortliche Person wird der Artikel in der Übersicht markiert, und dort löst sich diese Lücke auch.
• Prüfzyklus in Tagen: Die nächste Prüfung ist die letzte Prüfung plus der Zyklus. Ein Artikel ohne Zyklus wird nie fällig, und niemand wird deswegen behelligt.
• Der Hinweis auf die überfällige Prüfung geht an die **verantwortliche Person** des Artikels, einmal je Fälligkeit. Ein Artikel ohne verantwortliche Person benachrichtigt niemanden, denn die herrenlose Hälfte der Datenbank täglich in die Glocke der Administration zu kippen bringt den Leuten bei, die Glocke zu ignorieren.
• Archivieren nimmt einen Artikel mit Autor, Datum und Prüfspur aus dem Verkehr, statt dass jemand still ein Statusfeld bearbeitet. Aus dem Archiv geholt landet er wieder im Entwurf, nie direkt auf Sendung.
• KI-Entwurf aus gelösten Tickets: Wählen Sie bis zu fünf abgeschlossene Fälle, zeigen Sie bei Bedarf auf eine Lücke, und der Assistent schreibt einen wiederverwendbaren Artikel. Er **entsteht immer als Entwurf** und geht in dieselbe Prüfschleife wie alles von Hand Geschriebene: Die KI schlägt vor, ein Mensch gibt frei. Verwendet werden nur gelöste Tickets, denn ein offener Fall hat noch keine Antwort.
• Nutzung je Artikel: wie viele Besuche jeden Artikel geöffnet haben, durch welche Tür, und welche veröffentlichten Artikel im Zeitraum niemand gelesen hat, also der Teil der Datenbank, der nicht arbeitet.

Self-Service: der Assistent und die Deflection-Rate

Die öffentliche Wissensdatenbank hat jetzt einen Assistenten. Er antwortet **ausschließlich** verankert in Ihren veröffentlichten Artikeln und zeigt die Quellen, die er verwendet hat, damit wer eine erzeugte Antwort liest nachsehen kann, woher sie stammt. Findet er nichts, sagt er das und führt zum Ticketformular, und die unbeantwortete Frage wird als Abdeckungslücke festgehalten. Er füllt die Stille nie mit einem erfundenen Schritt, und wenn keine KI eingerichtet ist, zeigt er die gefundenen Artikel, statt sich außer Betrieb zu stellen.

Genau das macht Deflection messbar, und die Definition ist mit Absicht streng: Ein **vermiedenes Ticket ist eine ausdrückliche Aussage** von jemandem, der auf dem Weg war, einen Fall zu eröffnen, und aufgegeben hat, nachdem er eine Antwort oder einen vorgeschlagenen Artikel bekommen und angeklickt hat, dass es das Problem gelöst hat. Sonst zählt nichts.

• Einen Artikel zu lesen zählt nicht. Wer liest, vergleicht vielleicht, recherchiert, oder liest den falschen Artikel auf dem Weg zu dem Ticket, das er ohnehin eröffnet.
• Eine Suche ohne Ausgang zählt nicht. Den Tab zu schließen ist kein Erfolg.
• Das Ticket schlägt die Aussage: Hat die Person gesagt, es sei gelöst, und im selben Besuch einen Fall eröffnet, zählt der Besuch als Ticket. Lieber messen wir zu wenig.
• Ein Besuch, der nichts entschieden hat, bleibt ganz aus der Rate heraus, weder oben noch unten, und wird getrennt als unentschieden ausgewiesen.
• Die Rate ist der Anteil der Besuche, die **etwas entschieden haben** und sich gegen ein Ticket entschieden haben. Ohne eine einzige Entscheidung im Zeitraum bleibt die Rate leer und nie 0 %, denn nicht zu wissen und null Prozent sind verschiedene Antworten.
• Der Trichter (Suchen, Fragen, beantwortete Fragen) misst Reichweite, nicht Ergebnis, und nichts davon geht in die Rate ein.

Service-Analysen: fertige Berichte, Befunde und Prognose

Die Registerkarte „Analysen“ der Ticketkonsole beantwortet, was bisher kein Bildschirm beantwortet hat: wie lange die Warteschlange schon steht, wie viel von jeder versprochenen Etappe gehalten wurde, wie viel eskaliert ist, was Telefonie, Bot und Messaging getrieben haben, was Störungen an Tickets gekostet haben, wohin sich das Aufkommen bewegt und, am Ende, was dagegen zu tun ist. Jede Zahl kommt bereits vom Server berechnet, es können also nicht zwei Bildschirme still über dieselbe Größe uneins sein.

Zwei Lesarten, die gleich aussehen und es nicht sind: **Das Alter läuft nach der Uhr** (die Kalenderzeit seit der Erstellung des Tickets) und **die Frist läuft nach den Geschäftszeiten** (das SLA-Versprechen, mit abgezogenen Pausen). Sie heißen mit Absicht verschieden. Sie zu vermischen gäbe zwei Zahlen mit demselben Etikett und keine Möglichkeit zu erkennen, welche davon gerissen ist.

• Fertige Berichte: Ein Klick macht aus einer Vorlage Ihren eigenen Bericht, benannt in Ihrer Sprache. Von da an ist er ein ganz normaler Bericht, bearbeitbar, teilbar, exportierbar und planbar wie jeder andere, ohne eine eigene Maschinerie dahinter.
• Befunde: SLA unter dem Ziel, es kommt mehr herein als heraus, eine alternde Warteschlange, Wiedereröffnungen, Eskalation, Wissenslücken. Jeder Befund kommt mit den Zahlen, die ihn stützen, einer wahrscheinlichen Ursache und einer Maßnahme, nach Gewicht sortiert.
• Einhaltung nach Etappe: Erstantwort, Folgeantwort und Lösung, und nicht die Lösung allein. Folgeantwort ist jedes Mal, wenn der Kunde zurückkommt, nachdem er bereits einmal beantwortet wurde, und in die Zählung kommt nur ein Fall, der tatsächlich eine Frist hatte.
• Alterung des Backlogs in Bändern (unter einem Tag, ein bis drei Tage, drei bis sieben, über eine Woche), insgesamt, je Warteschlange und je Agent, mit dem ältesten Fall in Sichtweite.
• Der Bot hat drei Ausgänge, nicht zwei: ohne Menschen erledigt, an einen Menschen übergeben und **um einen Menschen gebeten, und niemand kam**, was eine verlassene Warteschlange ist und sich früher in der Zahl der erledigten versteckte.
• Telefonie, Messaging und Störungen bekommen je eine eigene Auswertung, denn ein WhatsApp-Gespräch ist kein Ticket, und eine Störung misst sich daran, was sie an Fällen gekostet hat, und an der Ursache, die immer wiederkommt.
• Prognose des Aufkommens: Trend plus ein Index nach Wochentag, damit der Samstag nicht projiziert wird, als wäre er ein Dienstag.

KI, die im Ticket handelt, unter einer Richtlinie

Die KI hat bereits jedes Ticket gelesen (Kategorie, Dringlichkeit, Stimmung, Zusammenfassung), und niemand hat es genutzt. Jetzt kann sie Kategorie und Priorität in das Ticket **schreiben**, aber nur unter einer Richtlinie, die der Arbeitsbereich festlegt, und sie ist **standardmäßig ausgeschaltet**: Nichts ändert sich, bis die Administration sie unter **Einstellungen → Service-KI** einschaltet. Feld für Feld wählen Sie zwischen **Nichts tun**, **Vorschlagen (eine Person bestätigt)** und **Schreiben, wenn sicher**. Geschrieben wird nur oberhalb einer Konfidenzschwelle, die Sie festlegen (50 % bis 100 %, standardmäßig 80 %); darunter wird derselbe Vorschlag zu einer Empfehlung, die sich mit einem Klick übernehmen lässt.

In der Konsole listet der Kasten **KI-Vorschläge** auf, was wartet: den vorgeschlagenen Wert mit seiner Konfidenz und dem Grund, warum er nicht geschrieben wurde (Richtlinie sagt nur vorschlagen, unterhalb der Schwelle, eine Person hatte bereits einen Wert gewählt, Tageslimit erreicht), mit **Übernehmen** und **Verwerfen**. Was die Richtlinie von selbst geschrieben hat, bleibt im Verlauf des Kastens als von der Richtlinie geschrieben sichtbar, damit die bearbeitende Person weiß, dass die Kategorie nicht von ihr stammt. **Jetzt mit KI klassifizieren** führt dieselbe Richtlinie von Hand aus. Der Kasten verschwindet für einen Arbeitsbereich, der die Richtlinie nicht eingeschaltet hat und keinen Vorschlag hat.

• Die KI klassifiziert anhand **Ihrer eigenen** Kategorie- und Prioritätslisten. Ein Wert, der nicht zu Ihren Optionen gehört, wird nie geschrieben, und ohne hinterlegte Optionen für ein Feld bleibt sie still, statt eine zu erfinden.
• Ein von einer Person gewählter Wert wird nicht überschrieben. Standardmäßig füllt der automatische Modus nur, was leer ist oder noch auf dem Formularstandard steht; eine menschliche Wahl zu ersetzen verlangt die ausdrückliche Option **Der KI erlauben, einen von einer Person gewählten Wert zu ersetzen**.
• Ein Antwortentwurf wird **nie gesendet**. Ihn anzunehmen legt ihn mit **Im Editor verwenden** in den Editor; Prüfen, Bearbeiten und Senden bleiben bei Ihnen. Auch das Lösen und Schließen eines Tickets ist nie automatisch: Dafür gibt es keinen Modus, nirgends.
• Jeder automatische Schreibvorgang zählt gegen das tägliche Aktionslimit, das mit dem Agenten geteilt wird (**Einstellungen → KI**, Autonomie des Agenten). Am Limit geht die KI wieder dazu über, nur vorzuschlagen, und sagt das im Kasten und auf der Seite der Richtlinie, mit den Zahlen des Tages: geschrieben, vorgeschlagen, vom Limit zurückgehalten, wartet auf eine Person.
• Alles hinterlässt eine Spur: jeder automatische Schreibvorgang im Aktionsbuch des Agenten, jeder KI-Aufruf im KI-Prüfprotokoll, wenn dieses Protokoll eingeschaltet ist, und die Änderung der Richtlinie selbst im Prüfprotokoll.
• **Beim Erstellen eines Tickets ausführen** wendet die Richtlinie ohne konfigurierte Automatisierung an. Ist das eingeschaltet, wartet das Erstellen eines Tickets über den Bildschirm ein paar Sekunden auf die KI, bevor das Ticket erscheint; ist die KI nicht verfügbar (kein Schlüssel, Ausgabenlimit, Anbieter ausgefallen), wird das Ticket trotzdem erstellt, ohne dass etwas geschrieben wird.
• Ticket-Automatisierungen und Zeitregeln haben zwei Aktionen dazubekommen: **Mit KI klassifizieren (gemäß der Service-KI-Richtlinie)** und **Antwort mit KI entwerfen (wird nie gesendet)**. Eine Regel, die zuerst die Kategorie setzt und dann die KI fragt, erlebt nicht, dass die KI sie rückgängig macht.
• Dieselbe Analyse desselben Textes erzeugt nie zwei Vorschläge und zählt nie zweimal gegen das Limit; einen Durchlauf zu wiederholen kostet nichts.

Außendienst direkt aus dem Ticket

Ein Ticket, das einen Vor-Ort-Besuch braucht, wird nicht mehr auf einem anderen Bildschirm neu eingetippt. Mit eingeschalteter Branchenlösung Außendienst öffnet der Kasten **Außendienst** in der Konsole den Außendienstauftrag direkt aus dem Ticket, plant den Besuch und zeigt der bearbeitenden Person, was der Kunde am Telefon fragt: nächster Besuch, ob er überfällig ist, letzter Besuch, Techniker, Gerät. Alles wird live aus dem Auftrag, seinen Besuchen und seinem Statusverlauf gelesen, sodass eine Änderung auf der Dispositionstafel genau das ist, was das Ticket beim nächsten Öffnen zeigt. Der Auftrag übernimmt Betreff und Beschreibung des Tickets als Problem und die Ticketpriorität, übersetzt in die des Auftrags (kritisch wird dringend, hoch bleibt hoch, mittel normal, niedrig niedrig).

**Außendienstauftrag öffnen** fragt nach dem **Objekt**, das Pflicht ist, weil das Ticket die Adresse des Besuchs nicht kennt: Die Objekte des Kunden stehen zuerst und markiert, ein Kunde mit nur einem Objekt hat es vorausgewählt, und ein Ticket ohne Kontakt oder Unternehmen durchsucht den gesamten Bestand nach Name, Adresse oder Postleitzahl (die ersten 50, mit dem Hinweis, die Suche einzugrenzen). Zeigt das Ticket auf eine Anlage, deren Seriennummer genau einem Gerät an diesem Objekt entspricht, wird das Gerät mit einem Kontrollkästchen **vorgeschlagen**, nie für Sie ausgewählt. Auftragsart (standardmäßig Reparatur), Techniker und Ankunftsfenster sind optional; mit Fenster wird der erste Besuch sofort geplant und erscheint auf der Dispositionstafel; ohne Fenster bleibt der Auftrag ein Entwurf, noch ohne Besuch.

• **Besuch planen** fügt demselben Auftrag von der Konsole aus einen Besuch hinzu: Ein erneuter Termin ist Besuch 2, 3 und so weiter, nie ein zweiter Auftrag. Ein Ticket hat höchstens einen Auftrag, und ein zweiter Klick auf Öffnen antwortet, dass er bereits existiert.
• Ankunftsfenster und Techniker des Auftrags selbst werden nur gefüllt, wenn sie leer waren: Ein zweiter Besuch schreibt nicht um, was für den ersten vereinbart wurde.
• **Besuch überfällig** erscheint, wenn das Fenster begonnen hat und der Besuch immer noch nur geplant ist, also niemand losgefahren ist. Die Auswahl für den Statuswechsel bietet nur die Übergänge an, die der Zustandsautomat der Branchenlösung vom aktuellen Status aus akzeptiert.
• Wenn der Außendienst **abgeschlossen** ist, **nicht abgeschlossen werden konnte** oder **storniert** wurde, wird die für das Ticket verantwortliche Person in ihrer Sprache mit einem Link zur Konsole benachrichtigt, egal ob die Änderung aus der Konsole, vom Bildschirm der Branchenlösung oder aus der App kam. Disponiert, unterwegs und wartet auf Ersatzteil bleiben im Kasten sichtbar, ohne bei irgendjemandem zu klingeln.
• **Der Ticketstatus ändert sich nie von selbst**, wenn der Außendienst fertig ist. Mit dem Kunden zu bestätigen und das Ticket zu lösen ist die Entscheidung der Person, die es bearbeitet.
• **Verknüpfung aufheben** löst die Verbindung zwischen Ticket und Auftrag und sonst nichts: Der Auftrag lebt in der Branchenlösung weiter, mit seiner eigenen Spur. Ihn zu stornieren ist ein Übergang der Branchenlösung, der dort erfolgt.
• Eine Erinnerungsaufgabe zum Besuchsdatum ist optional und nutzt das Aktivitätenmodul wieder; sie erscheint in der Zeitleiste des Tickets und in der Aufgabenliste des Technikers, oder in der der für das Ticket verantwortlichen Person, wenn es keinen Techniker gibt.
• Ist die Branchenlösung ausgeschaltet, sagt der Kasten das und verweist auf **Einstellungen · Verticals**, statt einen Button zu zeigen, der scheitern würde. Er bietet den leichten Weg an, den jeder Arbeitsbereich hat, **Stattdessen einen Serviceauftrag öffnen**, und zeigt diesen Auftrag und seine Termine, wenn einer existiert.

Wo Sie das einrichten: **Einstellungen → Textbausteine** für die fertigen Formulierungen, **Einstellungen → E-Mail-Vorlagen für Tickets** für die transaktionalen Texte und **Einstellungen → Fähigkeiten** dafür, wer was kann und was jede Warteschlange verlangt. Swarm, Follow-up und Arbeitsregisterkarten brauchen keine Einrichtung: sie sind bereits in der Konsole.

Diesen Artikel im System öffnen →