RFP-Vorlage für KI-Support: Anbieterfragen, Bewertungsraster und Ticket-Test

Warum wählen die meisten RFPs für KI-Support den falschen Anbieter?

Weil sie bewerten, was der Anbieter sagt, statt was die KI mit Ihren Tickets tut. Eine typische RFP stellt 80 Fragen, bekommt 80 selbstsichere Antworten und wählt dann den, der die beste Demo hatte. Die Demo nutzte die Szenarien des Anbieters, eine saubere Wissensdatenbank und einen Sales Engineer am Steuer.

Ich baue bei eesel Integrationen und sehe deshalb die andere Seite: die Fragen der Käufer nach der Vertragsunterzeichnung. Sie drehen sich fast nie um Funktionen. Sie lauten „Warum hat sie dieses Ticket so beantwortet?“, „Warum ist meine Rechnung im November gestiegen?“ und „Warum sagt sie Ja zu Produkten, die wir gar nicht unterstützen?“ Jede davon hätte eine RFP-Frage sein können.

Die Lösung ist eine andere Reihenfolge der Arbeit, nicht mehr Fragen:

1. Zuerst die Kriterien. Alles, was den Deal kippen kann (Sicherheitszertifizierung, Datennutzung, Ihr Helpdesk, HIPAA), ist eine Ja/Nein-Frage, die geprüft wird, bevor irgendjemand etwas bewertet.
2. Danach schriftliche Antworten. Der Fragenkatalog unten, schriftlich beantwortet und mit Belegen.
3. Dann Ihre Tickets. Die zwei oder drei Übrigen durchlaufen dasselbe Testset aus Ihrem Verlauf.
4. Zuletzt der Preis, bei Ihrem Volumen. Jeder Anbieter füllt dieselbe Kostenzeile aus.

In den Verkaufsgesprächen von eesel kommt am häufigsten der Wunsch, die KI mit den eigenen früheren Tickets des Käufers zu trainieren. Mein Kollege Amogh sagte es nach einer Reihe von Demos unverblümt: „past ticket training strikes again.“ Käufer wissen bereits, dass ihr eigener Verlauf der echte Test ist. Die meisten RFP-Vorlagen fragen nur nicht danach.

Was gehört in eine RFP-Vorlage für KI-Support?

Zehn Abschnitte. Jeder entspricht einer Entscheidung, die Sie später verteidigen müssen, gegenüber Ihrem CFO, Ihrem Sicherheitsteam oder Ihren Agenten.

Abschnitt 1 überspringen Teams am häufigsten, und er macht die Anbieterantworten vergleichbar. Geben Sie Ihre echten Zahlen an: Tickets pro Monat nach Kanal, die Top 10 der Kontaktgründe, Sprachen, Helpdesk und welche Tickettypen die KI nie anfassen soll. Eine Support-Leiterin sagte das Letzte in einem eesel-Gespräch klar: „There are certain tickets I don't want to go through AI.“ Schreiben Sie diese Liste in die RFP, nicht in ein Folgegespräch.

Welche Fragen sollten Sie KI-Support-Anbietern stellen?

Übernehmen Sie diese als schriftliche Fragen in Ihre RFP. Zu jeder habe ich ergänzt, wie eine starke Antwort aussieht, denn schwache Antworten klingen alle ähnlich, und der Unterschied liegt im Detail.

Lösungsqualität und Genauigkeit

Dieser Abschnitt bekommt das meiste Gewicht, und hier sind Anbieter am besten geübt. Gehen Sie über die Schlagzeilenzahl hinaus.

1. Was zählt Ihre Lösungsquote? Starke Antwort: eine genaue Definition, wer oder was entscheidet, dass ein Ticket gelöst ist, und ob Spam, automatisch geschlossene Tickets und Kunden, die einfach gegangen sind, enthalten sind.
2. Wie hoch ist Ihre Lösungsquote bei Tickets wie unseren? Starke Antwort: Ergebnisse nach Kontaktgrund und Kanal aufgeteilt, mit Stichprobengröße und Zeitraum. Eine einzige gemischte Zahl über alle Kunden sagt nichts.
3. Was tut sie, wenn die Wissensdatenbank keine Antwort hat? Starke Antwort: Sie sagt, dass sie es nicht weiß, und übergibt. Lassen Sie es sich zeigen.
4. Antwortet sie jemals aus dem Allgemeinwissen des Modells statt aus unseren Inhalten? Starke Antwort: Nein, oder ja mit einer Einstellung zum Abschalten. Ein technischer Evaluator fragte in einem eesel-Verkaufsgespräch genau das: ob die KI auf etwas wie ChatGPT zurückfällt, wenn sie es nicht weiß, und ob sich das abschalten lässt.
5. Wie erkennen Sie nach dem Start eine falsche Antwort? Starke Antwort: ein benannter Prozess (Stichproben, Bewertung, Warnungen), plus wo Sie es im Produkt sehen.
6. Was passiert, wenn der Modellanbieter das Modell ändert? Starke Antwort: Sie führen Tests mit Ihrem Verlauf erneut durch, bevor die Änderung Sie erreicht, und informieren Sie.

Diese erste Frage ist wichtiger, als sie aussieht:

In einem eesel-Test mit echtem E-Commerce-Zendesk-Verkehr waren 22 % der eingehenden Tickets Spam. Ein Anbieter, der das Schließen von Spam als „Lösung“ zählt, kann seine Quote um 22 Punkte erhöhen, ohne einem einzigen Kunden zu antworten. Der Beitrag zu Deflection vs. Lösungsquote zeigt, wie neun Helpdesks das unterschiedlich zählen.

Ein Betreiber auf Reddit beschrieb, was passiert, wenn niemand prüft, was „gelöst“ bedeutet:

"So we audited a week's worth of auto tickets and found 3 separate cases where the bot made up a policy that doesn't exist. The scary part is the customers believed what it said and walked away feeling that WE were wrong. It even marked the ticket as "resolved" so we didn't notice until they dropped a negative review."

quietkernel_thoughts, Reddit

Fügen Sie also eine siebte Frage hinzu: Wie zählen Sie ein Ticket, das der Kunde wieder öffnet oder zu dem er sich innerhalb von 7 Tagen erneut meldet? Wenn die Zahl des Anbieters diese nicht abzieht, misst sie, wie Konversationen enden, nicht ob Probleme gelöst wurden.

Übergabe und Kontrolle

1. Welche Tickets können wir komplett ausschließen, und wie? Starke Antwort: per Tag, Formular, Kanal, Kundensegment oder Thema, von Ihnen festgelegt, nicht über ein Ticket an deren Support-Team.
2. Kann sie zunächst Antworten für Agenten entwerfen, bevor sie etwas sendet? Starke Antwort: Ja, mit einem Schalter pro Thema oder Kanal, um von Entwurf auf Senden umzustellen.
3. Was sieht der Mensch bei der Übergabe? Starke Antwort: eine Zusammenfassung, was sie schon versucht hat, und die genutzten Quellen, ins Ticket geschrieben.
4. Kann ein Kunde jederzeit einen Menschen erreichen? Starke Antwort: Ja, und Sie sehen, wie oft danach gefragt wird.

Die klarste Version davon stammt von einem CX-Leiter einer Direct-to-Consumer-Marke mit etwa 7.000 Tickets pro Monat:

"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer. Then the point is a little bit gone. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

Das ist eine Anforderung, also schreiben Sie sie als eine: „Die KI darf nur auf Tickets antworten, die sie aus unseren Inhalten beantworten kann, und muss alle anderen unberührt für einen Menschen lassen.“ Testen Sie das dann. Mein Beitrag zu Best Practices für die Übergabe von KI-Agenten behandelt, wie eine saubere Übergabe aussieht.

Helpdesk-Integration und Aktionen

Das ist mein Tagesgeschäft, also sage ich es offen: „Integriert sich mit Zendesk“ kann alles bedeuten, von einem vollständigen Agenten, der in Tickets taggt, weiterleitet und antwortet, bis zu einem Widget, das Ihr Help Center liest und sonst nichts.

1. Arbeitet sie als Agent in unserem Helpdesk oder daneben? Starke Antwort: Sie liest und schreibt Tickets, Tags, Felder und interne Notizen in Ihrem Helpdesk, mit einer Liste, welche genau.
2. Welche Aktionen kann sie ausführen, nicht nur beantworten? Starke Antwort: eine benannte Liste (Bestellung nachschlagen, Feld aktualisieren, Erstattung bis zu einem Limit), mit Angabe, wie jede autorisiert und protokolliert wird.
3. Woraus lernt sie? Starke Antwort: Help Center, Makros, frühere Tickets, interne Dokumente, jeweils optional und filterbar. Fragen Sie, ob Sie wählen können, welche früheren Tickets sie liest (Zeitraum, Tags).
4. Was passiert, wenn die API unseres Helpdesks ausfällt oder langsam ist? Starke Antwort: Wiederholungen, keine doppelten Antworten und ein Protokoll, das Sie lesen können.
5. Wie schnell antwortet sie? Starke Antwort: gemessene Zeiten für Chat und E-Mail bei echtem Verkehr. Ein Käufer führte eine Evaluation mit 67 Tests durch, fand die Antworten solide und sprang dann ab, weil das Chat-Widget langsam war und ständig hängen blieb. Geschwindigkeit gehört ins Bewertungsraster.

Wenn Sie einen bestimmten Helpdesk nutzen, fragen Sie nach einem Kunden mit demselben Helpdesk als Referenz. Vergleichen Sie, was jeder Anbieter sagt, mit dem, was die KI Ihres Helpdesks selbst leistet: Die Aufschlüsselungen zu Zendesk-AI-Preisen, Freshdesk-Freddy-AI-Preisen und Gorgias-AI-Preisen sind gute Vergleichswerte.

Sicherheit, Datenschutz und Datennutzung

Das meiste in diesem Abschnitt ist Pass/Fail. Deals, die ich in dieser Phase ins Stocken geraten sah, taten das aus jeweils einem Grund: kein SOC-2-Bericht, eine interne ISO-Prüfung, die der Anbieter nicht bestand, oder kein HIPAA Business Associate Agreement. Finden Sie das in Woche eins heraus, nicht in Woche sechs.

1. Welche Zertifizierungen halten Sie heute, und welche sind in Arbeit? Fragen Sie nach dem Bericht oder einem Bridge Letter und nach dem Umfang. „SOC 2 Type II in Arbeit“ und „SOC 2 Type II Bericht unter NDA verfügbar“ sind verschiedene Antworten.
2. Werden unsere Daten zum Training irgendeines Modells verwendet, Ihres oder das eines Anbieters? Starke Antwort: ein klares Nein, im Vertrag. Lesen Sie das Detail: Das Trust Center von Zendesk sagt, dass seine generative KI nicht mit Kundendaten trainiert wird, aber bereinigte Servicedaten trainieren seine eigenen kundenübergreifenden Machine-Learning-Modelle.
3. Wo werden unsere Daten gespeichert und verarbeitet, und von welchen Unterauftragsverarbeitern? Starke Antwort: eine Liste, mit Regionen.
4. Können Sie Kartennummern und andere personenbezogene Daten schwärzen, bevor sie gespeichert werden? Ein Medienunternehmen, das eesel evaluierte, machte dies zu seinem wichtigsten Einwand, noch bevor ein Test begann.
5. Unterzeichnen Sie ein HIPAA-BAA, und in welchem Tarif? Nur relevant, wenn Sie Gesundheitsdaten verarbeiten, aber wenn ja, ist es ein Kriterium.
6. Was passiert mit unseren Daten, wenn wir gehen? Starke Antwort: Export in einem benannten Format, Löschung mit Bestätigung und eine Frist.

Ein Standard-Sicherheitsfragebogen fängt nicht alles davon allein ab. Ein Käufer in einem B2B-SaaS-Unternehmen mit 200 Mitarbeitern beschrieb die Lücke gut:

"My company (200 people, B2B SaaS) is starting to use AI vendors for customer support and internal tools. Our procurement process is basically "fill out security questionnaire, get SOC 2, done." But I'm realizing SOC 2 doesn't cover AI-specific stuff. Like what happens when the vendor updates their model and it starts giving wrong answers? What if the training data had customer info in it?"

Alieezeee, Reddit

Deshalb gehört die Frage zur Modelländerung aus dem Genauigkeitsabschnitt neben die Sicherheitskriterien und nicht nur in die Produktprüfung.

Für die vollständige Version nutzen Sie die Sicherheits-Checkliste für KI-Support-Anbieter als Anhang zur RFP und den Leitfaden zu SOC 2 und DSGVO, wenn Ihr Sicherheitsteam neu bei KI-Anbietern ist.

Preise und abrechenbare Einheiten

Die Antworten hier wirken vergleichbar und sind es nicht. Ein Anbieter rechnet pro Lösung ab, einer pro Konversation, einer pro Credit, einer pro Platz, und drei veröffentlichen gar keinen Preis. Fragen Sie:

1. Was genau ist eine abrechenbare Einheit? Lassen Sie sich die Definition schriftlich geben.
2. Wer entscheidet, ob eine Konversation zählt, und können wir das einsehen und anfechten?
3. Was passiert in unserem Spitzenmonat? Bitten Sie um die Rechnung bei dem 2-Fachen Ihres normalen Volumens.
4. Gibt es Mehrverbrauchskosten, und sind sie standardmäßig aktiv?
5. Sind Preiserhöhungen für die Vertragslaufzeit gedeckelt? Ein Hardware-Support-Team, das eesel evaluierte, hatte erlebt, wie sich der Preis eines früheren Anbieters mehr als verdoppelte, und wollte diesmal eine Preisgarantie schriftlich.
6. Füllen Sie diese Zeile aus: unser Ticketvolumen pro Monat der letzten 12 Monate, bepreist zu Ihren Tarifen.

Die Abrechnungseinheit ändert, wer für Fehlschläge zahlt:

Diese Zelle unten links ist jetzt die wichtigste Frage in diesem Abschnitt. Seit dem 18. Mai 2026 sortiert Zendesk jede KI-Konversation in drei Stufen, und nur eine „verified resolution“ zehrt an Ihrem Kontingent. Das eigene Modell von Zendesk trifft diese Entscheidung, 72 Stunden nach der ersten E-Mail oder 2 Stunden nach Beginn eines Messaging-Chats. Das ist in einer Hinsicht fair zu Ihnen (Eskalationen zahlen Sie nicht), aber Sie sollten dennoch fragen, wie sich die Urteile prüfen lassen.

Decagon, bei dem Kunden beide Modelle wählen können, argumentiert im eigenen Preis-Blog gegen die Abrechnung pro Lösung: "You never want to be in a situation where you're arguing over what a 'resolution' is." Sierra geht den umgekehrten Weg mit ergebnisbasierter Preisgestaltung, bei der die Ergebnisse pro Kunde vereinbart werden.

Auf Hacker News, als Antwort auf ein Startup, das ergebnisbasierte Abrechnung verkauft, nannte ein Ingenieur die Frage, die jedes ergebnisbasierte Angebot beantworten sollte:

"can you clearly explain how you will measure and track the outcomes? That's the key detail that matters. Relying on customers to self-report is not sufficient, and an automated self-report-system is not a true improvement."

mushufasa, Hacker News

So sehen die öffentlichen Preislisten für denselben Monat aus. Stellen Sie die Regler auf Ihre Zahlen:

Zwei Dinge fallen auf, wenn Sie damit spielen. Die Abrechnung pro Lösung wird günstiger, wenn die KI weniger löst, sodass ein niedriges Angebot einen schwachen Agenten verbergen kann. Und der Abstand zwischen den Anbietern ändert sich völlig mit Ihrer Lösungsquote, weshalb Sie nach dem Ticket-Test bepreisen, nicht davor. Für eine genauere Betrachtung siehe die wahren Kosten pro Lösung und die Aufschlüsselung zu Agentforce-Preisen.

Implementierung und Support

1. Was brauchen Sie von uns, in Stunden, nach Rolle? Starke Antwort: eine Schätzung für Ihre Support-Operations-, Engineering- und Sicherheitszeit, nicht „minimaler Aufwand“.
2. Wie lange dauert es, bis der erste Tickettyp live ist? Starke Antwort: ein Datum, gebunden an einen Umfang, mit dem, was es verzögern könnte.
3. Wer verantwortet die Feinabstimmung nach dem Start? Starke Antwort: namentlich benannt, mit dem, was im Preis enthalten ist.
4. Was sind die häufigsten Gründe, warum Ihre Rollouts ins Stocken geraten? Ein Anbieter mit echten Rollouts hat eine konkrete, ehrliche Antwort. Eine vage ist ein Warnsignal.
5. Können wir während des Hochlaufs weniger zahlen? Ein CFO bat in einem eesel-Verkaufsgespräch um reduzierte Preise während der Implementierung und sagte „this is not just for you, but for any tech vendor.“ Das ist eine normale Bitte.

Der Implementierungsleitfaden und die Liste der Implementierungsfehler lassen sich gut an Ihren Projektverantwortlichen weitergeben.

Vertrag und Ausstieg

1. Können wir unsere Konversationen, Einstellungen und Testergebnisse exportieren? In welchem Format?
2. Wie lang ist die Kündigungsfrist, und gibt es eine Gebühr bei vorzeitigem Ausstieg?
3. Was passiert, wenn der erste Anwendungsfall das vereinbarte Ziel verfehlt? Starke Antwort: eine schriftliche Abhilfe (verlängerter Pilot, Gutschrift oder das Recht auszusteigen).

Wenn Sie einen KI-Anbieter ersetzen, statt Ihren ersten zu kaufen, nehmen Sie den Leitfaden zum Wechsel von KI-Support-Anbietern in Ihre Lektüre auf.

Wie sollten Sie KI-Support-Anbieter bewerten?

Prüfen Sie zuerst die Kriterien. Wer eines nicht erfüllt, scheidet aus, egal wie gut die Demo war. Bewerten Sie dann den Rest in jeder Zeile von 1 bis 5 und multiplizieren Sie mit dem Gewicht.

Kriterien (Pass/Fail, vor der Bewertung): erforderliche Zertifizierung oder Bericht verfügbar, vertraglicher Ausschluss des Trainings mit Ihren Daten, Ihr Helpdesk unterstützt, benötigter Datenstandort, HIPAA-BAA bei Gesundheitsdaten, Datenexport beim Ausstieg.

Zwei Entscheidungen sind hier bewusst getroffen. Der Ticket-Test hat mehr Gewicht als die schriftlichen Antworten und die Übergabe zusammen, weil er die einzige Zeile ist, in die sich der Anbieter nicht hineinschreiben kann. Und Geschwindigkeit hat eine eigene Zeile, weil ein langsames Chat-Widget Deals verliert, die genaue Antworten gewonnen haben. Das Bewertungsraster für KI-Support-Piloten hat eine längere Version, falls Sie Teilbewertungen wollen.

Wie testen Sie Anbieter mit Ihren eigenen Tickets?

Das ist Abschnitt 9 der RFP, und um ihn würde ich kämpfen. So führen Sie ihn durch, damit die Ergebnisse vergleichbar sind.

1. Ziehen Sie ein Testset aus den letzten 90 Tagen. 100 bis 200 gelöste Tickets, proportional zum Volumen über Ihre wichtigsten Kontaktgründe gezogen. Entfernen Sie alles, was Sie nicht teilen können.
2. Fügen Sie bewusst die schwierigen hinzu. 10 bis 20 Tickets, bei denen die ehrliche Antwort „Nein“ oder „Das unterstützen wir nicht“ lautet, plus einige verärgerte Kunden und einige, die eine Aktion erfordern (Erstattung, Bestelländerung).
3. Geben Sie jedem Anbieter dasselbe Set und dasselbe Wissen. Derselbe Help-Center-Export, dieselben Makros. Keine vom Anbieter gewählten Szenarien.
4. Bewerten Sie jede Antwort anhand dessen, was Ihr Team tatsächlich gesendet hat. Korrekt und direkt nutzbar, korrekt aber überarbeitungsbedürftig, falsch oder korrekt übergeben.
5. Berichten Sie mehrere Zahlen, nicht eine. Genauigkeit, Quote unveränderter Sendungen, Quote falscher Antworten, Übergabequote und Antwortzeit.

In Schritt 5 kommt die Wahrheit heraus. In einem eesel-Test mit echtem E-Commerce-Zendesk-Verkehr (284 Chats plus eine Gegenprüfung mit 100 Tickets) erreichte die KI 93 % Triage-Genauigkeit und erkannte jedes Spam-Ticket. Doch Agenten sendeten ihre Entwürfe nur in 12 % der Fälle unverändert. Als das Team nachgrub, betrafen etwa 65 % der Umschreibungen Länge und Ton (Agenten kürzten Entwürfe von 8 bis 15 Sätzen auf 1 bis 3), und nur etwa 5 % betrafen Sachfehler. Eine Zahl hätte „großartig“ oder „nutzlos“ gesagt. Fünf Zahlen sagten „genau, zu wortreich, Ton korrigieren“.

Die „ehrliches Nein“-Tickets aus Schritt 2 sind wichtiger, als es klingt. Ein technisches B2B-Team erzählte eesel in einem Verkaufsgespräch, dass ein Bot für Marken, die nicht in der Datenbank standen, „Ja, wir unterstützen Ihr Automodell“ bestätigt hatte, weil die Wissensdatenbank „we support all models“ sagte. Genau diese Art Antwort zeigt eine Anbieter-Demo nie.

Auf diesen Schritt ist eesel ausgelegt. Der Skill Helpdesk-Simulation nimmt 20 Tickets, die Ihr Team kürzlich gelöst hat, entwirft für jedes eine eigene Antwort, vergleicht sie mit dem, was Ihr Team gesendet hat, gruppiert die Ergebnisse nach Themen und sendet nichts an Kunden:

Beachten Sie, was dieser Bericht als Lücke ausweist: nicht die Formulierung, sondern die Aktionen. Bei etwa der Hälfte der übereinstimmenden Tickets musste dennoch ein Mensch etwas in einem Backend-System tun. Genau diese Erkenntnis wollen Sie vor der Unterschrift, denn sie zeigt, nach welchen Integrationen Sie fragen sollten. Kann ein Anbieter so etwas nicht mit Ihrem Verlauf durchführen, fragen Sie, woher Sie es sonst wissen sollen. Der Leitfaden zum Testen von KI-Support-Agenten geht tiefer auf den Aufbau des Testsets ein.

Ein weiterer Test, den es sich zu übernehmen lohnt, aus einem Reddit-Thread dazu, was eine Live-Demo beweisen sollte:

"Make them do the demo with a knowledge base that's deliberately outdated by like 6 months, and see if the agent just confidently spits wrong info or admits it don't know. That's the real test for me"

Right_Smile_4412, Reddit

Ihre echte Wissensdatenbank ist irgendwo schon etwas veraltet, das ist also keine Fangfrage. Es ist der Normalfall.

Was veröffentlichen KI-Support-Anbieter, bevor Sie die RFP senden?

Einen Teil der RFP können Sie selbst anhand von Anbieterseiten ausfüllen. Das habe ich im Oktober 2026 auf der jeweiligen Anbieterseite gefunden:

Drei von sechs veröffentlichen keinen Preis, was im Enterprise-Vertrieb üblich ist, aber bedeutet, dass Ihre RFP von jedem dieselbe Kostenzeile verlangen muss. Mein Überblick über die besten KI-Kundensupport-Agenten behandelt weitere Anbieter, falls Ihre Longlist größer ist.

Welche Fehler machen Teams bei RFPs für KI-Support?

• 200 Fragen verschicken. Anbieter beantworten lange Fragebögen mit Texten aus dem letzten. 40 präzise Fragen bringen bessere Antworten als 200 allgemeine.
• Anbieter die Demo-Szenarien wählen lassen. Jeder Anbieter wirkt bei seinen eigenen Beispielen gut. Nutzen Sie Ihre Tickets.
• Angebote mit verschiedenen Einheiten vergleichen. Pro Lösung und pro Konversation lassen sich nicht vergleichen, bis beide auf Ihren Monat bepreist sind.
• „In Arbeit“ als „erledigt“ behandeln. Eine Zertifizierung in Arbeit kann für Sie in Ordnung sein oder ein Kriterium. Entscheiden Sie vor der Demo, nicht danach.
• Den Spitzenmonat überspringen. Bepreisen Sie Ihre Spitze, nicht Ihren Durchschnitt. Preise pro Einheit steigen mit Ihrem Volumen.
• Agenten außen vor lassen. Die Leute, die die Entwürfe der KI bearbeiten werden, sollten den Ticket-Test bewerten. Sie bemerken Tonprobleme, die eine Führungskraft beim Lesen von Zusammenfassungen übersieht.

Der Punkt mit dem schlimmsten Kunden verdient Wiederholung, denn er ist am leichtesten zu überspringen:

"test it as your worst customer not your best one vague question, typo in it, missing half the context. if it handles that you're probably fine. most people only test the clean version and then wonder why it breaks on real customers"

ShotOil1398, Reddit

Wie würde eesel diese RFP beantworten?

Da ich Ihnen geraten habe, harte Fragen zu stellen, hier die Antworten von eesel auf die, die meist den Ausschlag geben, auch auf die, die eesel möglicherweise ausschließen.

• Was es ist: ein KI-Helpdesk-Teammitglied, das in Ihrem Helpdesk als weiterer Agent arbeitet: Es entwirft oder sendet Antworten, taggt und leitet Tickets weiter und lernt aus Ihrem Help Center, Ihren Makros und früheren Tickets. Es verbindet sich unter anderem mit Zendesk, Freshdesk, Gorgias, Help Scout, HubSpot, Front und Salesforce.
• Abrechnungseinheit: ein Credit pro bearbeitetem Ticket oder Chat, egal wie viele Antworten. Die Tarife reichen von $299 für 500 Credits bis $1,749 für 5.000, ohne Platzgebühren. Mehrverbrauch kostet $0.80 pro Credit und ist aus, solange Sie ihn nicht einschalten, mit einer von Ihnen gesetzten Obergrenze. Ein Gratis-Tarif hat 100 Credits und braucht keine Karte.
• Sicherheit: SOC 2 Type II Audit in Arbeit, der Beobachtungszeitraum begann am 1. Oktober 2026. Wenn Sie heute einen fertigen Bericht brauchen, ist das ein Kriterium, das eesel noch nicht erfüllt. HIPAA-BAAs gibt es im Enterprise-Tarif. eesel trainiert oder feintuned keine Modelle mit Ihren Daten.
• Ticket-Test: eingebaut, mit Ihren eigenen gelösten Tickets, bevor irgendetwas einen Kunden erreicht.

So sieht es in der Produktion aus, laut veröffentlichten Kundengeschichten:

• Regulierte Finanzbranche, Entwurf zuerst. smava, ein deutscher Kreditvergleich, betreibt drei eesel-Agenten auf einem Zendesk: einer kategorisiert jedes Ticket, einer entwirft aus der Makrobibliothek, und einer bereitet kundenfertige Antworten vor. Das sind 27.000 bearbeitete Tickets in einem Monat und 15.300 Entwurfsantworten, und eesel sendet sie nie selbst.
• Antworten nur aus Ihren Dokumenten. Ein Industrieautomatisierungsunternehmen stellte seine technische Bibliothek hinter einen Chat, der nur aus den Dokumenten antwortet, seine Quelle verlinkt und zugibt, wenn er keine hat. Jedes Support-Ticket kommt mit einem Entwurf, den ein Ingenieur bearbeitet.
• Volumen mit festem Tarif. SamCart betreibt einen Agenten auf Freshdesk-Tickets und einen im Website-Chat, die aus 280 Help-Center-Artikeln antworten, in einem Tarif mit 8.000 Interaktionen pro Monat.

eesel als einen Ihrer RFP-Anbieter testen

Wenn Sie dieses Quartal eine RFP für KI-Support schreiben, setzen Sie eesel auf die Shortlist und lassen Sie es zuerst Abschnitt 9 durchlaufen. Verbinden Sie Ihren Helpdesk, bitten Sie es, Ihre kürzlich gelösten Tickets zu simulieren, und Sie haben vor jedem Verkaufsgespräch einen bewerteten Bericht nach Kontaktgrund, ohne dass etwas an Kunden gesendet wird. Messen Sie es dann an denselben Kriterien und derselben Kostenzeile wie alle anderen.

Testen Sie eesel kostenlos oder buchen Sie eine Demo, wenn Ihr Sicherheitsteam zuerst die Kontrollen sehen möchte.