
Was Zugriffskontrolle für Support-Agenten umfasst
Die meisten Teams denken bei Zugriffskontrolle an „Agent oder Admin“. In der Praxis gibt es vier Ebenen, und eine Lücke in einer davon hebelt die anderen drei aus.
| Ebene | Die Frage, die sie beantwortet | Typische Kontrollen |
|---|---|---|
| Identität | Ist das wirklich dein Agent? | SSO, erzwungene 2FA, IP-Beschränkungen, Sitzungs-Timeouts |
| Sichtbarkeit | Welche Tickets und Kundendaten kann er sehen? | Ticketzugriff, Zugriff pro Posteingang oder Abteilung, Datenmaskierung |
| Fähigkeit | Was kann er damit tun? | Rollen und Berechtigungen: antworten, löschen, exportieren, erstatten, Einstellungen ändern |
| Nachvollziehbarkeit | Kannst du belegen, was passiert ist? | Audit-Log, Zugriffsprotokoll, Freigabeverlauf |
Ich bin Rama und baue die Helpdesk-Integrationen von eesel, deshalb verbringe ich einen großen Teil meiner Woche auf der anderen Seite dieser Berechtigungsfenster. Jedes Mal, wenn eesel sich mit einem Helpdesk verbindet, muss es Scopes anfordern und dann innerhalb der Rolle eines echten Agenten arbeiten. In Zendesk zum Beispiel werden die Antworten von eesel als der Zendesk-Nutzer gepostet, der die Verbindung freigegeben hat, sodass dessen Zendesk-Rolle die harte Obergrenze für das ist, was die KI tun kann. Das ist die Linse, die ich durchgehend verwende: Bei Zugriffskontrolle geht es ebenso um die Plätze, die man vergisst, wie um die, die man am ersten Tag einrichtet.
Wenn du auch Kunden oder Marken trennst, überschneidet sich die Sichtbarkeitsebene mit Kundensupport für mehrere Marken und kundenspezifischen Wissensdatenbanken, die ich hier nicht wiederhole.
Warum Ticketzugriff nicht dasselbe ist wie Zugriffskontrolle
Der Ticketzugriff ist die Einstellung, die die meisten meinen, wenn sie sagen „Agenten sehen nur ihre eigenen Tickets“. In Zendesk sind die Optionen: alle Tickets, Tickets in den Gruppen des Agenten, Tickets in seiner Organisation oder nur zugewiesene. Freshdesk bietet ab Growth alle, Gruppen- oder zugewiesene Tickets.

Hier ein Beispiel für ein Team, das das braucht, aus einem r/Zendesk-Thread über die Trennung von Bereichen:
"the agents would belong to different business divisions under the same overall company. They'd work on tickets that employees submit with sensitive data so this is why we want the agents in one division not to have access to see another agent group's tickets and so on"
Der Zugriffsbereich regelt die Vordertür. Die Dokumentation der Anbieter beschreibt mindestens drei Seitentüren:
- CCs. Zendesk sagt, wer einen Agenten in CC setzt, light agents eingeschlossen, schickt ihm jedes öffentliche und private Update per E-Mail, unabhängig vom Ticketzugriff (Zendesk-Standardrollen). Ein einziges CC bei einem sensiblen Ticket, und die Zugriffseinstellung spielt für diesen Verlauf keine Rolle mehr.
- Admins. Admins sehen alles. Zoho Desk sagt es deutlich: Selbst wenn die Freigabe auf Privat steht, „support admins can view all the tickets within a department“ (Zoho-Regeln zur Datenfreigabe). Die Admin-Liste ist also Teil deiner Sichtbarkeitsrichtlinie, ob du das geplant hast oder nicht.
- KI-Entwürfe. Zendesks Auto Assist „may generate text replies based on that content for agents and end users who don't belong to the related user segment“. Mit anderen Worten: Eingeschränkte Help-Center-Inhalte können einen Agenten erreichen, der den Artikel nicht öffnen könnte. Standardmäßig hat jede Gruppe Auto Assist (Einrichtung von Auto Assist).

Zwei Helpdesks sind bei den Grenzen offener. Help Scout trennt nach Posteingang, und in der Dokumentation heißt es „There is no method to restrict individual conversations“ (Help-Scout-Rollen). Gorgias gibt jeder Rolle, auch Observer, die Berechtigung „View tickets“ und eine Standardansicht aller offenen Tickets und dokumentiert keine harte Sperre beim Öffnen eines Tickets (Gorgias-Nutzerberechtigungen). Für ein Team mit einer einzigen Marke ist beides nicht falsch. Es heißt nur, dass die Trennung über separate Posteingänge oder Konten erfolgen muss, nicht über eine Rolle.
Was jeder Helpdesk dich steuern lässt
Das ist die Gegenüberstellung, die ich mir beim ersten Kartieren gewünscht hätte. Preise gelten pro Agent und Monat laut der Preisseite des jeweiligen Anbieters im Oktober 2026, bei jährlicher Abrechnung, wo die Seite beides zeigt.
| Zendesk | Freshdesk | Gorgias | Help Scout | Front | Zoho Desk | HubSpot Service Hub | |
|---|---|---|---|---|---|---|---|
| Eigene Rollen | Nur Enterprise (auf Anfrage) | Pro (55 $) und höher | Keine, 5 feste Rollen | Individuell pro Nutzer ab Plus (45 $) und Pro | Enterprise (105 $) | 5 in Standard (14 $), 25 in Professional, 50 in Enterprise | Schalter pro Nutzer; Nur-Team-Zugriff ab Professional |
| Ticketzugriff | Gruppen, Organisation, zugewiesen | Gruppe, zugewiesen; Nur-Lese-Gruppen in Enterprise | Nur Ansichten, keine harte Sperre | Pro Posteingang | Pro geteiltem Posteingang | Pro Abteilung; Freigaberegeln in Enterprise | Alle, Team, eigene |
| Günstiger oder eingeschränkter Platz | Light Agents: 50 bis 5.000 inklusive ab Growth | Collaborators bis 5.000; Tagespässe 2 bis 12 $ | Nicht pro Agent berechnet; Observer-Rolle | Light Users: 5 kostenlos in Plus, 15 in Pro | Gastkonten | Light Agents 6 $/Monat | Nur-Lese-Plätze, kostenlos und unbegrenzt |
| SSO | SAML in allen Tarifen | SAML ab Growth | Eigenes OIDC ab Advanced | SAML in Pro | SAML ab Professional | Active Directory | SAML ab Professional |
| IP-Beschränkung | Alle Tarife | Enterprise | Nicht dokumentiert | Nicht dokumentiert | Enterprise | Alle Editionen | Nicht dokumentiert |
| Audit-Log | Ab Enterprise, unbegrenzt gespeichert | Enterprise | 12 Monate (Pro, Advanced) | Nicht dokumentiert | Alle Tarife, 365 Tage | Enterprise | 30-Tage-Ansichten, vollständig in Enterprise |
| Wer die KI konfiguriert | Support-Admins standardmäßig | Administratoren | Lead und Admin | Beacon-Einstellungen | Voreinstellung Workspace-Admin | Nicht dokumentiert | Berechtigung Customer-Agent-Editor |
Quellen: Zendesk, Freshdesk, Gorgias, Help Scout, Front, Zoho Desk, HubSpot.
Ein paar Zellen verdienen einen Satz. Zendesk und Zoho Desk enthalten IP-Beschränkungen in jedem Tarif, und in Zendesk können Agenten und Admins sie nicht umgehen (Zendesk-IP-Beschränkungen). Das Audit-Log von Front läuft in jedem Tarif mit 365 Tagen Verlauf und protokolliert auch Änderungen durch Admin Copilot, die API und Apps (Front-Audit-Log), was ungewöhnlich großzügig ist. Und Zendesk in Enterprise streicht die Standard-Agentenrolle ganz, sodass der Zugriff jedes Agenten aus einer eigenen Rolle stammt, mit einer Obergrenze von 197 pro Konto.
Die eigenen Berechtigungssätze von Front zeigen gut, wie Least Privilege auf Schalterebene aussieht. Das Beispiel von Front selbst: Auszubildende dürfen in geteilten Posteingängen Entwürfe schreiben, wobei „Send messages“ ausgeschaltet bleibt, bis sie eingearbeitet sind.

Für die Details pro Anbieter geht mein Leitfaden zu Zendesk-Rollen die komplette Berechtigungsliste durch, die Freshdesk-Version behandelt den Zugriffsbereich. Auch Gorgias hat eine eigene Rollenübersicht.
Was Least Privilege kostet
Das Muster in der Tabelle: Feinkörnige Rollen sind ein Feature der obersten Tarife. So sieht es aus, ab wo eigene Rollen in jedem Helpdesk erstmals verfügbar sind.

Ein Zendesk-Berater im selben r/Zendesk-Thread fasste zusammen, was das in niedrigeren Tarifen bedeutet:
"Groups (even normal) can do this. As long as agents access is set to "Only tickets in their group". Admins will be able to always see all tickets but agents get locked down as long as Access is set that way. If in Enterprise custom roles is how you handle this."
Front hört diese Kritik seit Jahren. Eine Capterra-Bewertung von 2022 (der genannte Preis stammt von damals, nicht von heute) formulierte es so:
"basic features like a user and team management are exclusive to the highest tier. For this even managing just a few users and their permission and settings is a real pain as long as you're not willing to upgread to the highest tier"
Verified Reviewer, CPO, Food & Beverages, Capterra
Datenschutzkontrollen kosten am meisten. Die Datenmaskierung von Zendesk, die Namen, E-Mail-Adressen und Telefonnummern von Endnutzern vor einer Rolle verbirgt, steckt im Add-on Advanced Data Privacy and Protection, das nur an Enterprise-Tarife verkauft wird, zu einem nicht veröffentlichten Preis (Zendesk ADPP). Dasselbe Add-on enthält das Zugriffsprotokoll, das 90 Tage lang festhält, wer welche Tickets angesehen hat.

Meine ehrliche Einschätzung: Wenn Berechtigungen pro Rolle ein Muss sind und du kein Geld für Zendesk Enterprise hast, sind Freshdesk Pro und Zoho Desk Professional die günstigsten vollständigen Varianten in diesem Vergleich. Wenn du Zendesk bereits in Suite Professional (115 $) nutzt, bringen dich Gruppen mit Nur-zugewiesen-Zugriff, eine kurze Admin-Liste und IP-Beschränkungen ein gutes Stück weit. Sieh dir meine Aufschlüsselungen zu Zendesk-Preisen und Freshdesk-Preisen an, bevor du nur wegen der Rollen upgradest.
Die Rollen, die ich für ein typisches Support-Team einrichten würde
Die meisten Teams brauchen fünf Zugriffsformen, nicht fünfzehn. Von diesem Setup würde ich ausgehen.
| Rolle | Ticketzugriff | Darf | Darf nicht |
|---|---|---|---|
| Agent an vorderster Front | Seine Gruppen | Antworten, taggen, innerhalb der Gruppe zuweisen, Makros nutzen | Tickets löschen, Daten exportieren, Endnutzer bearbeiten, Geschäftsregeln verwalten |
| Teamleiter | Alle Tickets | Alles, was ein Frontline-Agent darf, plus Berichte, Ansichten und Makros für das Team | Abrechnung, Nutzerverwaltung, API-Token |
| Externer oder ausgelagerter Agent | Nur zugewiesen oder eine Gruppe | Antworten in der Warteschlange, für die er beauftragt ist | Export, Massenaktionen, vollständige Zahlungs- oder Identitätsdetails einsehen |
| Light-Platz für andere Teams | Ihre Gruppen | Lesen, interne Notizen hinterlassen | Kunden antworten, Ticketfelder ändern |
| Admin | Alle | Einstellungen, Nutzer, Integrationen | Nichts ist eingeschränkt, weshalb es zwei davon geben sollte |
Auf die Zeile der externen Agenten würde ich die meiste Zeit verwenden. Nachdem Coinbase im Mai 2025 offengelegt hatte, dass Support-Mitarbeiter im Ausland bestochen worden waren, um Kundendaten abzuziehen, kehrte der Hacker-News-Thread immer wieder zum selben Prinzip zurück:
"That's not how front line support agent access should work. You get access based on active cases you are working on, not the keys to the kingdom because you might need to support a member at some future point in time."
Ein anderer Kommentator, der ein Admin-Panel für ein Zahlungsunternehmen mit PCI Level 1 gebaut hat, beschrieb die Kontrollen, die sie einführten, als sie außerhalb der USA einstellten: „logging, monitoring and also rate-limiting (ask for manager to approve if more than 5 full details requests, etc.)“ (vasusen, Hacker News). Dieser letzte Teil, Freigabe ab einem Schwellenwert, ist dasselbe Muster, auf das ich bei der KI zurückkomme. Wenn du mit einem BPO arbeitest, behandeln meine Leitfäden zum Auslagern des Kundenservice und zum Wissenstransfer an Offshore-Support den Rest des Setups.
Für die Light-Zeile nimm den günstigsten Lese-und-Kommentar-Platz, den dein Helpdesk anbietet. Zendesk enthält bis zu 100 Light Agents in Suite Professional (Light-Agent-Plätze), Freshdesk-Collaborators können nicht öffentlich antworten oder Ticketeigenschaften bearbeiten (Freshdesk-Collaborators), und die Nur-Lese-Plätze von HubSpot sind in bezahlten Tarifen kostenlos und unbegrenzt (HubSpot-Plätze).
Entwickler und Finanzleute, die nur einen Verlauf lesen und eine Notiz hinterlassen müssen, brauchen keine volle Agentenlizenz, wie ich in teamübergreifende Support-Eskalation beschrieben habe.
Offboarding: Wo Zugriff übrig bleibt
Zugriffskontrolle scheitert meist am Ausgang, nicht am Eingang. Jeder Helpdesk lässt dich einen Nutzer entfernen. Unterschiedlich ist, was mit seinen Tickets, seinen Automatisierungen und deiner Rechnung passiert.
| Helpdesk | Optionen zum Entfernen | Was mit offenen Tickets passiert | Abrechnung des Platzes |
|---|---|---|---|
| Zendesk | Auf Endnutzer herabstufen, dann sperren | Gehen zurück an die Gruppe | Wird weiter berechnet, bis du das Abonnement änderst |
| Freshdesk | Deaktivieren oder löschen | Gehen in die nicht zugewiesene Warteschlange | Platz wird beim Deaktivieren frei |
| Gorgias | Nur löschen | Nicht zugewiesen; seine Statistiken werden gelöscht | Nicht pro Agent berechnet |
| Help Scout | Nur löschen | Gehen an Unassigned; vor dem Löschen mit einem Workflow neu zuweisen | Nicht angegeben |
| Front | Sperren oder löschen | Konversationen in geteilten Posteingängen werden nicht mehr zugewiesen | Lizenz bleibt bis zur nächsten Vertragslaufzeit |
| Zoho Desk | Deaktivieren oder löschen | Du wählst, wer übernimmt | Lizenz wird nicht gekündigt |
| HubSpot | Deaktivieren, dann entfernen | Bleiben zugewiesen, bis er entfernt wird | Platz zuerst freigeben |
Quellen: Zendesk, Freshdesk, Gorgias, Help Scout, Front, Zoho Desk, HubSpot.
Drei Fallstricke solltest du vor dem letzten Arbeitstag kennen:
- Die Reihenfolge zählt bei Help Scout. Um die Konversationen eines Ausscheidenden einer bestimmten Person zu übergeben, führst du zuerst einen Workflow aus, denn „There is no way to do this after the user has been deleted“ (Help Scout).
- Integrationen brechen mit der Person weg. Zoho Desk sagt, dass Integrationen eines deaktivierten Agenten nicht mehr funktionieren, bis ein Admin sie neu autorisiert, und Zendesk warnt, dass Apps, die mit den Zugangsdaten des Ausscheidenden konfiguriert wurden, ausfallen können. Wisse immer, unter wessen Login deine Integrationen laufen, auch bei deiner KI.
- Daten gehen mit. Wird ein Zendesk-Agent herabgestuft, verschwinden seine CSAT-Daten und persönlichen Makros, und das Löschen eines Gorgias-Nutzers löscht seine Statistiken. Exportiere vorher, was du brauchst.
Das leisere Problem ist, dass sich niemand erinnert, wie die Berechtigungen eingerichtet wurden. Ein Zendesk-Nutzer schrieb im April 2026:
"We had some turnover in IT so no one who set up Zendesk/my account for our team are here still and I can't figure out how to add it as an option for them."
Halte das Rollen-Setup schriftlich fest und lies dein Audit-Log einmal pro Quartal. Zendesk speichert sein Log in Enterprise unbegrenzt, mit Akteur, IP-Adresse und Aktivitätstyp für jede Änderung (Zendesk-Audit-Log). Mein Leitfaden zum Zendesk-Audit-Log enthält die Variante Feld für Feld.

Bei Gorgias speichert das Audit-Log Ereignisse über 12 Monate. Für Saisonkräfte auf befristeten Plätzen behandelt mein Beitrag zum Onboarding von Saison-Support die Regeln pro Helpdesk.
Dein KI-Agent braucht auch eine Rolle
Hier überspringen die meisten Zugriffsprüfungen etwas. Ein KI-Support-Agent liest Tickets, durchsucht deine Wissensdatenbank und antwortet, taggt, schließt und erstattet in vielen Setups auch selbst. Er ist ein Teammitglied mit den schnellsten Händen im Haus und wird oft von demjenigen eingerichtet, der an dem Nachmittag gerade Admin-Rechte hatte.
Die Dokumentation der Anbieter zeigt, wie uneinheitlich das heute ist:
- Zendesk: Jeder Support-Admin ist standardmäßig Client-Admin der KI-Agenten (Zugriff auf Zendesk-KI-Agenten). Der kundenseitige KI-Agent beachtet Nutzersegmente, der agentenseitige Auto Assist dagegen nicht, wie oben beschrieben.
- Freshdesk: Zum Erstellen von KI-Agenten ist Administratorzugriff nötig, und der KI-Agent lernt nur aus Artikeln, die für alle Nutzer sichtbar sind, eingeschränkte Inhalte bleiben also komplett draußen (Freshdesk-Wissensquellen).
- Gorgias: Nur Leads und Admins verwalten den AI Agent, aber jede Rolle sieht seine Antworten (Gorgias-Berechtigungen).
- HubSpot: Der Customer Agent braucht die Berechtigung „Customer agent editor“, und einmal erstellt, „it can't be deleted“, er kann nur pausiert werden (HubSpot Customer Agent).
- Front: KI-Einstellungen gibt es nur mit der Voreinstellung Workspace-Admin, nicht als eigene Berechtigung (Front-Teammitgliedergruppen).
Keiner der sieben geprüften Anbieter dokumentiert, ob sein KI-Agent den Ticketzugriff eines einzelnen Agenten beachtet. Die sicherste Annahme ist also, dass die KI sieht, was ihre Verbindung sieht, und dass du das an der Verbindung steuerst.
Guten Rat gab es in einem r/AI_Agents-Thread darüber, Agenten Zugriff auf Kundendaten zu geben:
"You should treat an agent like you would any user: limit access via end points and only give them access to the endpoints they absolutely need. So avoid full/broad access as much as possible."
Das deckt sich mit dem, was ich von Käufern höre. Ein CX-Leiter einer DTC-Nahrungsergänzungsmarke auf Gorgias und Shopify mit etwa 7,000 Tickets im Monat sagte es in einem Verkaufsgespräch mit eesel klar:
"I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
Ich denke den Zugriff eines KI-Agenten deshalb in drei getrennten Reglern und dann einer Berechtigungsstufe pro Aktion.

- Wissen. Verbinde nur die Quellen, die er braucht. Wenn Agenten in einem Bereich die Tickets eines anderen Bereichs nicht sehen können, sollte auch die KI, die den einen Bereich beantwortet, nicht daraus lernen.
- Aktionen. Liste jede Aktion auf und lege für jede fest: automatisch, Freigabe erforderlich oder aus. Eine Bestellung nachzuschlagen ist risikoarm. Eine Antwort zu senden oder eine Erstattung auszulösen ist es nicht, zumindest nicht, bevor du gesehen hast, dass die KI das richtig macht.
- Netzwerk. Wenn die KI deine eigenen APIs aufruft, erlaube nur die Domains, die sie braucht, und halte Zugangsdaten aus den Händen des Modells.
So ist das KI-Helpdesk-Teammitglied von eesel aufgebaut. Jede Aktion wird pro Agent auf Auto, Freigabe erforderlich oder Deaktiviert gesetzt, und Freigaben laufen nach einem Timeout nie von allein durch. Nur Workspace-Owner und -Editoren können freigeben, und ein Viewer kann die Arbeit des Agenten lesen, aber der Agent führt in seinem Namen keine Schreibaktionen aus (eesel-Kontorollen). Ausgehende Aufrufe erreichen nur Domains, die du unter Network Access hinzufügst, und der Agent „only ever sees the name of the header, never its value“, sodass API-Schlüssel nicht ins Modell gelangen.

Dieselben Berechtigungen gelten im Terminal. Die eesel CLI steuert denselben Agenten wie das Dashboard, und eesel integrations zendesk actions listet jede Zendesk-Aktion mit ihrer Freigabeeinstellung auf, sodass du die Berechtigungen eines Agenten mit einem Befehl prüfen kannst oder einen Coding-Agenten wie Claude Code das tun lässt. Schreibzugriffe über die CLI folgen denselben Regeln, und Schreibaktionen eines Viewers werden immer für einen Editor zurückgehalten. --dry-run zeigt den genauen Aufruf, den ein Schreibzugriff ausführen würde, bevor irgendetwas gesendet wird.
Die Dokumentation von eesel rät, überwacht zu starten: Antworten und alles Unumkehrbare auf Freigabe erforderlich, Erstattungen und Stornierungen dauerhaft hinter einer Freigabe. Die meisten Teams beginnen mit internen Notizen und übergeben mehr, sobald sich der Agent bewährt, genau der Weg, den auch ein neuer Mitarbeiter geht. Wenn du die menschliche Seite dieses Wegs möchtest, führt mein Leitfaden zum Onboarding eines KI-Support-Agenten hindurch, und KI-Eskalation behandelt die Übergaberegeln.
Eine ehrliche Einschränkung auf der eesel-Seite: Die PII-Schwärzung läuft auf vergangenen Tickets, bevor sie indexiert werden, aber wenn der Agent ein aktuelles Zendesk-Ticket abruft, um eine Antwort zu entwerfen, erreicht der rohe Ticketinhalt das Modell. Wenn das Maskieren von Kartennummern an dieser Stelle ein Muss ist, kombiniere eesel mit der eigenen Schwärzung deines Helpdesks, etwa der Zendesk-Ticketschwärzung.
Eine Checkliste für die vierteljährliche Zugriffsprüfung
Zugriff driftet. Menschen wechseln das Team, externe Kräfte laufen aus, und jemand bekommt Admin-Rechte „nur für diesen Nachmittag“. Ich würde Folgendes jedes Quartal durchgehen:
- Zähle deine Admins. Zwei reichen für die meisten Teams. Jeder zusätzliche Admin sieht jedes Ticket.
- Vergleiche Plätze mit der Personalliste. Wer gegangen ist und noch einen Platz hält, ist Sicherheitslücke und Kostenposition zugleich, besonders bei Zendesk, Front und Zoho Desk, wo der Platz weiter berechnet wird.
- Prüfe den Zugriffsbereich bei Plätzen für externe und ausgelagerte Kräfte. Nur zugewiesen oder eine Gruppe, ohne Export.
- Lies das Audit-Log auf Rollenänderungen, Exporte und Anmeldungen von neuen IP-Adressen.
- Prüfe deine KI-Agenten wie jeden anderen Platz. Welche Quellen, welche Aktionen auf Auto, unter wessen Login läuft die Verbindung. Stelle deinem Setup für KI bei Systemzugriffsanfragen, falls du eines hast, dieselben Fragen.
Wenn du parallel die Compliance verschärfst, sind meine Checkliste zu SOC 2 und DSGVO für Support-Chatbots und der Überblick zu Zendesk-Sicherheit gute nächste Lektüre.
eesel als eingegrenztes KI-Teammitglied testen
Wenn dein Helpdesk Zendesk, Freshdesk, Gorgias, Help Scout oder Front ist und der KI-Platz derjenige ist, bei dem du dir am unsichersten bist, ist das KI-Helpdesk-Teammitglied von eesel genau dafür gebaut. Es tritt deiner bestehenden Warteschlange über die Zendesk-Integration bei (oder Freshdesk und Gorgias), liest nur die Quellen, die du verbindest, und führt nur die Aktionen aus, die du aktivierst. Ein Tool zu verbinden ändert von allein nichts: Keine Automatisierung startet und keine Antwort wird gesendet, bis du einen Trigger hinzufügst.

Jedes Ticket, das es anfasst, erscheint in Activity mit dem, was es gesucht hat, was es getan hat, wer es freigegeben hat und warum, und vor dem Go-live spielt der Simulations-Skill deine echten vergangenen Tickets noch einmal ab, damit du seine Antworten vorher siehst. Die Preise enthalten in jedem Tarif unbegrenzt viele Agenten und Plätze, beginnend kostenlos mit 100 Credits und danach ab $299 im Monat für 500 Credits, sodass zusätzliche Prüfer, die die KI beobachten, nicht jeweils eine Lizenz kosten. Was es noch nicht ist: SOC 2 Type II zertifiziert (das läuft laut Sicherheitsseite), und SSO mit erzwungener 2FA ist ein Add-on ab $199 im Monat. Wenn du eine KI willst, die bei internen Notizen beginnt und sich nach oben arbeitet, teste eesel kostenlos.