Multi-Client-Helpdesk: So betreibst du den Support für mehrere Kunden oder Marken aus einem Helpdesk

Was ein Multi-Client-Helpdesk ist und wer ihn braucht

Ein Multi-Client-Helpdesk ist ein einzelner Helpdesk-Account, der so eingerichtet ist, dass ein Support-Team mehrere getrennte Unternehmen betreuen kann, jedes mit eigenen Kunden, eigener Tonalität und eigenen Regeln. Jeder Helpdesk-Anbieter nennt den „Kunden“ anders: eine Marke in Zendesk und Deskpro, ein Produkt oder Workspace in Freshdesk, ein Postfach in Help Scout, ein Workspace in Front, ein Shop in Gorgias, eine Abteilung in Zoho Desk, ein Kunde in HaloPSA.

Vier Arten von Teams betreiben einen:

• Agenturen, die Support als Dienstleistung an mehrere Marken verkaufen, oft neben Marketing- oder Entwicklungsarbeit. Mein Beitrag zu KI-Support für Agenturen behandelt dieses Geschäftsmodell.
• Ausgelagerte Support-Teams (BPOs), die die Warteschlange für Kundenunternehmen besetzen. Siehe meinen Leitfaden zum Auslagern des Kundenservice.
• MSPs, die IT-Support für viele Kundenunternehmen betreiben, meist auf einem PSA-Tool. Mein Überblick über MSP-Ticketsysteme geht darauf ausführlich ein.
• Unternehmen mit mehreren Marken, bei denen ein Support-Team hinter mehreren Shops oder Produktlinien steht.

Ich habe die letzten Jahre die Helpdesk-Integrationen hinter eesel gebaut, und Setups mit mehreren Marken haben mir am meisten beigebracht. Anfang dieses Jahres stießen ein Gorgias-Team mit 3 Marken, ein Zendesk-Team, das zwei Agenten mit unterschiedlichen Artikelsätzen brauchte, und ein Zendesk-Setup mit getrennten Marken bei eesel an dieselbe Wand: Die Konfiguration pro Marke war allein zu schwer umzusetzen, und zwei Nutzer eines Accounts sind deswegen abgesprungen. Deshalb wird jetzt jede Zendesk-Marke einzeln mit eesel verbunden und kann auf einen eigenen Agenten zeigen. Heute betreibt ein Wellness-Unternehmen mit mehreren Marken auf Zendesk fünf dedizierte KI-Agenten auf eesel, einen pro Marke, die jeweils aus den eigenen Tickets der Marke lernen.

Die Lehre aus diesen Einführungen ist die These dieses Beitrags. Das Postfach zu trennen dauert einen Nachmittag. Die Kunden voneinander getrennt zu halten, ist das eigentliche Projekt.

Das Postfach ist der einfache Teil

Jeder Helpdesk, den ich mir angesehen habe, kann jedem Kunden eine eigene Eingangstür geben. Das Problem ist der Raum dahinter.

Das lässt sich in den meisten Tools sauber pro Kunde trennen:

• E-Mail-Adresse und Postfach. Zendesk legt eine Support-Adresse pro Marke an, Help Scout gibt jedem Postfach ein eigenes gemeinsames Postfach, und Gorgias gibt jedem Shop eine eigene Support-E-Mail und Signatur.
• Help Center. Jede Zendesk-Marke kann ein eigenes Help Center haben, jedes Freshdesk-Produkt bekommt ein Portal, und jede Zoho-Desk-Abteilung kann im Enterprise-Plan ein Portal im eigenen Branding bekommen.
• SLA-Ziele. Help Scout legt SLA-Richtlinien pro Postfach fest, Deskpro pro Marke, HaloPSA pro Standort.
• Gespeicherte Antworten und Makros. Help Scout begrenzt gespeicherte Antworten pro Postfach; Gorgias hat markenspezifische Makros und Regeln.

Und das bleibt tendenziell geteilt, direkt aus der Dokumentation der Anbieter:

Nichts davon ist ein Fehler dieser Produkte. Sie wurden für ein Unternehmen mit mehreren Marken gebaut, und das ist ein anderes Vertrauensmodell als eine Agentur, die die Daten von zehn voneinander unabhängigen Kunden hält. Du musst nur wissen, welches Modell du kaufst.

Die drei Wege, wie ein Multi-Client-Setup Daten durchsickern lässt

Wenn bei einem Multi-Client-Helpdesk etwas schiefgeht, ist es fast immer eines von drei Dingen. Ich würde dein Setup rückwärts von diesen Punkten aus entwerfen.

1. Eine Antwort geht von der falschen Marke raus

Das bemerken Kunden, weil ihr Endkunde eine E-Mail bekommt, die vom Unternehmen eines anderen unterschrieben ist. Die Ursachen sind banal. In Zendesk hat der Account nur eine E-Mail-Vorlage, sodass markenspezifische E-Mails separate Trigger brauchen, und „du hast nur einen Satz Trigger“, den du mit Markenbedingungen eingrenzen musst. Die Marke einer Support-Adresse lässt sich später nicht ändern; du löschst sie und legst sie neu an. Trigger können ein Ticket sogar einem Agenten außerhalb seiner Marke zuweisen, der dann auf einen Zugriffsfehler stößt.

Es ist nicht nur ein Markenproblem. Ein MSP auf Reddit beschrieb, wie ein Kunde die Ticket-E-Mail eines anderen Anbieters weiterleitete, die zu einer Ticketnummer in seinem PSA passte:

„was dazu führte, dass die Ticketnummer im E-Mail-Betreff ein geschlossenes Ticket eines anderen Kunden wieder öffnete und unser Kunde sich dann wunderte, warum wir nie nachgefasst haben“

u/Free-Neighborhood389, r/Autotask

Die Lösung ist unspektakulär und funktioniert: eine Support-Adresse pro Kunde, Markenbedingungen bei jedem Trigger, der E-Mails versendet, und nach jeder Änderung ein Testticket an die Adresse jedes Kunden.

2. Ein Kundendatensatz wird über Kunden hinweg geteilt

Wenn zwei deiner Kunden dieselben Endkunden haben (üblich bei einem BPO, das mehrere Marken eines Mutterkonzerns bedient, oder bei einem MSP, dessen Kundenmitarbeiter zwischen Unternehmen wechseln), existiert der Kontaktdatensatz meist nur einmal im Account. Front warnt, dass benutzerdefinierte Felder geteilt werden, wenn derselbe Kontakt in zwei Workspaces schreibt. Die markenbezogenen Kontakteigenschaften von HubSpot sind „für alle Kontakte verfügbar, nicht nur für die der Marke zugeordneten Kontakte“ (HubSpot-Dokumentation).

Für die meisten Unternehmen mit mehreren Marken ist das in Ordnung, sogar nützlich. Für eine Agentur, die die Daten voneinander unabhängiger Kunden hält, ist es das stärkste Argument für getrennte Accounts.

3. Die KI antwortet aus dem Wissen des falschen Kunden

Das ist die neueste Lücke und die, die mir am meisten Sorgen macht, weil niemand jede KI-Antwort liest. Wenn ein KI-Agent die Help Center von fünf Kunden sehen kann, gibt er früher oder später die Rückerstattungsrichtlinie von Kunde A an den Endkunden von Kunde B weiter.

Die eigene KI jedes Helpdesks geht damit unterschiedlich um. Zendesk bindet einen KI-Agenten an das Help Center einer Marke, erlaubt nur einen aktiven KI-Agenten pro Kanal und empfiehlt für E-Mail einen nach Marke zugeschnittenen Agenten statt mehrerer. Bei Freshdesk kann jeder Freddy-KI-Agent wählen, aus welchem Portal er lernt, aber Website-Quellen sind auf 25 pro Account begrenzt, sodass 10 Kunden mit je 3 URLs nicht passen (Freshdesk-Dokumentation). Die KI-Seite behandle ich weiter unten ausführlich.

Ein Support-Leiter, der Zendesk für zwei Regionen einrichtete, stieß auf Reddit genau darauf:

„Zendesk AI zieht Wissen aus den Help Centern, die mit derselben Marke verknüpft sind, unabhängig von Sprache oder Region. Wenn also ein brasilianischer Kunde etwas fragt, stützt die KI ihre Antwort möglicherweise auf alle zugehörigen Inhalte, sogar auf Artikel, die gerade erst für die USA erstellt wurden.“

u/velvetvortext, r/Zendesk

Seine Alternative war eine Marke pro Region mit getrennten Help Centern und KI-Konfigurationen. Für ein Multi-Client-Setup ist das die einzige Variante, der ich vertrauen würde.

Wie jeder Helpdesk mit mehreren Kunden umgeht

Hier der direkte Vergleich. Die Preise gelten pro Agent und Monat bei jährlicher Abrechnung laut Preisseite des jeweiligen Anbieters, Stand Oktober 2026, und „harte Trennwand“ bedeutet eine Einstellung, die verhindert, dass ein Agent die Tickets eines anderen Kunden sieht, nicht einen Ansichtsfilter.

Meine Einschätzung: Zoho Desk und Help Scout sind die günstigsten echten Trennwände, Freshdesk Workspaces sind die tiefste, und Zendesk ist am leistungsfähigsten, verlangt für die Trennwand aber Enterprise-Preise. Unten steht, was du in jedem davon tatsächlich anklickst.

Zendesk

Zendesk nennt es Multibrand, verwaltet unter Admin Center > Account > Brand management. Suite Growth und Professional bekommen 5 Marken und 5 Help Center; Suite Enterprise und Enterprise Plus bekommen 300. Die aktuelle Seite Zendesk-Preise listet Suite Team mit einem Help Center, sodass Suite Professional für $115 der günstigste öffentliche Plan mit mehr als einem ist.

Mehrere Marken aus einer Warteschlange zu betreiben funktioniert gut, sobald es eingerichtet ist. Ein Zendesk-Reviewer auf G2 mochte es, dass „ein Team aus derselben Warteschlange arbeitet“, über zwei Marken hinweg, mit der ehrlichen Einschränkung, die jeder Admin mit mehreren Marken kennt:

„Trigger und Automatisierungen über beide Marken hinweg konsistent zu halten, hat mehr Sorgfalt gekostet als erwartet; ich habe einmal eine Regel für eine Marke gebaut und völlig vergessen, sie für die andere zu spiegeln“

Alex M., Zendesk-Review auf G2

Der Haken ist der Zugriff. Abteilungsbereiche, die Agenten auf die Marken beschränken, in denen sie Mitglied sind, brauchen Customer Service Suite Enterprise oder Support Enterprise. Neue Teammitglieder treten standardmäßig allen Marken bei, und Admins „müssen Mitglieder aller Marken sein“. In Growth und Professional ist der Workaround eine Gruppe pro Marke plus „Tickets in ihren Gruppen“ im Profil jedes Agenten. Mein Beitrag zum Zendesk-Multi-Brand-Setup enthält die Klick-für-Klick-Anleitung.

Freshdesk

Freshdesk hat zwei Ebenen. Multiple Products gibt jedem Kunden ein Postfach, ein Portal und eine Wissensdatenbank, bis zu 5 im Pro-Plan ($55) und unbegrenzt im Enterprise-Plan ($89). Aber „Agenten sehen in ihrer Ticketansicht Tickets aller Produkte“, solange du keine Routing- und Ticket-Scope-Regeln ergänzt.

Die neuere Ebene sind Workspaces: bis zu 30 unabhängige Support-Abläufe in einem Account, jeder mit eigenen Agenten, Gruppen, SLAs, Automatisierungen, E-Mail, Portalen und einer eigenen Wissensdatenbank. Sie ist nur im Enterprise-Plan verfügbar und wird auf Anfrage aktiviert. Eine Agentenlizenz deckt jeden Workspace ab, dem der Agent angehört, was für ein BPO mit geteiltem Personal wichtig ist.

Zwei Workspace-Details, die du vor der Entscheidung kennen solltest: Ein Workspace lässt sich nach dem Anlegen nicht löschen, und Freshdesk selbst sagt, dass getrennte Abrechnung oder rechtliche Eigentümerschaft für separate Accounts sprechen können. Meine Aufschlüsselung zu Freshdesk AI behandelt die Plan-Beschränkungen von Freddy.

Help Scout

Die Einheit bei Help Scout ist das Postfach, und es hat den agenturfreundlichsten Standard, den ich gefunden habe: Ein Nutzer hat „nur Zugriff auf die festgelegten Postfächer“, in jedem Plan. Pläne enthalten 2, 5 oder 10 Postfächer, Extras kosten $10 im Monat, und Docs-Sites (Help Center) gibt es 2, 3 oder 5 mit Extras für $20. Gespeicherte Antworten und SLAs liegen beide pro Postfach.

Für KI legst du pro Kunde einen KI-Agenten mit eigenen Wissensquellen an und verknüpfst ihn dann mit dem Beacon (Chat-Widget) dieses Kunden. AI Answers kostet $0.75 pro Lösung auf der Help-Scout-Preisseite.

Die Lücke: Docs sind nicht abgeschottet. Einen Nutzer auf das Postfach von Kunde A zu beschränken, hindert ihn nicht daran, das Help Center von Kunde B zu bearbeiten. Wenn deinen Kunden wichtig ist, wer ihre Artikel anfasst, halte die Autorenrechte in einer kleinen Gruppe. Mehr dazu in meinem Beitrag zu Help-Scout-Alternativen.

Front

Front teilt Kunden in Workspaces auf, jeder mit „eigenen Workflows, Analysen und Ressourcen wie Tags oder Nachrichtenvorlagen“. Starter bekommt 1, Professional ($65) bis zu 5, Enterprise unbegrenzt. Jedes Teammitglied bekommt pro Workspace eine Workspace-Rolle: Kein Zugriff, Admin oder Mitglied.

Die Wissensquellen der Front-KI liegen in den Workspace-Einstellungen, ein Workspace pro Kunde ist also auch der Weg, jedem Kunden sein eigenes KI-Wissen zu geben. Pläne werden auf Organisationsebene festgelegt, du kannst also nicht einen Kunden auf Starter und einen anderen auf Enterprise setzen. Mein Beitrag zu Front AI behandelt die Autopilot-Preise, die bei $0.05 pro Konversation beginnen.

Gorgias

Gorgias passt natürlich zu einer Agentur, die mehrere E-Commerce-Shops betreibt, weil es pro Ticket statt pro Agent abrechnet: „Ob du einen Shop hast oder 30, du kannst sie alle in einem einzigen Gorgias-Helpdesk verwalten.“ Jeder Shop bekommt eigene Kanäle, Support-E-Mail, Makros und Regeln, und „du bekommst für jeden verbundenen Shopify-Shop einen eigenen KI-Agenten“, mit bis zu 100 Guidance-Einträgen pro Shop.

Zwei Einschränkungen aus der Dokumentation: Der KI-Agent pro Shop ist auf Shopify-Shops ausgelegt, und ich habe keine Einstellung gefunden, mit der sich ein Agent auf die Tickets eines Shops beschränken ließe. Das Löschen eines Shops „entfernt alle zugehörigen Integrationen und Daten“, also solltest du einen Kunden bewusst offboarden. Mein Leitfaden zum Verwalten mehrerer Marken in Gorgias geht weiter ins Detail.

Zoho Desk, HubSpot, Deskpro und HaloPSA

• Zoho Desk nutzt Abteilungen: bis zu 10 im Professional-Plan ($23), 50 im Enterprise-Plan ($40) und bis zu 500 mit einem Add-on. Nach der Zuweisung kann ein Agent „nur die Tickets einsehen und aufrufen, die zu dieser Abteilung gehören“ (Zoho-Dokumentation). Help Center im eigenen Branding pro Abteilung brauchen Enterprise, und der Wechsel zu einem getrennten Login pro Marke lässt sich ohne den Zoho-Support nicht rückgängig machen. Mein Beitrag zu Zoho Desk AI behandelt Zia.
• HubSpot Service Hub behandelt mehrere Marken über HubSpot Brands, ein Add-on für $1,000 im Monat pro Marke, das nur auf Marketing Hub Enterprise verkauft wird. Es schaltet einen Kundenagenten pro Marke frei; mein Beitrag zu HubSpot-AI-Alternativen behandelt günstigere Wege. Die eigene Übersicht von HubSpot sagt, dass Brands nicht für „deutlich unterschiedliche Geschäfts-/Datenmodelle“ geeignet sind, was auf die meisten Agenturen zutrifft.
• Deskpro gibt jeder Marke ein eigenes Help Center, eigene SLA-Ziele und eigenes Reporting und sagt, ein Agent von Marke A „hat keinen Einblick in Tickets von Marke B, sofern nicht ausdrücklich gewährt“. Die Preisseite begrenzt Help Center mit eigenem Branding je nach Plan auf 3, 10 und unbegrenzt.
• HaloPSA ist für MSPs gebaut: Kunden, Standorte und Nutzer, SLAs pro Standort, KB-Listen pro Kunde und Kundenbeschränkungen pro Agent, zu einem Preis von £69 pro Agent, wobei Kunden und Portalnutzer kostenlos sind.

Marken in einem Account oder getrennte Accounts?

Das ist die Frage, die ich beantworten würde, bevor ich irgendeine Einstellung anfasse, weil sie teuer rückgängig zu machen ist. Zwei Fragen entscheiden.

1. Braucht der Kunde eine eigene Abrechnung oder die rechtliche Eigentümerschaft an den Daten? Wenn ja, gib ihm einen eigenen Account. Der Workspaces-Leitfaden von Freshdesk selbst weist in diese Richtung, und es ist das einzige Setup, bei dem geteilte Kontaktdatensätze keine Frage mehr sind.
2. Dürfen Agenten die Tickets anderer Kunden unter keinen Umständen sehen können? Wenn ja, plane das Budget für den Plan mit harter Trennwand ein: Enterprise in Zendesk oder Freshdesk, jeden Plan in Help Scout, Abteilungszuweisung in Zoho Desk. Ein Ansichtsfilter ist keine Trennwand.

Wenn beide Antworten nein lauten, ist eine Marke innerhalb eines Accounts günstiger, lässt sich kundenübergreifend leichter besetzen und gibt dir einen Ort für das Reporting. Die meisten Unternehmen mit mehreren Marken landen hier. Die meisten Agenturen mit voneinander unabhängigen Kunden und strikten Verträgen nicht.

Die zweite Frage ist die, die Leute überrascht. Ein Zendesk-Admin, dessen Partner die Daten ihrer vermittelten Kunden von Offshore-Agenten fernhalten wollten, stellte fest, dass die In-App-Tools nicht so weit reichten:

„Ich finde keine einfache Standardlösung ... Marken und Organisationen reichen nicht aus. Eine zweite ZD-Instanz könnte es aber“

u/Glittering-Face-1545, r/Zendesk

Wenn im Vertrag eines Kunden „nur diese Agenten, nur diese Daten“ steht, beginne mit getrennten Accounts und arbeite rückwärts. Mein Beitrag zu KI für Offshore-Support behandelt die Aufteilung zwischen Onshore und Offshore genauer.

So richtest du einen Multi-Client-Helpdesk in 7 Schritten ein

Sobald du dich für einen oder mehrere Accounts entschieden hast, würde ich in dieser Reihenfolge vorgehen. Die Schritte 1 bis 3 verhindern die Antwort von der falschen Marke; die Schritte 4 bis 7 halten das Service-Level jedes Kunden ehrlich.

1. Lege pro Kunde eine Kundeneinheit an und benenne sie nach dem Kunden. Je eine Marke, ein Produkt, ein Postfach oder ein Workspace. Nutze den Namen, den der Kunde nach außen verwendet, denn er erscheint in E-Mails und Help-Center-Kopfzeilen.
2. Gib jedem Kunden eine eigene Support-Adresse und Signatur. Füge dann die Markenbedingung zu jedem E-Mail-versendenden Trigger oder jeder Ticket-Routing-Regel hinzu. Sende ein Testticket an jede Adresse.
3. Ändere den Standardzugriff, bevor du Agenten hinzufügst. In Zendesk treten neue Teammitglieder jeder Marke bei, sofern du das nicht änderst. Entscheide pro Agent, welche Kunden er bearbeitet, und halte die Zahl der Admins so klein wie möglich, da Admins in den meisten Tools alles sehen.
4. Lege SLA-Ziele pro Kunde aus dem Vertrag fest. Kunden bezahlen für unterschiedliche Reaktionszeiten. Nutze SLA-Richtlinien pro Kunde (Help Scout pro Postfach, Zendesk mit einer Markenbedingung, Freshdesk pro Workspace). Mein Leitfaden zu SLA-Best-Practices behandelt Ziele, und Zendesk-SLA-Bedingungen behandelt den Markenfilter.
5. Baue pro Kunde eine eigene Wissensdatenbank auf. Ein Help Center pro Kunde, betreut von jemandem, der diesen Kunden kennt. Eine gemeinsame Wissensdatenbank ist die Wurzel der meisten kundenübergreifenden Falschantworten, von Menschen wie von KI. Mein Beitrag zum Management von Wissensdatenbanken behandelt die Zuständigkeit.
6. Gib jedem Kunden einen eigenen KI-Agenten und teste ihn mit den vergangenen Tickets dieses Kunden. Niemals ein KI-Agent für mehrere Kunden. Mehr dazu im nächsten Abschnitt.
7. Berichte jeden Monat pro Kunde. Filtere nach der Kundeneinheit nach Volumen, erster Antwort, Lösung und CSAT, damit Abrechnung und Vertragsreviews auf denselben Zahlen beruhen. Versieh jedes Ticket bei der Erstellung mit dem Kunden als Tag, damit Berichte auch dann stimmen, wenn ein Ticket verschoben wird.

Wenn du Offshore- oder Schichtpersonal über Kunden hinweg einsetzt, behandeln meine Beiträge zu Follow-the-Sun-Support und Schichtübergabe im Support die Übergabeseite.

Wo KI passt, wenn jeder Kunde anders ist

KI ist der Bereich, in dem ein Multi-Client-Helpdesk am meisten gewinnt und am meisten riskiert. Der Volumenfall ist einfach: Ein E-Commerce-Betreiber mit mehreren Marken, der in einem Verkaufsgespräch mit eesel saß, bearbeitet über mehrere Marken hinweg 500+ Tickets am Tag, vor allem Rückerstattungen, Abmeldungen und Sendungsverfolgung. Diese Tickets sehen bei jedem Kunden gleich aus. Die Antworten nicht, denn jeder Kunde hat sein eigenes Rückgabefenster, seinen eigenen Versandpartner und seinen eigenen Ton.

Deshalb würde ich drei Regeln festhalten:

• Ein KI-Agent pro Kunde, nur mit dem Wissen dieses Kunden. Nicht ein Agent mit der Anweisung „prüfe, welche Marke das ist“.
• Aktionen pro Kunde. Kunde A erlaubt vielleicht automatische Rückerstattungen unter $50; Kunde B erlaubt keine. Die Berechtigung gehört an den Agenten des Kunden, nicht in einen gemeinsamen Prompt.
• Zuerst an der Historie jedes Kunden beweisen. Eine Einführung, die bei einem Kunden funktioniert, sagt nichts über den nächsten aus.

So lässt sich das auf eesel abbilden. Ich werde konkret, weil ich einen Teil davon gebaut habe.

Jeder Kunde bekommt in einem Workspace seinen eigenen Agenten. Ob du auf Zendesk, Help Scout oder Front bist: Jeder eesel-Plan enthält unbegrenzt viele Agenten und Seats, und Helpdesk-Agenten laufen unter einem Account, „jeder mit eigenem Wissen und eigenen Anweisungen“. Bei Zendesk gilt: „Jede Marke wird separat verbunden, und jede kann an einen anderen Agenten mit eigenen Triggern und Aktionen gehen“, und eesel importiert Tickets und Help-Center-Artikel nur von dieser Marke (eesel-Zendesk-Dokumentation). Freshdesk, Gorgias und Zoho Desk akzeptieren mehrere verbundene Accounts pro Workspace, wobei jede Automatisierung zu einem Account gehört. Ein Stolperstein, den ich beim Bauen gesehen habe: Melde dich zuerst als Agent der Marke, die du verbindest, bei Zendesk an, sonst leitet Zendesk dich auf deine Standardmarke, und die wird dann verbunden.

Wissen bleibt dort, wo du es hinlegst. Eine Integration lässt sich bei einem Agenten entfernen und bei anderen behalten. Wenn der Ticketverlauf eines Kunden keinen Agenten speisen soll, schalte dessen Ticket-Quelle ab; dem Agenten in seinen Anweisungen zu sagen, vergangene Tickets zu ignorieren, verhindert nicht, dass er daraus lernt. Deine Daten werden nur für deine eigenen Agenten verwendet und nicht zum Training der zugrunde liegenden Modelle genutzt (eesel-Sicherheitsdokumentation).

Aktionen gelten pro Agent. „Jede Aktion läuft von allein, fragt dich vorher oder bleibt aus. Du wählst pro Agent“ (eesel-Aktionsdokumentation). Die Rückerstattungsregel für Kunde A berührt Kunde B also nie.

Teste jeden Kunden, bevor er live geht. Der Simulation-Skill spielt echte vergangene Tickets erneut ab und vergleicht die Antworten des Agenten mit dem, was dein Team tatsächlich gesendet hat. Für ein BPO ist das ein Go-live-Check pro Kunde, den du dem Kunden zeigen kannst, und mein Leitfaden zur Fehleranalyse im Support behandelt, was du mit den Fehlern tun solltest. Die Dokumentation empfiehlt außerdem, jeweils eine Warteschlange oder eine Marke auf einmal einzuführen; alles außerhalb bleibt bei deinem Team und kostet nichts.

Automatisiere es per Skript, wenn du viele Kunden betreust. Wenn du alle paar Wochen einen neuen Kunden aufnimmst, lässt dich die eesel-CLI das vom Terminal aus erledigen. eesel agents create legt einen neuen Agenten für den neuen Kunden an, und jeder Befehl akzeptiert --agent <name>, sodass du die Anweisungen oder das Wissen eines Kunden aktualisieren kannst, ohne die anderen anzufassen. Setze EESEL_API_URL und EESEL_API_TOKEN, und dieselben Befehle laufen aus einem Skript oder CI-Job. Jeder Workspace ist außerdem ein MCP-Server, sodass ein Coding-Agent wie Claude Code oder Cursor dasselbe Setup steuern kann. Für eine Agentur, die Kunden jedes Mal gleich aufnimmt, macht das aus einer Checkliste ein Skript.

Die Preise werden über Kunden hinweg gebündelt. Die Preise von eesel sind ein monatlicher Credit-Plan mit festem Preis, bei dem ein Ticket oder Chat einen Credit kostet: Free mit 100 Credits, dann Teammate ab $299 für 500 Credits bis $1,899 für 5,000, ohne Seat- oder Plattformgebühr und mit optionalem Overage zu $0.80 pro Credit. Da Credits auf Workspace-Ebene liegen, nutzen sechs kleine Kunden einen Plan statt sechs Abos.

Was eesel nicht kann, damit du darum herum planen kannst: Es gibt derzeit kein Reseller- oder White-Label-Programm (eine Agentur mit 22 Workspaces über 10+ Kundenunternehmen hat eesel darum gebeten, und ich sage das lieber offen, als etwas anderes anzudeuten). Team-Rollen (Owner, Editor, Viewer) gelten für den ganzen Workspace, nicht für den Agenten eines Kunden. Wenn ein Kunde also einen eigenen Login mit eigenen Berechtigungen braucht, gib ihm einen eigenen Workspace. Und Anfang dieses Jahres sagte ein Support-Dienstleister für Ferienwohnungen, der eesel als Copilot nutzt, dem eesel-Team, dass seine Kunden „häufig Screenshots teilen“, die Agenten von Hand abtippen mussten. Wenn die Tickets deiner Kunden also bildlastig sind, teste das an einer Stichprobe, bevor du vollständig autonom gehst. Mein Beitrag zu White-Label-KI behandelt die Reseller-Frage allgemeiner.

eesel für deinen Multi-Client-Helpdesk testen

Wenn du den Support für mehrere Kunden oder Marken betreibst, gibt eesel jedem einen eigenen KI-Helpdesk-Teammate in einem einzigen Workspace. Verbinde jede Zendesk-Marke einzeln (oder mehrere Freshdesk-, Gorgias- oder Zoho-Desk-Accounts), trainiere jeden Agenten nur mit den Tickets und dem Help Center dieses Kunden, lege Aktionen und Ton separat fest und spiele seine vergangenen Tickets erneut ab, bevor er irgendjemandem antwortet. Der Test ist kostenlos mit 100 Credits, und jeder Plan enthält unbegrenzt viele Agenten, sodass dein nächster Kunde nichts kostet, bis seine Tickets eintreffen.

eesel testen