KI-Kundensupport für Marktplätze: Käufer-, Verkäufer- und Trust-Lanes

Warum scheitert ein einzelner Chatbot auf einem Marktplatz?

Ich baue die Integrationen und Aktionen, mit denen eesels Agenten aus anderen Systemen lesen können, deshalb dreht sich der Großteil meiner Woche um eine Frage: Was muss die KI sehen, und was darf sie ändern? In einem Shop mit einer einzelnen Marke ist die Antwort einfach. Auf einem Marktplatz teilt sie sich in zwei, denn die schreibende Person kann Käufer oder Verkäufer derselben Bestellung sein, und beiden stehen unterschiedliche Antworten zu.

Nimm ein Paket, das als zugestellt markiert ist, aber laut Käufer nie ankam. Der Käufer will eine Erstattung. Der Verkäufer will seine Auszahlung. Ein Bot, der auf ein einziges Help Center trainiert ist, zitiert entweder die Käuferrichtlinie gegenüber dem Verkäufer oder die Verkäuferrichtlinie gegenüber dem Käufer, und beides ist schlecht. Ebays eigene Geld-zurück-Garantie zeigt, wie viel Struktur hinter diesem einen Fall steckt: Der Verkäufer hat 3 Werktage zum Antworten, jede Seite kann zwischen 3 und 21 Werktagen eBay um ein Eingreifen bitten, und Bestellungen ab 750 $ brauchen eine Unterschriftsbestätigung als Zustellnachweis.

Ich habe das von innen gesehen. Im Mai 2026 bat uns ein großer Marktplatz für Essenslieferungen um zwei getrennte Wissensdatenbanken innerhalb eines Zendesk-Help-Centers, eine für Kunden und eine für Restaurants. Diese Anfrage ist das ganze Problem in einem Satz. Wir haben außerdem jahrelang KI-Agenten auf Live-Support-Queues gesetzt und zugesehen, wie selbstsicher klingende Bots falsche Antworten gaben, weshalb jeder eesel-Rollout inzwischen zuerst an historischen Tickets simuliert wird. Auf einem Marktplatz kann eine falsche Antwort dich auf beiden Seiten derselben Bestellung etwas kosten.

Welche Marktplatz-Tickets kann KI bearbeiten, und welche brauchen einen Menschen?

Ich sortiere Marktplatz-Tickets nach einem Test: Gibt es irgendwo in einem System eine einzige richtige Antwort? Wenn ja, kann die KI allein antworten. Wenn die Antwort davon abhängt zu beurteilen, wer recht hat, entscheidet ein Mensch, und die KI bereitet vor. Das ist der Kern eines guten Ticket-Routings auf einer zweiseitigen Plattform.

Die obersten vier Zeilen sind das Volumen. Sie sind auch der Punkt, an dem die meisten Marktplatz-Bots scheitern, weil sie aus dem Help Center statt aus dem Bestellsystem antworten. "Auszahlungen kommen meist in 2 bis 3 Tagen an" ist keine Antwort auf "Wo ist meine Auszahlung?" Die echte Antwort ist ein Status und ein Datum, und die steckt bei deinem Zahlungsanbieter. In der unteren Hälfte der Tabelle bleibt dauerhaft ein Human-in-the-Loop-Schritt.

Wie teilst du Käufer, Verkäufer und Trust & Safety in Lanes auf?

Drei Lanes decken fast alles ab. Die Käufer-Lane bearbeitet Bestellungen, Lieferung und Erstattungen. Die Verkäufer-Lane bearbeitet Auszahlungen, Gebühren, Angebote und Verifizierung. Die Trust-&-Safety-Lane bearbeitet Betrug, gefälschte Angebote und Kontoübernahmen, und sie überholt die Queue.

Jede Lane braucht drei eigene Dinge: einen Wissensbestand, eine Reihe erlaubter Aktionen und eine Person oder ein Team, das übernimmt, was die KI übergibt. Die Trennung des Wissens ist am wichtigsten. Deine Erstattungsrichtlinie für Käufer und deine Entschädigungsrichtlinie für Verkäufer widersprechen sich absichtlich, und eine KI, die beide liest, vermischt sie. Das ist dasselbe Problem wie beim Multi-Brand-Kundensupport, nur mit zwei Zielgruppen statt zwei Shops.

Dein Helpdesk kann die Trennung wahrscheinlich schon, wobei es auf deinen Plan ankommt:

In Zendesk ist der günstigste Weg, den ich gesehen habe, um Käufer und Verkäufer abzubilden, eine Verkäufer-Marke plus Nutzersegmente, wobei Verkäuferdatensätze als benutzerdefinierte Objekte mit Tickets verknüpft werden. Wenn Agenten nur ihre eigene Lane sehen sollen, ist das eine separate Berechtigungsfrage, die meine Notizen zur Zugriffskontrolle für Support-Agenten behandeln.

smava ist das klarste Beispiel, das ich dafür nennen kann, zwei Zielgruppen in einem Helpdesk getrennt zu halten. smava und Finanzcheck teilen sich ein Zendesk, und eesel bearbeitet rund 27,000 Tickets im Monat für beide, mit Entwürfen aus etwa 820 Makros und Help-Center-Artikeln, die nach Marke getrennt gehalten werden. Eine Verkäufer-Lane und eine Käufer-Lane funktionieren genauso: ein Helpdesk, zwei Wissensbestände, die sich nie vermischen.

In welche Lane gehört dieses Ticket?

Hier ist die Lane-Logik zum Durchklicken. Wähle ein Ticket, und du siehst die Lane, was die KI tun darf und wer die Aufgabe abschließt.

Wähle ein Ticket, um seine Lane zu sehen, was die KI tun darf und wer es abschließt. Das ist mein Ausgangspunkt für eine Marktplatz-Queue; deine Richtlinienabteilung legt die endgültigen Regeln fest.

Wie verbindest du die KI mit Live-Bestell- und Auszahlungsdaten?

Die Abfragen in der Käufer- und Verkäufer-Lane funktionieren nur, wenn die KI deine Systeme in Echtzeit lesen kann. Wer "Wo ist meine Auszahlung?" aus dem Help Center beantwortet, liefert einen generischen Zeitplan. Wer es aus der Zahlungs-API beantwortet, liefert "Deine Auszahlung über 412 $ ist unterwegs und sollte am Donnerstag ankommen." Die zweite Antwort schließt das Ticket, und genau darum geht es beim Support für Sendungsverfolgung und bei der WISMO-Automatisierung.

Bei den Auszahlungen steht oder fällt die Verkäufer-Lane, und Stripes Connect-Dokumentation erklärt, warum die Tickets bei dir landen. Wenn ein Verkäufer erwartete Gelder nicht sieht, sagt Stripe, dass er "sich an die Plattform wenden muss, mit der er arbeitet", weil die Plattform Auszahlungseinstellungen und Zeitpläne steuert. Jede Auszahlungsfrage ist also dein Ticket, nicht Stripes. Dieselbe Seite listet die Auszahlungsstatus auf, die eine KI laut nennen sollte: ausstehend, unterwegs, ausgezahlt, fehlgeschlagen und storniert.

Fehlgeschlagene Auszahlungen sind ein gutes Beispiel für ein Ticket, das die KI größtenteils bewältigen kann. Wenn eine Auszahlung fehlschlägt, markiert Stripe dieses Bankkonto als fehlerhaft und pausiert geplante Auszahlungen dorthin, und die Plattform kann einen Link erzeugen, mit dem der Verkäufer seine Bankdaten selbst aktualisiert. Das ist eine Abfrage plus ein Link, was KI gut kann. Dieselbe Seite vermerkt, dass die Plattform ein Bankkonto wegen Betrugs plattformweit sperren kann, und diese Aktion gehört einem Menschen.

Verifizierungssperren funktionieren genauso. Stripes Verifizierungsdokumentation sagt, dass Stripe Auszahlungen "typischerweise deaktiviert", wenn erforderliche Angaben bis zur Frist nicht eingehen, und jede Anforderung kommt mit einer verständlichen Fehlermeldung, auf die der Verkäufer reagieren kann. Adyen arbeitet mit einer ähnlichen Uhr: Laut Verifizierungsübersicht haben Verkäufer 30 Tage, Probleme zu beheben, bevor Auszahlungen enden, und 60 Tage, bevor sie keine Zahlungen mehr annehmen können. Eine KI, die die offenen Anforderungen liest und dem Verkäufer genau sagt, was er hochladen soll, spart bei jedem dieser Fälle ein Hin und Her.

Hier die Technik aus Entwicklersicht. Du willst vier Lesezugriffe und fast keine Schreibzugriffe:

1. Bestellungen: Status, Artikel, Sendungsereignisse, aus deiner Marktplatz-Datenbank oder Shopify.
2. Erstattungen: erstattet oder nicht, Betrag, Datum.
3. Auszahlungen: Status, Ankunftsdatum, Fehlercode, pro Verkäuferkonto.
4. Kontoanforderungen: welche Verifizierung offen ist und bis wann.

Webhooks halten die Daten aktuell. Stripes Seite zu Connect-Webhooks sagt, dass jede Connect-Integration auf Ereignisse hören sollte, und die für ein Support-Team wichtigen sind account.updated, payout.failed und charge.dispute.created. Ich lasse gern den Webhook für fehlgeschlagene Auszahlungen ein Ticket in der Verkäufer-Lane eröffnen, noch bevor der Verkäufer schreibt. Ein proaktives "Deine Auszahlung ist fehlgeschlagen, hier ist der Link zur Behebung" schlägt eine verwirrte E-Mail drei Tage später.

Bei Schreibzugriffen gilt meine einfache Regel: Alles, was Geld bewegt oder ein Konto ändert, wartet auf einen Menschen. Dazu gehören Erstattungen, Freigaben von Auszahlungen, Gebührenstornierungen und Kontosperrungen. Wenn du eine Vorlage dafür willst, wer was freigibt, findest du sie in meiner Matrix für Erstattungsfreigaben, und das Management von Support-Ausnahmen behandelt die Randfälle.

Wie sollte KI Streitfälle zwischen Käufer und Verkäufer behandeln?

Hier sind die gegensätzlichen Interessen am schärfsten, und hier würde ich die KI nie Partei ergreifen lassen. Beide Seiten sind deine Kunden. Was die KI tun kann, ist, die entscheidende Person viel schneller und viel einheitlicher zu machen.

Die Einheitlichkeit ist wichtiger, als viele erwarten. Hier beschreibt ein Gastgeber, wie sich Streitfall-Support auf einem großen Mietmarktplatz anfühlte:

"... The side you wins is the side you can say the magic words that specific agent wants to hear."

reverend_gonzo, Hacker News

Wenn das Ergebnis davon abhängt, an welchen Agenten du gerätst, verlieren beide Seiten Vertrauen. Die Lösung ist ein standardisiertes Nachweispaket, das jedes Mal gleich aussieht und gebaut wird, bevor ein Mensch den Fall überhaupt öffnet.

Mein Nachweispaket hat fünf Teile: die Bestelldaten, die Sendungsverfolgung des Paketdienstes, den vollständigen Nachrichtenverlauf zwischen Käufer und Verkäufer, einen Snapshot des Angebots im Zustand beim Kauf und die Erstattungs- und Streitfallhistorie beider Parteien. Die KI sammelt sie, markiert Lücken ("Verkäufer hat seit 3 Werktagen nicht geantwortet") und entwirft eine Nachricht an jede Seite, sobald der Mensch entschieden hat. Dieser letzte Teil wird leicht übersprungen, und das sollte er nicht. Die unterlegene Seite verdient eine klare Erklärung, geschrieben in der Sprache ihrer Lane.

Die Fristen unterscheiden sich je nach Marktplatztyp stark, also bilde deine eigenen ab, statt die eines anderen zu kopieren. Ein Marktplatz für physische Waren stützt sich auf Sendungsverfolgung und Zustellnachweis: eBay verlangt von Verkäufern eine Antwort innerhalb von 3 Werktagen, und Etsys Fallprozess erlaubt Käufern, einen Fall zu eröffnen, sobald die voraussichtliche Lieferzeit verstrichen ist und 48 Stunden nach der Nachricht an den Verkäufer. Ein Marktplatz für Dienstleistungen hat keine Sendungsnummer, stützt sich also auf Meilensteine und Nachrichten. Upwork gibt Freelancern 7 Kalendertage, um einen Streitfall bei Festpreisen einzureichen, und Fiverrs Resolution Center akzeptiert eine Anfrage automatisch, wenn sie nicht innerhalb von 48 Stunden beantwortet wird. Wenn du eine Dienstleistungsplattform betreibst, tauscht dein Nachweispaket die Sendungsverfolgung gegen gelieferte Dateien und den vereinbarten Umfang.

Auch wer zahlt, spielt eine Rolle und entscheidet, wie die KI formulieren sollte. Bei Sharetribe können standardmäßig "nur Marktplatzbetreiber eine Transaktion stornieren und eine Erstattung veranlassen", und eine strittige Bestellung wird nach 60 Tagen mit voller Erstattung storniert, wenn niemand handelt. Genau so einen Timer sollte die KI im Nachweispaket sichtbar machen, damit nichts stillschweigend abläuft.

Worin unterscheiden sich Chargebacks von Streitfällen zwischen Käufer und Verkäufer?

Ein Chargeback kann von genau derselben Bestellung stammen, ist aber ein anderer Prozess mit einem anderen Richter. Bei einem Streitfall zwischen Käufer und Verkäufer entscheidest du nach deiner eigenen Richtlinie. Bei einem Chargeback entscheidet der Kartenherausgeber des Käufers, und du bist auf die Uhr des Kartennetzwerks angewiesen.

Die Stripe-Regeln lohnt es sich im Detail zu kennen, denn sie sind streng:

• Die Frist ist kurz. Stripes Leitfaden zur Streitfall-Antwort sagt, dass das Fenster je nach Kartennetzwerk meist 7 bis 21 Tage beträgt, und eine versäumte Frist ist automatisch ein Verlust.
• Du hast einen Versuch. "You've only one opportunity to submit your response", laut derselben Seite. Keine Änderungen, keine Links, kein Audio oder Video, und eine Obergrenze von 4,5 MB für die gesamten Nachweise.
• Support-Historie ist ein Nachweis. Stripe rät Händlern, die gesamte Kommunikation mit dem Kunden aufzubewahren, weil sie Teil des Falls wird. Dein Helpdesk ist ein Archiv für Streitfälle, ob du es geplant hast oder nicht.
• Es kostet in jedem Fall Geld. In den USA berechnet Stripe 15 $, wenn ein Streitfall eingeht, und weitere 15 $, wenn du widersprichst, wobei die zweite Gebühr bei einem Sieg zurückerstattet wird.

Wer den Verlust trägt, hängt davon ab, wie deine Zahlungen aufgesetzt sind. Stripes Seite zu Connect-Streitfällen sagt, dass bei Destination Charges sowie bei Separate Charges and Transfers "Stripe Streitbeträge und Gebühren von deinem Plattformkonto abbucht", und du kannst dann die Überweisung stornieren, um es vom Verkäufer zurückzuholen. Bei Direct Charges wird das Guthaben des Verkäufers belastet. Adyens Standard ist ähnlich: Die Plattform zahlt zuerst und kann die Kosten an den Verkäufer weitergeben oder pro Zahlung aufteilen.

Die Aufgabe der KI bei einem Chargeback ist also eng umrissen: das Ereignis charge.dispute.created erkennen, ein Ticket mit dem Fälligkeitsdatum in der Betreffzeile eröffnen und die Nachweise aus der Bestellung, dem Zustellnachweis und dem Support-Verlauf zusammenstellen. Ein Mensch in der Finanzabteilung prüft und reicht ein. Wenn du die Support-Details willst, gehen meine Leitfäden zu KI bei Zahlungsstreitigkeiten und Chargeback-Anfragen tiefer.

Welche Kontrollen braucht die Trust-&-Safety-Lane?

Meldungen über Betrug und gefälschte Angebote sind die Tickets, bei denen Geschwindigkeit und Zurückhaltung gleichermaßen zählen. Der Meldende muss sofort das Gefühl haben, gehört zu werden, und die KI darf niemanden auf eigene Faust warnen oder bestrafen. In die andere Richtung falsch zu liegen ist genauso schlecht, wie dieser Facebook-Marketplace-Nutzer erfahren hat:

"Last year, I reported a number of people, who were trying to scam me (via Messenger messages related to Marketplace listings). Not only did Facebook did not see anything wrong with the accounts and scammy messages, I was flagged for sending useless reports."

lukaslalinsky, Hacker News

Das sind die fünf Kontrollen, die ich für diese Lane einrichte:

1. Prioritäts-Routing. Meldungen überspringen die normale Queue und landen beim Trust-&-Safety-Team. Skills-basiertes Routing in deinem Helpdesk erledigt das; die Aufgabe der KI ist, das Ticket gleich beim ersten Mal richtig zu taggen.
2. Sicherung der Nachweise. Die KI speichert das Angebot, die Nachrichten und die Kontodaten im Moment der Meldung, weil Betrüger schnell bearbeiten oder löschen.
3. Eingeschränkte Aktionen. Die KI darf bestätigen und taggen. Sie darf das gemeldete Konto nicht sperren, suspendieren, erstatten oder anschreiben. Das sind KI-Leitplanken, die du einmal setzt und nie lockerst.
4. Bewusstsein für Identitätsmissbrauch. Verkäufer erhalten Betrugsnachrichten, die sich als dein Support-Team ausgeben. Ein ehemaliger Etsy-Verkäufer beschrieb "20+ daily messages from scammers pretending to be buyers or Etsy support." Deine KI sollte nie nach Passwörtern oder Zahlungsdaten fragen und das in ihren Antworten auch sagen.
5. Einsprüche und Prüfpfad. Jede Aktion an einem Konto wird protokolliert, samt der Person, die sie freigegeben hat. Wenn ein Verkäufer gegen eine Sperrung Einspruch einlegt, sieht die prüfende Person die gesamte Historie an einem Ort.

Kontoübernahmen verdienen eine eigene Regel. Wenn ein Verkäufer schreibt "Jemand hat meine Bankdaten geändert", behandle es als dringend und leite es sofort an einen Menschen weiter. Stripes Auszahlungs-Tools erlauben einer Plattform, ein Bankkonto zu sperren (plattformweit) oder ein Konto wegen Übernahme abzulehnen, aber das sind Entscheidungen für dein Team, nicht für die KI. Für das allgemeine Muster sauberer Übergaben siehe meine Notizen zum KI-Eskalationsmanagement.

Wie würde ich das ausrollen?

Ich würde mit den Abfragen anfangen, nicht mit den Streitfällen, und testen, bevor irgendetwas live geht. Eine Abfolge, die ich funktionieren sah:

1. Woche 0: abbilden und verbinden. Hole 300 aktuelle Tickets und sortiere sie in die drei Lanes. Verbinde Lesezugriff auf Bestellungen, Erstattungen, Auszahlungen und Kontoanforderungen. Schreibe die Liste der eingeschränkten Aktionen.
2. Wochen 1 bis 2: simulieren. Lass die KI für jede Lane gegen historische Tickets laufen und vergleiche ihre Antworten mit dem, was dein Team tatsächlich gesendet hat. Mein Leitfaden zum Test vor dem Start und die Pilot-Scorecard zeigen, wie du bewertest.
3. Wochen 3 bis 4: Abfragen live. Bestellstatus, Erstattungsstatus, Auszahlungsstatus und Gebührenfragen gehen ohne Mensch raus. Alles andere ist nur Entwurf.
4. Wochen 5 bis 8: Nachweispakete. Die KI beginnt, Pakete für Streitfälle und Chargebacks zusammenzustellen. Menschen entscheiden weiterhin jeden einzelnen.
5. Laufend: Trust-&-Safety-Tagging. Schalte das Prioritäts-Tagging für Meldungen ein, mit null Kontoaktionen für die KI, niemals.

Beim Simulationsschritt finden Marktplätze ihre Überraschungen. Ein typisches Beispiel: Die KI gibt einem Verkäufer die Rückgaberichtlinie für Käufer, weil ein Verkäufer fragte "Wie funktionieren Rückgaben?" Das ist ein Problem der Wissenstrennung, und du willst es in einem Replay vergangener Tickets finden, nicht im Posteingang eines echten Verkäufers. Mein Leitfaden zum KI-Support-Pilot enthält die Vier-Wochen-Version dieses Plans.

Was solltest du auf einer zweiseitigen Plattform messen?

Die Deflection-Rate ist die falsche Leitkennzahl für einen Marktplatz. Ein Käufer, der eine Bot-Antwort bekommt und aufgibt, zählt als umgeleitet, und ein Verkäufer, der verstummt und woanders inseriert, ebenso. Ich messe jede Kennzahl zweimal, einmal pro Seite.

Den CSAT nach Seite zu trennen, ist der Punkt, den ich am stärksten vorantreibe. Verkäufer sind oft eine kleinere Gruppe mit deutlich höherem Lifetime Value, und eine Verkäufer-Lane, die still nachlässt, fällt in einem gemischten Wert nicht auf. Für Definitionen gehen meine Übersichten zu CX-KI-Kennzahlen und wiederholten Tickets jede einzelne durch.

Verkäufer sagen dir, wenn die Verkäufer-Lane kaputt ist, meist öffentlich. Hier ein kleiner Unternehmer zu einer Auszahlungssperre:

"We are affected by this as Etsy is currently holding about 4000 of our Euros... The worst thing about it is that we raised a support request for this, for which you have to jump through really stupid hoops, and have not even heard back from them in weeks. Not even a boilerplate response."

handmadeta, Hacker News

Eine Auszahlungssperre kann aus Risikogründen die richtige Entscheidung sein. Wochenlange Stille ist nie die richtige. Eine KI, die den Sperrgrund liest und noch am selben Tag antwortet, auch nur mit "Deine Gelder sind wegen einer Verifizierungsprüfung zurückgehalten, das brauchen wir von dir", verwandelt diesen Beitrag in ein Ticket, das nie geschrieben wird.

Wie passt eesel zu einem Marktplatz-Support-Team?

eesel ist ein KI-Teammitglied, das dem Helpdesk beitritt, den du bereits nutzt, darunter Zendesk, Freshdesk und Gorgias sowie HubSpot. Es lernt aus deinem Help Center und vergangenen Tickets, und du kannst pro Lane einen eigenen Agenten betreiben, jeweils mit eigenem Wissen und eigenen Anweisungen.

Der Teil mit den Live-Daten ist der, an dem ich am meisten arbeite. eesels Einstellung Network Access lässt einen Agenten deine eigenen APIs aufrufen, sodass er Live-Bestellungen, Erstattungen oder Auszahlungen nachschlagen kann. Du erlaubst eine Domain und setzt den Auth-Header, und die Zugangsdaten werden von eesel an jede Anfrage angehängt, die KI sieht sie also nie. Shopify-Bestelldaten verbindest du über die Shopify-Integration. Mit Aktionsberechtigungen stellst du jede Aktion so ein, dass sie selbstständig läuft, um Freigabe bittet oder ausgeschaltet bleibt, wodurch Erstattungen und Kontoänderungen hinter einem Menschen bleiben.

Wenn deine Entwickler lieber im Terminal arbeiten, führt die eesel-CLI dasselbe Teammitglied und denselben Workspace von der Kommandozeile aus. Du kannst ausstehende Freigaben prüfen, das Aktivitätsprotokoll jedes Laufs lesen und die Standardanweisungen des Agenten bearbeiten, und Coding-Agenten wie Claude Code können sie ebenfalls steuern. Für einen Marktplatz, der seine Bestell- und Auszahlungssysteme bereits als Code betreibt, bleiben die Regeln des Support-Agenten so neben allem anderen.

Zwei Kundengeschichten zeigen die Lanes in der Praxis. SamCart, eine Plattform, über die mehr als 75,000 Unternehmen verkaufen, setzt eesel im Verkäufer-Support ein: Ein Agent antwortet auf Freshdesk-Tickets und ein weiterer betreibt den Website-Chat, beide antworten aus etwa 280 Help-Center-Artikeln. Der Agent antwortet nur, solange kein Teammitglied zugewiesen ist, und wenn ein Verkäufer nach einem Menschen fragt, wird das Ticket für die Übergabe getaggt und der Agent hört auf. Rúngne zeigt die Käuferseite: eesel bearbeitete in einem Monat rund 2,100 Gorgias-Tickets und beantwortete Fragen zu Bestellstatus und Lagerbestand aus Shopify-Daten, während Stornierungen, beschädigte Artikel, verlorene Pakete und Zollstreitigkeiten an Menschen gehen.

Die ehrlichen Grenzen: eesel entscheidet keine Streitfälle und reicht keine Chargeback-Antworten für dich ein, und ich würde es auch nicht wollen. Das SOC-2-Type-II-Audit ist in Arbeit, der Beobachtungszeitraum beginnt am 1. Oktober 2026. Die Preise stehen auf der Preisseite: ein kostenloser Plan mit 100 Credits und Teammate-Pläne ab $299 im Monat für 500 Credits, wobei ein Ticket oder ein Chat einen Credit kostet. Wenn du eine separate KI-Schicht gegen die eingebaute KI deines Helpdesks abwägst, habe ich beides in meinem Vergleich der KI-Schicht verglichen.

eesel für deine Marktplatz-Queue testen

Wenn deine Käufer und Verkäufer dieselben vorgefertigten Antworten bekommen, kann eesel jeder Seite im bestehenden Helpdesk eine eigene Lane geben: Live-Abfragen zu Bestellungen und Auszahlungen für die einfachen Tickets, Nachweispakete für Streitfälle und jede Entscheidung über Geld bei deinem Team. Jeder Rollout beginnt mit einer Simulation an deinen historischen Tickets, sodass du siehst, wie es Käufern und Verkäufern antwortet, bevor es sonst jemand tut.

Teste eesel kostenlos mit 100 Credits oder buche eine Demo und bring eine Auswahl an Käufer- und Verkäufer-Tickets mit, damit wir deine Lanes gemeinsam abbilden können.