Kundensupport-SOP: So schreiben Sie eine, der Agents und KI gleichermaßen folgen

Kurzfassung

Eine Kundensupport-SOP ist ein schrittweises Verfahren für eine Ticketart: wann es gilt, was zu prüfen ist, was in jedem Fall zu tun ist und wann eskaliert wird. Die funktionierenden sind kurz, als Wenn-dann-Schritte geschrieben, mit dem Makro verlinkt und gehören einer namentlich benannten Person mit Prüfdatum. Die gescheiterten sind lange Dokumente, die niemand öffnet, bis der Kunde schon verärgert ist.

Die große Veränderung 2026: Ihre SOP hat jetzt zwei Leser, die neue Kollegin und den KI-Agent. Zendesk, Gorgias, Freshdesk, Ada und Decagon verlangen alle Verfahren, die so geschrieben sind, wie Sie sie einem neuen Agent erklären würden. Schreiben Sie die SOP einmal in diesem Format, und Sie haben beide geschult.

Wenn Ihre SOPs über Notion, Loom-Videos und alte Makros verstreut sind, liest eesel alles zusammen mit Ihren früheren Tickets und entwirft Antworten, die denselben Schritten folgen. So taucht eine Korrektur an der SOP in der nächsten Antwort auf statt erst in der nächsten Schulung.

Was ist eine Kundensupport-SOP?

Eine Kundensupport-SOP (Standard Operating Procedure, Standardarbeitsanweisung) ist eine schriftliche Schrittfolge, um eine wiederkehrende Situation jedes Mal gleich zu bearbeiten. „So bearbeiten wir eine Erstattungsanfrage“ ist eine SOP. „Erstattungen sind innerhalb von 30 Tagen möglich“ ist eine Richtlinie. „Hallo Sam, ich habe Ihre Erstattung veranlasst“ ist ein Makro.

Ich baue bei eesel KI-Agents, und die Anweisungen, denen diese Agents folgen, sind ehrlich gesagt nichts anderes als SOPs mit strengerer Formatierung. Ich sehe mir also viele Support-Verfahren an, und die häufigste Verwechslung ist, dass alle drei Ebenen in einem Dokument zusammengeworfen werden. Die Richtlinie ändert sich einmal im Jahr, die Schritte jedes Quartal und der Wortlaut jede Woche. Steckt alles in einem Dokument, gefährdet jede Änderung die anderen beiden.

So verteilen sich die Ebenen in der Praxis:

Die vierte Zeile ist neu. Vor ein paar Jahren war die SOP nur für Menschen. Heute speisen dieselben Schritte den KI-Agent, deshalb ist das Format wichtiger als früher.

Warum die meisten Support-SOPs ungelesen bleiben

SOPs zu schreiben ist der einfache Teil. Schwierig ist, dass sie niemand liest und sie veralten. Ein Hacker-News-Kommentator hat die Ökonomie besser formuliert als jedes Betriebsbuch, das ich kenne:

"The TCO of knowledge is dominated by the maintenance cost, not the creation cost... The org must make it someone's job to grow, weed, and maintain these gardens."

kjellsbells, Hacker News

Dieselben drei Fehlerbilder sehe ich bei fast jedem eesel-Rollout:

1. Die SOP existiert, aber niemand weiß davon. Ein Entwickler, der in ein DSGVO-Ticket hineingezogen wurde, beschrieb, dass "we already have a canned response to these requests - the person on the support team is a new hire and was unaware" (Hacker News). Das Verfahren war in Ordnung. Nur hat es im entscheidenden Moment niemand sichtbar gemacht.
2. Das Wissen ist verstreut. Eine DTC-Nahrungsergänzungsmarke, mit der ich gesprochen habe und die etwa 7.000 Gorgias-Tickets im Monat bearbeitet, wollte die Hälfte ihres E-Mail-Volumens von KI erledigen lassen. Ihre Verfahren lagen in ClickUp-SOPs, nicht transkribierten Loom-Videos und einem langen Schwanz veralteter Makros. Bevor eine KI dem Prozess folgen konnte, musste ihn jemand erst finden.
3. Das Wissen geht mit den Menschen. Ein IT-Dienstleister der öffentlichen Hand auf Freshdesk, der rund 3.000 komplexe ERP-Tickets im Monat bearbeitet, sagte dem eesel-Vertrieb, er verliere in dem Jahr zwei erfahrene Agents und wolle deren Know-how vor dem Abschied sichern. Das ist implizites Wissen in Reinform: echte Verfahren, die nie aufgeschrieben wurden, weil zwei Leute sie einfach kannten.

Und wenn Verfahren schlecht geschrieben sind, können sie alles noch verschlimmern. Ein ehemaliger eBay-Support-Mitarbeiter erinnerte sich, "4 concurrent chats" zu bearbeiten und "offering pre-programmed macros often pointing to terribly written documentation the person had already read and was confused about" (Hacker News). Eine schlechte SOP hilft nicht nur nicht. Sie schickt den Kunden zurück auf dieselbe Seite, die ihn verwirrt hat.

Die Lösung für alle drei Fälle ist nicht mehr Dokumentation. Es sind kürzere Verfahren, die im Ticket selbst auftauchen und für die jeweils eine Person verantwortlich ist, dass sie stimmen.

Welche Support-Prozesse brauchen zuerst eine SOP?

Nicht jede Ticketart braucht ein schriftliches Verfahren. Passwort-Resets über einen Self-Service-Ablauf brauchen keines. Ich priorisiere einen Prozess für eine SOP, wenn er bei mindestens zwei dieser Kriterien hoch punktet:

• Volumen. Er kommt täglich vor, kleine Abweichungen summieren sich also.
• Fehlerkosten. Es fließt Geld, Daten werden offengelegt oder eine gesetzliche Frist gilt.
• Ermessensentscheidungen. Agents müssen etwas entscheiden, und zwei Agents würden unterschiedlich entscheiden.
• Teamübergreifende Übergaben. Er braucht Entwicklung, Buchhaltung oder Recht, sodass der Eskalationsweg ausdrücklich festgelegt sein muss.

In den meisten Teams ergibt das dieselben ersten fünf: Erstattungen und Rücksendungen, Kontozugang und Identitätsprüfungen, Ausfälle und Störungen, Anfragen zu Datenlöschung oder -export sowie Beschwerden, die eine Führungskraft brauchen. Fangen Sie dort an. Ein Team mit fünf soliden SOPs ist besser als eines mit fünfzig veralteten.

Auch brauchen nicht alle Prozesse dasselbe Format. Mit dieser Übersicht entscheide ich:

So schreiben Sie eine Kundensupport-SOP

So gehe ich vor, egal ob der Leser eine neue Kollegin oder ein KI-Agent ist. Rechnen Sie bei den ersten fünf mit etwa einer Stunde pro SOP.

1. Beginnen Sie mit 20 echten Tickets, nicht aus dem Gedächtnis

Ziehen Sie 20 aktuelle Tickets einer Art und lesen Sie, wie Ihre besten Agents sie tatsächlich gelöst haben. Sie finden Schritte, die niemand aufgeschrieben hätte („zuerst prüfen, ob mit Geschenkkarte bezahlt wurde“), und Ausnahmen, die wöchentlich vorkommen. Aus dem Gedächtnis schreiben Sie den Prozess, von dem Sie glauben, dass Sie ihn leben. Die Tickets zeigen den, den Sie wirklich leben. Wenn Sie schon eine Ticketanalyse betreiben, ist das eine Aufgabe von 20 Minuten.

2. Schreiben Sie den Auslöser in den Worten des Kunden

Die erste Zeile beantwortet „Wann gilt diese SOP?“. Formulieren Sie sie so, wie Kunden es sagen, nicht mit Ihrer internen Bezeichnung: „Kunde möchte sein Geld zurück, sagt, er sei doppelt belastet worden, oder will kündigen und erstattet bekommen.“ Für KI gilt das doppelt. Die Zendesk-Dokumentation weist darauf hin, dass ein auf Englisch zuverlässig erkanntes Verfahren auf Französisch danebenliegen kann, und die Lösung ist, den Anwendungsfall mit den Formulierungen der Kunden zu erweitern.

3. Eine Aktion pro Schritt, jedes Wenn-dann ausformuliert

Das ist der größte Qualitätssprung. Zendesk veröffentlicht Schreibregeln für Verfahren, die ich auch jedem menschlichen Autor geben würde: eine Aktion pro Schritt, ausdrückliche „Wenn ... dann ...“-Bedingungen, konkrete Sprache („Bitten Sie den Kunden um seine 10-stellige Kontonummer“, nicht „Kontoinfos anfordern“) und immer derselbe Begriff („Premium-Tarif“, nie mal „Gold-Tarif“). Adas Leitfaden ergänzt, dass jede Verzweigung ein Sonst braucht und jeder Ablauf einen ausdrücklichen Ausgang (Ada-Dokumentation).

Enthält ein Schritt das Wort „und“, sind es wahrscheinlich zwei Schritte.

4. Schreiben Sie die Ausnahmen auf und wer sie genehmigen darf

Die meisten SOPs beschreiben den Idealfall und hören auf. Die Tickets, die wehtun, sind die Ausnahmen. Ein Hacker-News-Kommentator beschrieb einen Agent, der zustimmte, dass man zu Unrecht belastet worden war, aber "could not refund me on the spot because of protocol" (Hacker News). Die Lösung ist nicht, das Protokoll zu streichen. Sie ist, den Ausnahmeweg in die SOP zu schreiben: wer genehmigen darf, bis zu welchem Betrag und wie schnell. Nutzen Sie Zahlen. „Ab 500 $ geht es an die Teamleitung“ lässt sich befolgen. „Große Erstattungen brauchen Genehmigung“ nicht.

5. Verlinken Sie das Makro, fügen Sie den Wortlaut nicht ein

Legen Sie die Antwort in ein Makro und verlinken Sie es aus dem Schritt, der es nutzt. Ändert das Marketing den Ton oder die Rechtsabteilung einen Satz, bearbeiten Sie ein Makro, und jede SOP, die darauf zeigt, bleibt korrekt. Zendesk begrenzt Konten auf 5.000 geteilte Makros und Gorgias auf 5.000 Makros, Sie kommen also nicht an die Grenze, gehen aber unter, wenn jede SOP eigene Kopien erzeugt. Mein Leitfaden zu persönlichen vs. geteilten Makros behandelt die Zendesk-Seite.

6. Benennen Sie einen Verantwortlichen und ein Prüfdatum

Jede SOP bekommt oben den Namen einer Person und ein „Prüfen bis“-Datum. Kein Team. Eine Person. Ohne das wird die SOP zu dem, was ein Kommentator "backwaters of slowly rotting stuff" nannte (Hacker News).

7. Testen Sie sie mit jemandem ohne Vorwissen

Geben Sie die SOP der neuesten Person im Team oder jemandem aus einer anderen Abteilung und beobachten Sie, wie sie damit ein echtes Ticket bearbeitet. Ada empfiehlt dasselbe für KI-Verfahren: Lassen Sie jemanden "with limited context" gegenlesen (Ada-Dokumentation). Jede Frage, die gestellt wird, ist eine fehlende Zeile. Es ist außerdem der günstigste Gewinn bei der Einarbeitungszeit, den ich kenne.

Vorlage für eine Kundensupport-SOP

Das ist die Vorlage, die ich nutze. Kopieren Sie sie in Ihre Wissensdatenbank und füllen Sie je Prozess eine aus.

SOP: [Process name]
Owner: [One person]          Review by: [Date, 90 days out]
Applies to: [Channels, regions, plans]

WHEN (trigger, in the customer's words)
- [How customers phrase it, 2 to 4 examples]

DON'T USE WHEN
- [Look-alike requests that need a different SOP]

CHECK FIRST
- [Field or system to look at, e.g. order date, plan, payment method]

STEPS
1. [One action]
2. IF [condition] THEN [action + macro link]
3. ELSE [action + macro link]

EXCEPTIONS AND APPROVALS
- [Situation] -> [Who approves] up to [$ / limit], within [time]

ESCALATE TO
- [Team or person], via [tag / group / channel], when [trigger]

TAGS / FIELDS TO SET
- [Tag names, custom fields, status]

LINKED MACROS
- [Macro name], [Macro name]

CHANGE LOG
- [Date] [What changed] [Who]

Der Block „Nicht verwenden, wenn“ ist davon abgeschaut, wie Decagon die Verfahren seiner Agents gliedert: jedes besteht aus einer Beschreibung, "When to use" und "When to not use".

Ein ausgefülltes Beispiel: Erstattungsanfrage

So sieht die Vorlage für einen typischen E-Commerce-Shop ausgefüllt aus. Setzen Sie Ihre eigenen Zahlen ein.

Diese eine Tabelle beantwortet jede Frage, die eine neue Kollegin sonst in Slack stellen würde. Und sie ist fast genau das, was ein KI-Agent auch braucht, womit wir bei dem Teil sind, bei dem die meisten SOP-Leitfäden noch nicht angekommen sind. Zur KI-Seite von Erstattungen geht mein Beitrag zu KI bei Erstattungsanfragen tiefer.

Ihre SOP ist jetzt auch die Anweisung eines KI-Agents

Jede große KI-Support-Plattform, die ich mir angesehen habe, verlangt heute Verfahren, die so geschrieben sind, wie Sie eine SOP für einen Menschen schreiben würden. Das ist der Wandel: Eine gut geschriebene SOP sind die Trainingsdaten Ihres KI-Agents, und eine vage ist der Grund, warum Bots selbstsicher danebenliegen.

Zendesk ist das klarste Beispiel. Sie beschreiben Ihre Geschäftsrichtlinien, und es erzeugt eine Verfahrenskarte, der der KI-Agent folgt; seit Mai 2026 sind mehrstufige Verfahren in den Suite- und Support-Tarifen enthalten. Der Editor fordert Sie buchstäblich auf, die Schritte zu beschreiben "as you would with a human agent". Wenn Sie Ihre SOP bereits im Format aus Schritt 3 geschrieben haben, können Sie sie einfügen. Das größere Setup habe ich in meiner Aufschlüsselung zu Zendesk-KI-Agents behandelt.

Gorgias teilt es in zwei. Guidance enthält Ihre Richtlinien, bis zu 100 Einträge pro Shop mit je 30.000 Zeichen, und Gorgias sagt "among knowledge types, guidance carries the most weight" (Gorgias-Dokumentation). Skills enthalten den Schritt-für-Schritt-Teil, und Aktionen wie das Stornieren einer Bestellung laufen nur innerhalb eines Skills oder einer Guidance (Gorgias-Skills-Dokumentation). Gorgias warnt außerdem, dass ein Rückgabeartikel mit 30 Tagen und eine Guidance mit 14 Tagen widersprüchliche Antworten erzeugen, also das Ebenenproblem von vorhin in KI-Form.

Freshdesk sagt es offen: Für seine Natural Language Workflows gilt, "existing SOPs, playbooks, or support guides can often serve as a starting point." Außerdem empfiehlt es den visuellen Builder für "deterministic, strictly sequenced, or compliance-driven processes", ein guter Rat. Mehr zur KI-Seite in meinem Beitrag zu Freddy-KI-Agents.

Zwei Hinweise von außerhalb der Helpdesks lohnen sich zum Abschauen. Der Leitfaden von OpenAI zum Bau von Agents sagt, man solle "use existing operating procedures, support scripts, or policy documents" nutzen und merkt an, dass im Kundenservice Routinen "can roughly map to individual articles in your knowledge base" (OpenAI). Und Salesforce macht den Punkt, den ich Teams am liebsten mitgeben würde: Anweisungen sind nicht deterministisch und "don't replace the need for coded business rules." Ihr Beispiel ist eine 30-Tage-Erstattungsregel, die sie in eine Aktion legen würden, die die Kriterien prüft, nicht in einen Satz.

Das ist die ehrliche Grenze von SOP-als-Anweisung. Ein schriftliches Verfahren leitet die KI. Es garantiert nichts. Der Fall Air Canada ist die Mahngeschichte, auf die man immer wieder zurückkommt:

"Air Canada's chatbot returned sources along with its answer. ... Air Canada's argument was that because the chatbot response included a link to a page on the site outlining the policy correctly, Moffat should've known better."

Sayrus, Hacker News

Die richtige Richtlinie existierte, und der Bot sagte trotzdem etwas anderes. Deshalb schreibe ich bei allem, wo Geld fließt oder Daten offengelegt werden, die SOP für das Urteilsvermögen der KI und lege das harte Limit in die Aktion selbst. Das ist dieselbe Logik, wie einem neuen Mitarbeiter das Erstattungslimit im Abrechnungstool zu setzen, statt darauf zu vertrauen, dass er es sich merkt. Deshalb gehören KI-Leitplanken und eine saubere Übergabe an Menschen in die SOP und werden nicht später aufgesetzt.

Wo Support-SOPs liegen sollten

Der beste Ort für eine Kundensupport-SOP ist dort, wo Ihre Agents ohnehin sind, wenn das Ticket offen ist. In der Praxis heißt das zuerst Ihr Helpdesk, danach ein separates Tool. Das bietet jeder Helpdesk laut eigener Dokumentation:

Einiges aus dieser Tabelle hat Teams, mit denen ich gearbeitet habe, erwischt:

• Zendesk-Artikel nur für Agents brauchen Suite Growth oder höher; in Suite Team können Sie einen Artikel nicht auf Agents beschränken. Und die agentenseitigen Auto-Assist-Verfahren von Zendesk können nur öffentliche, veröffentlichte Artikel einfügen, interne SOPs lassen sich also nicht darin verlinken. Mein Beitrag zu Zendesk-Nutzersegmenten führt durch die Einrichtung.
• Gorgias hat gar keine Einstellung für Artikel nur für Agents. Unlisted-Artikel existieren öffentlich und sind per URL erreichbar; Gorgias' eigener Vorschlag für eine interne Verfahrensseite ist ein separates, für Suchmaschinen verborgenes Help Center (Gorgias-Dokumentation). Für die meisten Shops in Ordnung, aber legen Sie dort nichts Sensibles ab.
• Front zeigt interne Wissensdatenbanken im Seitenleisten-Plugin, aber das Werkzeug zum Einfügen in die Antwort braucht eine öffentliche. Interne SOPs stehen neben der Unterhaltung, nicht im Editor.
• Freshdesk kann Ordner nur für Agents in seinen Solution Article Suggester einspeisen, der Freddy AI Copilot und mindestens 25 veröffentlichte Artikel braucht (Freshdesk-Dokumentation). Copilot kostet 29 $ pro Agent und Monat in Pro und Enterprise (Freshdesk-Preise).

Wann ein separates SOP-Tool sinnvoll ist

Ein eigenes Tool lohnt sich in drei Fällen: Das Verfahren besteht überwiegend aus Klicks in anderen Systemen (Screenshots helfen), Sie brauchen den Nachweis, dass jeder Agent sie gelesen hat, oder mehrere Abteilungen teilen dieselben Verfahren. Das kosten die gängigen Optionen laut ihren Preisseiten:

Scribe ist derzeit das interessanteste. Sein Erfassungstool macht aus einem durchgeklickten Verfahren eine Anleitung, und es bewirbt diese Anleitungen inzwischen als Input für KI-Agents und sagt, man könne sie per MCP oder API "directly to your AI agents" weitergeben (Scribe).

Eine Warnung, die für jedes eigenständige Tool gilt: Eine SOP außerhalb des Helpdesks funktioniert nur, wenn Agents sie aus dem Ticket erreichen. Müssen sie eine zweite App öffnen und suchen, tun sie es nicht, besonders bei vier gleichzeitigen Chats. Prüfen Sie vor der Entscheidung, ob es eine Seitenleisten-App oder Browser-Erweiterung gibt. Und behalten Sie einen Exportweg. Ein Trainual-Rezensent auf G2 wies darauf hin, dass "the moment you stop paying you lose all your hard work making the SOP" (G2). Ihre Verfahren gehören Ihrem Unternehmen, egal welches Tool sie hält. Für einen breiteren Vergleich siehe meine Übersicht zu Software für Kundensupport-Wissensdatenbanken.

So halten Sie SOPs aktuell

Eine veraltete SOP ist schlimmer als keine, denn ein Agent, der ihr vertraut, schickt eine falsche Antwort mit voller Überzeugung. Das System, das bei mir funktioniert, ist eine kleine Schleife statt eines großen Jahres-Audits.

1. Geben Sie Agents einen Ein-Klick-Weg, eine Lücke zu melden. Ein Tag wie „sop-gap“ am Ticket reicht. Das Wissenspanel von Zendesk lässt Agents einen Artikel markieren, was ein Ticket für den Verantwortlichen erzeugt (Zendesk-Dokumentation).
2. Leiten Sie die Meldung an den Verantwortlichen, nicht ans Team. Dafür steht der Name oben auf der SOP.
3. Korrigieren Sie erst die SOP, dann das Makro, dann die KI-Anweisungen. Wenn möglich am selben Tag. Wenn Sie den letzten Schritt auslassen, zitiert Ihre KI weiter die Regel vom letzten Monat.
4. Prüfen Sie trotzdem nach Zeitplan. Ich nehme 90 Tage für Erstattungen, Zugang und Sicherheit und sechs Monate für den Rest.
5. Sehen Sie sich die Lücken-Tags monatlich an. Drei Meldungen zur selben SOP bedeuten, sie braucht eine Überarbeitung, keinen Flicken. Eine Wissenslückenanalyse leistet das im großen Maßstab.

Manche Tools automatisieren die Erinnerung. Mit der Artikelverifizierung von Zendesk können Admins bis zu 20 Verifizierungsregeln festlegen, und sie mailt den Artikelverantwortlichen, bis sie verifizieren, aber nur in Enterprise.

Document360 setzt einen Artikel auf "Stale", wenn das Prüfdatum verstrichen ist, und Guru markiert abgelaufene Karten in der Aufgabenliste des Verifizierers als nicht verifiziert (Guru). Ein Wissensspezialist, der Guru auf G2 bewertete, beschrieb, warum das für den Support wichtig ist:

"Instead of the content becoming obsolete, the platform enforces ownership by prompting subject matter experts to re-verify knowledge on a set schedule. This maintains a highly trustworthy repository for our support specialists directly inside our communications tools."

Dairon P., G2

Die Werkzeuge helfen, ersetzen aber nicht die Gewohnheit. Ein anderer Guru-Rezensent merkte an, dass das Bearbeiten einer Karte aus Formatierungsgründen sie automatisch verifiziert, auch wenn der Bearbeiter nicht der Experte ist (G2). Ein grüner Haken heißt nur, dass jemand geklickt hat. Er heißt nicht, dass die Schritte stimmen.

Fehler, an denen Kundensupport-SOPs scheitern

Diese Muster sehe ich am häufigsten, wenn ein Team sagt: „Wir haben SOPs, aber niemand nutzt sie“:

• Einen Aufsatz schreiben. Wenn sie über einen Bildschirm hinausgeht, überfliegen Agents sie mitten im Ticket und verpassen den entscheidenden Schritt. Lange Hintergründe gehören ins Richtliniendokument.
• Richtlinie, Schritte und Wortlaut vermischen. Jede Änderung wird riskant, also ändert niemand etwas. Halten Sie die drei Ebenen getrennt.
• Keine Zahlen bei den Ausnahmen. „Große Erstattungen eskalieren“ bedeutet für jeden Agent und jede KI etwas anderes.
• Eine SOP pro Kanal oder Region kopiert. Ein Reddit-Thread zum Aufbau von SOPs brachte es gut auf den Punkt: "Once you start duplicate SOPs, keeping them all current becomes its own job" (Reddit). Verzweigen Sie stattdessen innerhalb einer SOP.
• Die SOP als Skript behandeln. Tier-1-Skripte helfen Agents, keinen Schritt zu vergessen, aber die besten SOPs geben eine Befugnisgrenze und eine Begründung mit, damit Agents den Fall bewältigen, den die SOP nicht vorhergesehen hat. Mein Beitrag zu Feedback an Support-Agents behandelt die Coaching-Seite.
• KI SOPs ungeprüft schreiben und umschreiben lassen. Ein Kommentator beschrieb einen Agent, der "doing massive updates on Confluence constantly" machte, und fand das Ergebnis "full of hallucinations and nonsense" (Hacker News). KI kann aus Tickets Entwürfe machen. Ein Mensch mit Kontext gibt trotzdem frei.

Wenn Sie eine Gruppe neuer Agents einarbeiten, sind die SOPs die halbe Schulung. Wenn Sie über Zeitzonen hinweg arbeiten, sorgen sie auch dafür, dass eine Schichtübergabe um 3 Uhr nachts einheitlich bleibt.

eesel für Kundensupport-SOPs

Wenn Ihre Verfahren über Helpdesk, Wiki, ein paar Loom-Videos und einen Haufen Makros verteilt sind, ist das KI-Helpdesk-Teammitglied von eesel für genau dieses Durcheinander gebaut. Es verbindet sich mit Zendesk, Freshdesk, Gorgias, Front, Help Scout und den Dokumenten, in denen Ihre SOPs liegen, etwa Confluence, Notion und Google Docs, und lernt auch aus Ihren früheren Tickets, nimmt also die Schritte auf, denen Ihre besten Agents tatsächlich folgen, auch die, die nie jemand aufgeschrieben hat. Es entwirft Antworten oder antwortet direkt, und bevor Sie irgendetwas einschalten, können Sie es an Hunderten Ihrer früheren Tickets simulieren und sehen, wo es der SOP folgen würde und wo nicht.

Am wichtigsten für SOPs ist die Anweisungsseite. Sie ist ein schlichtes Dokument mit Ihren Antwortrichtlinien und Workflow-Schritten, geschrieben im selben Format wie die Vorlage oben. Korrigiert eine Führungskraft im Chat eine Antwort, schreibt eesel die Korrektur in diese Anweisungen, sodass die Korrektur für jede künftige Antwort gilt, statt im Kopf einer einzelnen Person zu bleiben.

Sie brauchen auch keine riesige Bibliothek, um zu starten. Ein britisches Support-Team, das ich mir angesehen habe, ließ eesel aus nur neun synchronisierten Zendesk-Makros 56 Aufgaben lösen. Fünf klare SOPs und eine Handvoll Makros bringen mehr, als man denkt.

Um ehrlich zu sein, was eesel ist und was nicht: eesel ist kein Schulungs- oder Freigabe-Tool. Wenn Sie E-Signaturen brauchen, dass jeder Agent die Erstattungs-SOP gelesen hat, behalten Sie dafür Trainual oder Ähnliches. Was eesel leistet, ist sicherzustellen, dass die SOP bei jedem Ticket befolgt wird, von der KI und vom Agent, der ihren Entwurf prüft. Sie können eesel kostenlos mit 100 Credits testen, ohne Karte, und sehen, wie es mit Ihren eigenen Tickets umgeht.