Was ein Freigabe-Workflow im Support tatsächlich abdeckt
Ein Freigabe-Workflow greift immer dann, wenn jemand im Team nicht allein handeln darf. Im Support sind das meist drei Arten von Anfragen:
- Geld: Erstattungen, Gutschriften, Kulanzgesten und Gebührenerlasse über dem, was ein Mitarbeiter gewähren darf.
- Ausnahmen: alles außerhalb der schriftlichen Richtlinie, etwa eine Rückgabe nach Ablauf der Frist oder eine Kündigung ohne vorherige Fehlerbehebung. Mein Ratgeber zum Ausnahmemanagement im Support zeigt, wie Sie sie protokollieren.
- KI-Arbeit: Antworten und Aktionen, die ein KI-Agent entwirft und die ein Mensch prüft, bevor sie rausgehen.
Der Geldfall ist der älteste, und Mitarbeiter an der Front beschreiben ihn branchenübergreifend gleich. So hat ein Support-Mitarbeiter eines Telekommunikationsunternehmens eine echte Gutschriftenleiter beschrieben:
"Supervisors can approve up to about $300 in credits, then whatever is left gets rolled up to their managers. Floor support or SME'S have about the same limit as a supervisor, but they do not have access to things like the credit qué and a few other things."
Das ist ein Workflow, auch wenn ihn nie jemand aufgeschrieben hat: Limits pro Rolle, eine Warteschlange, die nur manche sehen, und obendrauf die Übergabe nach oben. Ihn aufzuschreiben ist der erste Schritt, und er gehört in Ihre Support-SOPs, neben die Richtlinie selbst.
An der Anfragekarte scheitern die meisten Workflows, deshalb fange ich dort an. Ein Genehmiger sollte allein anhand der Karte entscheiden können:
Muss die Führungskraft das Ticket öffnen, den Verlauf durchscrollen und dann auch noch die Bestellung nachschlagen, dauert die Freigabe 15 Minuten statt 15 Sekunden. Von der Warteschlangenseite sehe ich die Kosten jede Woche: Der Kunde wartet, und der Mitarbeiter wird zum Boten einer Entscheidung, die er nicht getroffen hat.
Entscheiden Sie, was freigegeben werden muss, bevor Sie ein Tool wählen
Die Tool-Frage kommt an zweiter Stelle. Zuerst legen Sie fest, welche Anfragen überhaupt eine zweite Person brauchen, und dafür nutze ich zwei Tests.
Test 1: Liegt es über dem Limit des Mitarbeiters? Legen Sie Betragsstufen fest, geben Sie jeder Stufe einen Genehmiger, und lassen Sie Mitarbeiter alles unterhalb ihrer Stufe ohne Nachfrage erledigen. Freigaben bei Kleinstbeträgen sind reine Verschwendung, wie ein Kommentator feststellte, nachdem er auf eine Erstattung von 37 Cent gewartet hatte:
"This is why for the store it is better to have a smoother process for small price adjustments, it should not be necessary to wait 15 minutes for the store manager's approval on a 37 cent refund, nor should he even have to deal with it at all, that is a waste of his time and salary to be attending to something so minor."
Test 2: Lässt es sich rückgängig machen? Das wird mit KI noch wichtiger, denn eine Erstattung kann zurückgebucht oder abgeschrieben werden, ein Versprechen in einer E-Mail dagegen nicht. Ein aktueller Thread dazu, was KI-Agenten ohne Freigabe tun sollten, kam genau darauf:
"imo the cutoff isnt really about the action type, its about reversibility. if the agent does something you can undo in 30 seconds, let it run. if undoing it requires an apology email to a customer, that needs approval."
Kombinieren Sie beide Tests, ergibt sich eine Treppe. Die Zahlen unten sind ein Beispiel, kein Richtwert. Wählen Sie Ihre aus Ihrer eigenen Erstattungshistorie:
Die meisten Tickets sollten auf der untersten Stufe enden. Steigt die Hälfte Ihrer Erstattungstickets die Treppe hinauf, sind die Limits zu niedrig, und jeder Aufstieg bedeutet Wartezeit für den Kunden. Der Ratgeber zur Erstattungs-Freigabematrix geht ausführlich auf die Festlegung der Stufen ein. Es gibt auch ein faires Gegenargument: Manche Freigaben haben einen Grund, denn Mitarbeiter an der Front wissen nicht immer, warum ein Preis oder eine Richtlinie so gesetzt ist. Das Ziel sind weniger, gezieltere Freigaben, nicht null.
Wo jeder Helpdesk Freigaben ansiedelt
Ich habe die Help Center der Helpdesks durchgesehen, die mir in eesel-Rollouts am häufigsten begegnen. Sie fallen in drei Gruppen: Tools mit echtem Freigabeobjekt, Tools für IT-Freigaben und Tools, bei denen „Freigabe“ einen geteilten Entwurf plus eine entzogene Berechtigung bedeutet. Wählen Sie Ihren aus, um Einrichtung, Entscheidungsort der Genehmiger und Tarifvoraussetzung zu sehen:
Kurz gesagt: Wenn Sie ein Freigabeobjekt mit Status, Schließsperre und Vermerk brauchen, sind Zendesk Professional, Freshservice und Jira Service Management die einzigen drei hier, die es für Tickets mitbringen. Alle anderen kommen über Prozesse ans Ziel.
Zendesk: echte Genehmigungsanfragen ab Suite Professional
Zendesk nennt Erstattungen als Beispielfall: Ein Mitarbeiter erhält ein Erstattungsticket, erstellt eine Genehmigungsanfrage und schickt sie an einen Genehmiger wie seinen Teamleiter. Die Regeln sind auf nützliche Weise streng, laut Zendesks Dokumentation zu Genehmigungen:
- Bis zu 5 Genehmiger pro Anfrage. Bei mehreren müssen alle zustimmen, und eine Ablehnung lehnt den gesamten Block ab.
- Der Genehmiger darf weder der Anfragesteller des Tickets noch der Bearbeiter noch die Person sein, die die Anfrage erstellt hat. Die Funktionstrennung ist eingebaut.
- Gruppen-Genehmiger funktionieren nur bei Gruppen mit höchstens 30 Mitgliedern, und die erste Antwort zählt.
- Eine offene Anfrage verhindert das Schließen des Tickets, bis alle geantwortet haben oder sie zurückgezogen wird.
- Anfragen lassen sich nach dem Erstellen nicht bearbeiten. Sie ziehen sie zurück und erstellen sie neu.
Die Lücken sollten Sie kennen, bevor Sie darauf aufbauen. Es gibt keine sequenzielle Kette: Brauchen Sie erst den Teamleiter und dann den Manager, erstellen Sie eine Anfrage, warten und erstellen dann die nächste. Zendesk dokumentiert auch keine Erinnerungsfunktion, also ist das Nachhaken bei einem langsamen Genehmiger Handarbeit per Link. Ein Zendesk-Product-Manager bestätigte in den Kommentaren außerdem, dass die Freigabe per E-Mail-Antwort aus Compliance-Gründen ausgeschlossen ist.
Der Slack-Teil ist die große Änderung 2026. Seit Mai 2026 erhalten einzelne Genehmiger eine Slack-DM, und Gruppenfreigaben öffnen einen temporären privaten Kanal mit allen Mitgliedern der Gruppe:
Im Oktober 2026 hat Zendesk Slack-Kommentare ergänzt, die als prüfbarer Vermerk ins Ticket zurücksynchronisiert werden. Eine Anfrage erstellen oder zurückziehen können Sie weiterhin nicht aus Slack. Für automatisierte Abläufe kann das Action-Flows-Rezept bis zu 30 Tage pausieren und nach Approved, Denied, Withdrawn oder Expired verzweigen, wobei Zendesk sagt, dass erweiterte Freigabeaktionen sein Early-Access-Programm erfordern.
Wenn Sie Suite Team nutzen, ist Side Conversations der Ausweichweg, also ein separater Thread statt eines Approve-oder-Deny-Objekts. Die Tarifvoraussetzungen stehen in meiner Aufschlüsselung zu Zendesk-Preisen, und der Ratgeber zu Rollen und Berechtigungen erklärt, wer Anfragen erstellen darf.
Freshservice und Jira Service Management: Freigabeketten auf IT-Niveau
Beide Tools kommen von der IT-Seite, und das merkt man: Freigaben sind dort ein vollwertiges Objekt mit mehrstufiger Logik, die den Customer-Service-Helpdesks fehlt.
In Freshservice sitzen Genehmiger in Gruppen, und Gruppen sitzen in einer Kette. Jede Gruppe hat eine Regel (Everyone, Anyone, Majority oder First Responder), und die Kette hat ebenfalls eine:
Zwei Funktionen wünsche ich mir von Customer-Service-Tools. Freshservice kann Genehmiger alle N Stunden erinnern, und Genehmiger können Freigaben mit Von- und Bis-Datum an einen Kollegen delegieren, was das Problem „Manager ist im Urlaub“ löst. Die Preise reichen von 19 bis 99 $ pro Agent und Monat bei jährlicher Abrechnung, mit Multi-Approval-Workflows in jedem Tarif. Mein Ratgeber zu Freshservice-Preisen enthält die Tarifdetails.
Jira Service Management ergänzt die Freigabe als Schritt in einem Workflow-Status. Sie wählen die Zahl der Genehmiger, woher sie kommen und von welchen Feldern sie ausgeschlossen werden, etwa Bearbeiter oder Melder. Genehmiger handeln im Help Center, per E-Mail, Slack oder Teams, und sie brauchen keine JSM-Lizenz. Der Beitrag zu Jira Service Management Preisen erklärt, warum die 100 E-Mails pro Tag im Free-Tarif Freigabe-Benachrichtigungen ausbremsen können.
Wenn Ihr Support-Team ohnehin ein Freshworks- oder Atlassian-Konto mit der IT teilt, kann es sich lohnen, Erstattungsfreigaben dort laufen zu lassen. Wenn nicht, sind diese Tools für ein Support-Team, das nur das Ja einer Führungskraft will, viel Einrichtungsaufwand.
Front, Help Scout und Freshdesk: Entwürfe und Berechtigungen
Diese drei haben keine Genehmigen-Schaltfläche für Tickets. Sie haben einen Entwurf, den jemand anderes sehen kann, und eine Möglichkeit, bestimmten Personen das Senden zu verbieten.
Fronts eigene empfohlene Regel lautet, „bei Preisfragen den Entwurf immer zur Freigabe mit einer Führungskraft zu teilen“, laut dem Artikel zu Support-Workflows. Geteilte Entwürfe sind in geteilten Posteingängen standardmäßig aktiv, aber Teamkollegen werden nur benachrichtigt, wenn Sie sie per @ erwähnen:
Um daraus eine harte Regel zu machen, entziehen Sie einer Gruppe wie neuen Mitarbeitern die Berechtigung „Send messages“. Das erfordert Enterprise für 105 $ pro Platz und Monat und gilt nur für geteilte Kanäle. Front schlägt für Freigabeanfragen auch eine verknüpfte Aufgabe vor, die einer Führungskraft zugewiesen wird, was in allen Tarifen funktioniert und die Konversation wieder nach oben holt, wenn die Aufgabe erledigt ist. Tarifdetails stehen in meinem Beitrag zu Front-Preisen.
Help Scouts dokumentierter Ansatz ist einfacher: Neue Mitarbeiter speichern Antworten als Entwürfe, und eine Führungskraft sendet in ihrem Namen über das Menü Send options. Light Users, die Notizen hinterlassen, aber nicht antworten können, erfordern Plus oder Pro. Der Haken: Help Scout gibt an, dass es keine Methode gibt, einzelne Konversationen einzuschränken, Sie können also nicht sagen „dieser Mitarbeiter braucht nur bei Erstattungstickets eine Freigabe“. Mehr in der Aufschlüsselung zu Help Scout-Preisen.
Freshdesk dokumentiert einen Freigabe-Workflow, aber für Wissensdatenbank-Artikel in Enterprise, nicht für Tickets. Die Ticket-Freigabe in Freshdesk ist ein Prozess, den Sie mit Rollen und Berechtigungen und internen Notizen aufbauen. Der Ratgeber zu Freshdesk-Freigaben führt durch diese Optionen.
Gorgias und HubSpot: Rechte nach Rolle, Freigaben anderswo
Gorgias steuert Erstattungen über Rollen statt über Freigaben. Basic-, Lead- und Admin-Nutzer können eine Shopify-Erstattung oder -Stornierung direkt aus dem Ticket auslösen, Observer- und Lite-Nutzer nicht, und in den Tabellen der Nutzerberechtigungen habe ich keine Betragsobergrenze pro Mitarbeiter gefunden. Das Nächste an einem Prüfschritt ist, dass Makroaktionen unter dem Editor erscheinen, wo der Mitarbeiter sie vor dem Senden ansehen, bearbeiten oder entfernen kann. Wenn Sie in Gorgias eine Führungskraft einbinden wollen, ist das ein Rollendesign und eine Teamnorm, die Sie mit Gorgias-Regeln stützen können, die Erstattungstickets für die Prüfung durch einen Teamleiter markieren.
HubSpot hat die ausgereifteste Freigabe-Oberfläche der Gruppe, mit Approve, Reject und Request changes am Datensatz, aber sie gilt für Deals und Angebote. Tickets stehen nicht auf HubSpots Liste der Freigabeobjekte. Regeln für die Ticket-Pipeline in Service Hub Professional können einschränken, wer Tickets in bestimmten Phasen bearbeitet, aber Super-Admins, Workflows und die API können sie umgehen. Mein Ratgeber zu KI für HubSpot Service Hub beschreibt, was die Support-Seite automatisieren kann.
Setzen Sie das Betragslimit auch in der Zahlungsebene
Wenn Ihr Helpdesk ein Limit nicht durchsetzen kann, kann es manchmal das Zahlungssystem. Stripe hat die klarste native Erstattungsfreigabe, die ich gefunden habe: eine Zwei-Parteien-Freigaberegel für „Refund is created“ mit optionalem Betragsschwellenwert. Ein Nutzer kann seine eigene Anfrage nicht genehmigen, und nicht genehmigte Anfragen laufen nach 14 Tagen ab, laut Stripes Dokumentation zu Zwei-Parteien-Freigaben.
Shopifys Online-Admin kennt Erstattungsberechtigungen nur als an oder aus, ohne Betragslimit. Shopify POS ist anders: Erstattungen, Rabatte und Guthaben lassen sich auf „Approval required“ setzen, und eine Führungskraft genehmigt durch Eingabe ihrer PIN. Benutzerdefinierte POS-Rollen sind ein Feature von POS Pro.
KI-Antworten und -Aktionen genehmigen
Alles oben Genannte setzt voraus, dass ein menschlicher Mitarbeiter fragt und ein Mensch genehmigt. Mit einem KI-Agenten in der Warteschlange kommt eine zweite Ebene hinzu: Die KI bereitet die Arbeit vor, und ein Mensch genehmigt sie, bevor sie den Kunden oder Ihre Systeme erreicht. Ein Hacker-News-Kommentator beschrieb dieses Setup gut, bevor die meisten Anbieter es auslieferten:
"Now if AI agents are free to issue refunds or discounts by their own? Great, let's do that and suddenly most people are on board. But get ready for rampant abuse. Best solution would be an AI cyborg system where it readies a recommendation and a human swings by and approves or denies it without wasting time talking to people."
Das ist nah an dem, was Anbieter heute liefern, jeder auf seine Weise:
- Zendesk Auto Assist (Teil des Copilot-Add-ons) schlägt Aktionen vor, die ein Mitarbeiter vor der Ausführung genehmigt. Admins können eine Aktion als vorab genehmigt markieren, und Zendesks eigene Empfehlung lautet, dass Schreibaktionen wie Erstattungen vom Mitarbeiter genehmigt bleiben sollten. Mein Ratgeber zu Auto-Assist-Aktionen zeigt die Einrichtung.
- Front Autopilot-Regeln haben ein Feld „Hold reply for review“, das einen Entwurf erstellt statt zu senden, und Front empfiehlt, dort vor der vollen Automatisierung zu starten.
- Help Scout AI Drafts sind dafür geschrieben, dass Mitarbeiter sie vor dem Senden prüfen und überarbeiten, in Plus und Pro.
- Gorgias AI Agent hat eine Einstellung „Customer confirmation“, aber beachten Sie, wer genehmigt: der Kunde bestätigt, nicht eine Führungskraft. Sie schaltet sich bei nicht umkehrbaren Aktionen wie dem Stornieren einer Bestellung automatisch ein.
- Stripe wendet Standard-Freigaberegeln auf Erstattungen an, die mit Agent-gekennzeichneten API-Schlüsseln erstellt werden. Selbst die Zahlungsebene behandelt von KI ausgelöste Erstattungen als eigenen Akteur.
So würde ich den Ablauf bei einer Erstattungsanfrage mit KI anlegen:
Was Prüfer mit KI-Entwürfen tatsächlich tun, wird oft unterschätzt. In einem Test mit echtem Traffic in einem E-Commerce-Zendesk-Posteingang war die Triage zu 93 % korrekt, aber Mitarbeiter sendeten nur 12 % der KI-Entwürfe unverändert. Das Muster war überfliegen und umschreiben: ein Entwurf mit 8 bis 15 Sätzen, gekürzt auf 1 bis 3 Sätze. Etwa 65 % der Überarbeitungen betrafen Länge und Ton, also etwas, das sich durch Training mit den gesendeten Antworten des Teams beheben lässt, und nur etwa 5 % betrafen sachliche Fehler der KI.
Zwei Lehren von der Warteschlangenseite. Erstens: Eine Ja-oder-Nein-Schaltfläche reicht nicht. Ein Freshdesk-Kunde sagte mir, er müsse KI-Entwürfe vor dem Senden bearbeiten, weil ihn „unverändert genehmigen oder ablehnen“ zu Kopieren und Einfügen zwang. Zweitens: Prüfen Sie, dass die bearbeitete Version tatsächlich gesendet wird. Ein Kollege meldete einmal einen Freshdesk-Kunden, bei dem bearbeitete Entwürfe als ursprüngliche, unbearbeitete Version rausgingen, was den Workflow unbrauchbar machte, bis es behoben war. Testen Sie diesen Pfad, bevor Sie ihm vertrauen.
Wenn Sie KI-Copilot-Tools vergleichen, sagen Ihnen diese zwei Details mehr als jede Demo. Freshdesks eigene Sicht auf Entwürfe steht in meinem Beitrag zu Freshdesk KI-Antwortentwürfen.
So betreibe ich Approve-first-KI mit eesel
Das KI-Teammitglied von eesel ist so gestaltet, wie Sie einen neuen Mitarbeiter einarbeiten würden. Es bekommt am ersten Tag keinen Autonomie-Schalter. Es verdient sich Autonomie durch geprüfte Arbeit. In der Praxis läuft das auf eine Einstellung pro Aktion hinaus, pro Agent gewählt, wie in der Dokumentation zu Actions and Approvals beschrieben:
- Auto: läuft von selbst, es sei denn, die Anweisungen sagen, in einer bestimmten Situation vorher zu fragen.
- Needs approval: Der Agent bereitet die Aktion vor, und ein Mensch genehmigt oder lehnt sie ab, bevor etwas passiert.
- Disabled: Der Agent kann sie gar nicht verwenden.
Aktionen sind in Read und Write gruppiert, ein üblicher Startpunkt ist also Read auf Auto und das meiste von Write auf Needs approval, mit risikoarmen Aktionen wie internen Notizen auf Auto:
Braucht eine Aktion eine Freigabe, sieht der Genehmiger den genauen Antworttext oder Erstattungsbetrag (oder das Tag) und wählt dann eine von drei Schaltflächen. Approve führt sie jetzt aus. Always allow führt sie aus und stellt diese Aktion ab dann auf Auto, nur für diesen Agenten. Deny überspringt sie, und der Agent macht ohne sie weiter. Diese Schaltfläche „Always allow“ ist der Abschlussschritt: Sie genehmigen Erstattungen bei einem Shop-Agenten fünfmal, sie sehen richtig aus, und Sie lassen ihn laufen.
Die Freigabe landet dort, wo der Genehmiger ohnehin arbeitet, was wichtig ist, denn der eingangs zitierte Zendesk-Admin wollte nicht noch einen Tab im Blick behalten. Freigaben erscheinen im eesel-Dashboard, als Karte im Slack-Thread, von dem der Lauf ausging, als Link in einer E-Mail oder Helpdesk-Notiz und im Terminal:
Ein paar Regeln, auf die ich mich beim Einrichten für einen neuen Kunden stütze:
- Ausnahmeregeln werden in einfachen Worten formuliert. Sie können Antworten auf Auto lassen und schreiben „vor Antworten zu allem rund um Erstattungen nachfragen“, und der Agent fragt nur in diesen Fällen. Die Dokumentation enthält Vorlagen genau dafür, etwa jede Erstattung über 100 $ zu eskalieren oder die Fotoanfrage bei Schadensmeldungen unter 50 $ zu überspringen. So hat ein Support-Admin seinem Agenten die Regel „erst Fehler beheben, dann kündigen“ beigebracht: indem er ihn wie einen neuen Mitarbeiter korrigierte.
- Nur Editors können genehmigen. Owners und Editors entscheiden. Viewers sehen Freigaben, können aber nicht handeln, und in Slack wird der Klickende per E-Mail einem Editor zugeordnet.
- Nichts wird bei Zeitüberschreitung automatisch genehmigt. Eine offene Aktion bleibt offen, und der Agent hinterlässt eine Notiz, dass sich ein Mensch melden wird. Jede Entscheidung zeigt auf der Seite Activity, wer wann entschieden hat.
- Nichts läuft, bevor Sie eine Automatisierung erstellen. Das Verbinden von Zendesk lässt den Agenten niemandem antworten.
Für Teams, die im Terminal leben oder Claude Code, Codex oder Cursor Freigaben verwalten lassen wollen, steuert das eesel CLI denselben Agenten wie das Dashboard. eesel approvals listet, was wartet, eesel approvals approve <id> --always genehmigt und schließt die Aktion in einem Schritt ab, und eesel integrations zendesk actions gibt jede Aktion mit ihrer Freigabeeinstellung aus. CLI-Schreibzugriffe folgen denselben Berechtigungen, daher werden Schreibaktionen eines Viewers immer für einen Editor zurückgehalten.
Bevor irgendetwas davon einen Kunden berührt, bitte ich zuerst um eine Simulation. Mit angebundenem Helpdesk spielt der Agent echte vergangene Tickets nach und vergleicht seine Antworten mit denen des Teams. Im Beispiel der Dokumentation stimmten 17 von 20 gezogenen Tickets überein, mit einem Wert pro Thema und einer nach Rang sortierten Liste von Korrekturen. Das zeigt, welche Aktionen bereit für Auto sind und welche hinter einer Freigabe bleiben sollten. Für das größere Bild siehe meine Beiträge zu KI-Teammitgliedern und zum KI-Helpdesk-Agenten.
Häufige Fehler bei Freigabe-Workflows
- Alles genehmigen. Wenn jede Erstattung eine Führungskraft braucht, wird die Führungskraft zur Warteschlange. Erhöhen Sie die Mitarbeiterlimits, bis die meisten Tickets auf der untersten Stufe enden.
- Eine dünne Anfrage. „Kann ich das erstatten?“ zwingt den Genehmiger, das Ticket zu rekonstruieren. Nutzen Sie die Karte mit fünf Zeilen: Bestellung, Anliegen, Richtlinienzeile, Empfehlung, Frist.
- Keine Erinnerung und kein Ersatzgenehmiger. In der Dokumentation von Zendesk und Jira habe ich keine Erinnerungsfunktion für Freigaben gefunden. Hat Ihr Tool ebenfalls keine, legen Sie ein internes SLA für Freigaben fest und benennen Sie einen Vertreter.
- Kein schriftlicher Vermerk. Eine Freigabe in einer DM ist für den nächsten Mitarbeiter unsichtbar. Halten Sie die Entscheidung im Ticket fest, damit sie in Ihr Ausnahmeprotokoll und in künftige Richtlinienänderungen einfließt.
- KI zu früh befördern. Stellen Sie eine Aktion nach geprüfter Arbeit auf automatisch, nicht nach einer guten Demo. Der Eintrag zu KI-Guardrails behandelt weitere sinnvolle Limits, und Prompt Injection ist der Grund, warum Erstattungsaktionen besondere Sorgfalt verdienen.
- Vergessen, wohin Eskalationen gehen. Freigabe und Eskalation sind verwandt. Wird eine Freigabe abgelehnt, braucht der Agent einen klaren Weg, den KI-Eskalation und teamübergreifende Eskalation behandeln.
Wenn sich Richtlinien ändern, aktualisieren Sie am selben Tag auch die Freigaberegeln. Mein Ratgeber zum Management von Richtlinienänderungen zeigt, wie Sie Mitarbeiter, Makros und KI-Anweisungen synchron halten, und Zugriffskontrolle für Support-Mitarbeiter erklärt, wie Sie festlegen, was jeder Platz, einschließlich des KI-Platzes, anfassen darf.
eesel für Approve-first-KI in Ihrer Warteschlange testen
Wenn Sie Zendesk, Freshdesk, Gorgias oder einen anderen Helpdesk nutzen, an den eesel sich anbindet, kann das KI-Helpdesk-Teammitglied von eesel so starten, wie Sie jeden neuen Mitarbeiter bei Erstattungen starten würden: Es entwirft die Antwort oder die Erstattung, und Sie genehmigen sie aus Slack, dem Ticket oder dem Dashboard. Aktionen, die immer wieder richtig sind, bekommen „Always allow“, und alles, was Geld kostet, kann so lange hinter Ihrem OK bleiben, wie Sie möchten. Die Berichtsansicht zeigt pro Tool, wie viele Aktionen genehmigt, abgelehnt oder noch offen waren:
Freigaben kosten nichts extra. Ein Ticket oder Chat ist 1 Credit, egal wie viele Antworten und Aktionen es braucht, mit unbegrenzten Plätzen; der kostenlose Tarif hat 100 Credits und keine Karte, und bezahlte Tarife beginnen bei 299 $ im Monat für 500 Credits. Testen Sie eesel in Ihrer eigenen Warteschlange mit jeder Antwort auf Needs approval und sehen Sie, wie viele Sie unverändert gesendet hätten.