Gumloop Preise 2026: Was ein Credit wirklich kostet

Gumloop Preise 2026 im Überblick

Gumloop ist eine No-Code-KI-Agenten-Plattform: Du baust Agenten und Workflows auf einer visuellen Oberfläche zusammen, und sie laufen gegen dein Slack, Gmail, BigQuery, HubSpot und den Rest. Das Unternehmen holte sich eine 50-Millionen-Dollar-Series-B unter Führung von Benchmark, mit Shopify, Ramp, Gusto, Samsara, Instacart und Opendoor als genannten Kunden.

Wenn dir die Kategorie neu ist: Die hilfreiche gedankliche Unterteilung ist, dass diese Plattformen KI-Agenten verkaufen, keine Chatbots. Das, was du kaufst, führt Aktionen in anderen Systemen aus, und genau deshalb ist die Abrechnung schwerer vorherzusagen als eine SaaS-Lizenz pro Sitzplatz.

Die Plan-Auswahl auf Gumloops Preisseite besteht jetzt aus zwei Stufen, nicht drei.

Zwei Dinge haben sich kürzlich geändert, und viele Artikel haben das noch nicht mitbekommen.

Es gibt keinen kostenlosen Plan. Gumloops Credits-Dokumentation sagt das ganz unverblümt und fügt hinzu, dass Konten, die noch auf der alten kostenlosen Stufe erstellt wurden, ihr verbleibendes Guthaben behalten, das sich aber nicht mehr monatlich erneuert. Wenn du eine Seite liest, die behauptet, Gumloop gebe dir 5.000 kostenlose Credits im Monat, beschreibt diese Seite eine Stufe, die es nicht mehr gibt. Was du stattdessen bekommst, ist ein 14-tägiger Pro-Test, der eine Kreditkarte erfordert, einmalig pro Kunde ist und sich beim Ablauf in ein kostenpflichtiges Abo umwandelt, sofern du nicht kündigst.

Die zweite Änderung ist größer, und sie ist das gesamte Thema dieses Beitrags.

Die eine Zahl, die deine Rechnung wirklich bestimmt

Gumloop hat seine Abrechnung auf ein Passthrough-Modell umgeschrieben. Der eigene Ankündigungsbeitrag ist erfrischend deutlich über die Mechanik: "We pass through tokens at cost / We pass through compute at cost / We charge a base 8% orchestration fee on top of these costs."

Das macht den Credit zu einer Währung, nicht zu einem Gutschein. Der Wechselkurs ist veröffentlicht: 1 Credit = $0,005, also bekommst du für $1 200 Credits, und ein Modellaufruf für $0,03 sind 6 Credits, aufgerundet auf ganze Credits.

Ich habe genug Zeit damit verbracht, Abrechnungsdokumentationen für die Integrationen zu lesen, die ich bei eesel ausliefere, um zu wissen, dass dieser eine Satz in der Credits-Dokumentation der Satz ist, der zählt: "Agent credit costs are variable. The same agent might cost 2 credits for a quick question and 200 for a deep research task. You pay for what the agent actually does, not a fixed per-message price."

Das ist eine faire Art abzurechnen. Es ist auch eine schwierige Art zu planen, und beide Tatsachen liegen direkt übereinander. Du kaufst nicht 20.000 Aktionen. Du kaufst $100 zugrundeliegender Ausgaben zum Listenpreis, und der Wechselkurs zwischen "eine Sache, die ich erledigt haben wollte" und "Credits" wird zur Laufzeit vom Modell festgelegt, auf das der Agent zurückgreift.

Das ist auch auf meiner Seite des Zauns das wiederkehrende Muster des Gesprächs. Ich habe erlebt, wie ein Käufer an einem einzigen Testtag 200 Interaktionen erreichte und sofort anfing sich Sorgen zu machen, was das bei seinem tatsächlichen Volumen von etwa 9.000 im Monat bedeuten würde. Die Sorge war nicht der Preis pro Einheit. Es war, nicht zu wissen, wie viele Einheiten ein normaler Dienstag produziert.

Die fünf Zähler bei jedem Agenten-Chat

Ein Agenten-Gespräch wird als Summe von fünf separaten Dingen abgerechnet, laut Gumloops Dokumentation.

Gumloop veröffentlicht ein durchgerechnetes Beispiel, was ein gutes Zeichen ist: Ein Chat, der 400 Credits für Chat & Reasoning, 10 für Compute und 15 für Tool Calls ausgibt, "pays a 34 credit fee (8% of 425, rounded up), for 459 credits in total." Bei $0,005 pro Credit kostet dieses eine Gespräch $2,30.

Drei Details im Kleingedruckten lohnt es sich herauszugreifen, denn sie sind es, die den ersten Zähler still und leise aufblähen:

• Jede Nachricht sendet den bisherigen Kontext erneut mit, sodass ein langes Gespräch pro Runde mehr kostet als ein kurzes.
• Jedes verbundene Tool fügt seine Definition dem Prompt hinzu. Zwanzig selten genutzte Integrationen anzuhängen macht jede einzelne Nachricht teurer.
• Eine Nutzernachricht kann mehrere KI-Schritte auslösen, "and each step is billed separately."

Die Modellwahl ist der größte Hebel der drei, und das ist nicht mal knapp. Gumloops Recommended-Voreinstellung ist aktuell Grok 4.6, mit Fastest und Smartest als Presets links und rechts davon. Ein Frontier-Modell bei einer Aufgabe mit hohem Volumen gegen ein kleines Modell zu tauschen ändert den ersten Zähler um eine Größenordnung, weil du den tatsächlichen Satz des Anbieters zahlst: Meine Claude Preise-Aufschlüsselung gibt einen Eindruck von der Spanne, die hier durchgereicht wird.

Compute hat einen netten Sonderfall: Auf den Nutzer zu warten kostet nichts, und Enterprise-Kunden, die in ihrer eigenen VPC laufen, wird Compute überhaupt nicht berechnet.

Schätze deine eigene monatliche Gumloop-Rechnung

Statt dir ein Stufenraster hinzuwerfen, hier die tatsächliche Rechnung. Die Standardwerte bilden Gumloops eigenes veröffentlichtes 459-Credit-Beispiel nach, sodass du die Mathematik gegenchecken kannst, bevor du deine eigenen Zahlen einträgst.

Spiel kurz mit dem Regler "Minuten, die der Agent arbeitet". Von einer auf fünf Minuten zu gehen fügt 20 Credits pro Chat hinzu, was nach nichts klingt, bis man es mit ein paar hundert Gesprächen multipliziert. Compute ist der Zähler, den man vergisst, weil er als einziger Zeit statt Output abrechnet.

Es ist außerdem der Zähler, der genau das bestraft, worin Agenten eigentlich gut sein sollen. Ein regelbasierter Bot hat konstruktionsbedingt fixe Kosten pro Lauf. Ein Agent, der vier Minuten über einen schwierigen Fall nachdenkt, kostet viermal so viel wie einer, der in einer Minute antwortet, und das ist der Trade-off, den man verstehen sollte, bevor man einen regelbasierten Chatbot ersetzt durch etwas Intelligenteres.

Workflow-Läufe werden nach einer völlig anderen Formel abgerechnet

Das ist die nützlichste Unterscheidung in Gumloops Preismodell, und sie steckt in der Dokumentation, nicht auf der Preisseite.

Compute und die Orchestrierungsgebühr gelten nur für Agenten-Chats. Workflow-Läufe werden allein nach Node-Kosten abgerechnet, egal ob der Workflow eigenständig läuft oder von einem Agenten aufgerufen wird. Die veröffentlichte Formel lautet 1 credit (base) + the cost of each node that runs.

Und die meisten Nodes sind kostenlos. Gumloop listet Textbearbeitung (Combine Text, Text Formatter, Find & Replace), Logik (If/Else, Switch, Router), Loops, Datentransformation, Input/Output und "most integrations (Google Sheets, Slack, Gmail, Airtable, Salesforce, etc.)" mit null Credits auf. Das eigene Beispiel: ein Google Sheet lesen, die Zeilen filtern, eine Slack-Nachricht senden, Gesamtkosten 1 Credit.

Diese Liste kostenloser Integrationen lohnt sich genau zu lesen, denn hier ist die Plattform am günstigsten. Dieselben Connectoren, die hier nichts kosten, werden anderswo gemessen, und das ist genau die Art von Detail, die über eine Migration entscheidet.

Wenn du einen Umzug abwägst, habe ich die Äquivalente auf der n8n-Seite Connector für Connector kartiert. Google Sheets ist das, was die meisten Teams zuerst prüfen. Der Beitrag zu Salesforce deckt den CRM-Fall ab, wo die Node-Anzahl am schnellsten steigt.

Derselbe Job, auf zwei Wegen geroutet, führt also zu zwei sehr unterschiedlichen Rechnungen. Wenn eine Aufgabe deterministisch genug ist, um sie als geplanten Workflow auszudrücken, ist das spürbar günstiger, als einen Agenten sie konversationell erledigen zu lassen. Das ist der größte einzelne Kostenhebel im Produkt, und es ist eine Design-Entscheidung, keine Plan-Entscheidung, was man klären sollte, bevor man einen Workflow aufbaut, nicht danach.

Dieser Hebel hat einen Haken, und das ist der Grund, warum ich keinen Fünfjahresplan darauf aufbauen würde: Die Preisseite bezeichnet diese Hälfte des Produkts inzwischen als "Workflows (Legacy)". Der Schwerpunkt hat sich klar zu Agenten verschoben. Der günstige Weg funktioniert noch und ist weiterhin dokumentiert, aber man würde sich auf den Teil der Plattform verlassen, von dem sich das Unternehmen erkennbar entfernt. Das deckt sich mit dem, was ein Reddit-Kommentator berichtete, nachdem er mit dem Team gesprochen hatte: Man habe ihn eher zum Bau von Agenten-Schleifen ermutigt als zur Nutzung der Workflow-Funktion.

Was tatsächlich Credits kostet

Die kostenpflichtigen Nodes, aus der Credits-Dokumentation:

Gumloop weist selbst auf die Falle hin, was ich lieber zitiere als umschreibe: "Enriching 100 contacts costs 6,001 credits (1 + 60 x 100)". Diese eine Schleife ist 30% des monatlichen Pro-Kontingents, oder $30 von deinen $37. Nodes im Loop-Modus laufen einmal pro Element, jede Node-Kosten multipliziert sich also mit der Listenlänge.

Gebühren von Drittanbieter-Tools kommen zum 1-Credit-Tool-Aufruf oben drauf, und sie werden pro Ergebnis berechnet, nicht pro Aufruf. Die Apollo-Integration berechnet People Search mit 3 Credits pro Ergebnis, eine Suche mit 50 gefundenen Personen kostet also 150 Credits, nicht 3.

Genau hier beißen Credit-Modelle Leute, die Go-to-Market-Automatisierung statt interner Ops betreiben, denn Enrichment und Suche sind die beiden Nodes, die mit der Listenlänge skalieren, nicht mit der Anzahl der Läufe. Wenn das dein Anwendungsfall ist, lohnt sich zusätzlich ein Blick auf meine Übersicht zu KI-Marketing-Automatisierungstools.

Die Bonus-Credit-Klippe, über die niemand spricht

Das ist das Detail, das ich nicht erwartet hätte zu finden, und es steht in Gumloops eigener Dokumentation.

Die 20.000 Credits des $37-Pro-Plans setzen sich zusammen aus "7,400 credits at the $0.005 list price, plus 12,600 bonus credits." Overage wird dagegen zum nicht subventionierten Listensatz von $0,005 abgerechnet.

Rechnet man das durch, kosten die enthaltenen Credits jeweils etwa $0,00185. Die Overage-Credits kosten $0,005. Der Grenz-Credit über 20.000 hinaus kauft also etwa 2,7x weniger Arbeit pro Dollar als der durchschnittliche Credit im Plan.

Nichts davon ist versteckt oder unehrlich, und großzügige enthaltene Kontingente sind, wie die meisten nutzungsbasiert bepreisten Softwareprodukte funktionieren. Aber es bedeutet, dass die Kostenkurve nicht linear ist, und "wir zahlen halt ein bisschen Overage" ist ein schlechterer Deal, als der Plan-Preis vermuten lässt. Das ist auch, warum "ab $37" in diesem Satz mehr Arbeit leistet, als die meisten Leute hineinlesen.

Zwei Leitplanken federn die Landung ab, und sie sind besser als bei den meisten. Pay-as-you-go ist standardmäßig deaktiviert, sodass das Erreichen von 20.000 Credits deine Agenten stoppt, statt still und leise eine zweite Rechnung zu starten; du musst Overage erst aktiv einschalten. Ist es einmal aktiviert, ist die Pro-Overage immer gedeckelt, mit einer Standardobergrenze von 1.000.000 Overage-Credits ($5.000) pro Abrechnungszeitraum und einer niedrigeren, einstellbaren Grenze auf deiner Abo-Seite. Credit-Nutzungs-E-Mails werden bei 75% und 90% verschickt.

Zwischen diesen beiden ist die schlimmstmögliche Pro-Rechnung eine bekannte Zahl: $37 plus was auch immer für eine Grenze du einstellst, oder $5.037, wenn du den Standardwert unangetastet lässt. Das ist mehr, als die meisten nutzungsbasiert bepreisten Tools dir im Voraus sagen.

Eigener Schlüssel: 80% weniger Credits, doppelte Gebühr

Wenn du bereits direkt an Anthropic oder OpenAI zahlst, verändert BYOK die Rechnung erheblich. Chat & Reasoning fällt auf 0 Credits, und KI-Nodes, Bildgenerierung und Transkription in Workflows fallen ebenfalls auf 0.

Der Haken ist, dass sich die Orchestrierungsgebühr von 8% auf 16% verdoppelt, und sie wird auf das berechnet, was der Lauf wert gewesen wäre, nicht auf das, was dir tatsächlich in Rechnung gestellt wird. Gumloops eigener Vorher-Nachher-Vergleich am selben Chat:

Das ist eine Kürzung von 80% bei den Credits, aber es ist eine Verschiebung der Ausgaben, keine Ersparnis: Du zahlst jetzt deinem Anbieter für die Tokens. BYOK braucht Pro oder höher, jeder Schlüssel erlässt nur die Modelle, die dieser Anbieter bereitstellt, und Pro-Nutzer können persönliche oder im Team geteilte Schlüssel einrichten, aber keine auf Organisationsebene, das bleibt Enterprise vorbehalten. Es rührt außerdem nicht an Drittanbieter-Tool-Gebühren, da diese direkt durchgereicht werden.

Ob es sich lohnt, läuft auf etwas Einfaches hinaus: Wenn dein effektiver Satz bei deinem Anbieter besser ist als der Listenpreis, gewinnt BYOK. Wenn du auf Gumloops Bonus-Credit-Subvention gesetzt hast, vielleicht nicht.

Wofür Gumloop dich nicht berechnet

Es ist einfach, einen Preis-Beitrag zu schreiben, der nur die Zähler zählt, deshalb lohnt es sich, ehrlich zu sein, wo das Modell auf der Käuferseite steht.

Fehlgeschlagene Tool-Aufrufe werden nicht berechnet, klar und deutlich formuliert: "Every successful tool call costs at least 1 credit. Failed calls are not charged." Ein Workflow, der auf halbem Weg stoppt, wird nur für die Nodes abgerechnet, die vor dem Fehler liefen. Auf einen Menschen zu warten kostet nichts. Sitzplätze und Teams sind bei beiden Plänen unbegrenzt, anders als bei Zapier ist das zweite Teammitglied also kein Plan-Upgrade.

Die Transparenz-Tools sind ebenfalls besser als bei den meisten, und das lohnt sich zu erwähnen, denn viele nutzungsbasiert bepreiste Tools bieten nichts Vergleichbares. Es gibt ein Live-Coins-Badge im Chat-Header, das sich aktualisiert, während der Agent arbeitet, ein Chat-Details-Panel, das ein Gespräch in Zeilen pro Zähler aufschlüsselt, Credit-Logs, die nach Agenten-Chats oder Workflow-Läufen filterbar sind, und CSV-Export. Wenn du je versucht hast, eine KI-Ticketing-Rechnung mit dem abzugleichen, was der Bot tatsächlich getan hat, wirst du die Aufschlüsselung pro Gespräch zu schätzen wissen. Erlassene Credits unter BYOK werden weiterhin durchgestrichen und mit "Free" markiert angezeigt, sodass du siehst, was ein Lauf gekostet hätte. Das Insights-Dashboard und der Analytics-Agent, der Fragen wie "wie viele Credits haben wir letzten Monat pro Nutzer ausgegeben" beantwortet, sind Enterprise-exklusiv.

Enterprise bekommt außerdem Credit-Warnungen pro Chat: Wird eine konfigurierte Schwelle überschritten, pausiert der Agent und stellt eine Action Request zur Freigabe, bevor er weitermacht. Das ist gutes Design, und genau die Art von Kontrolle, die jedes Team wollen sollte, das KI-Agenten gegen Produktionsdaten laufen lässt. Es ist die Budget-Version desselben Musters hinter Agenten-Übergabe: im Voraus festlegen, wo die Maschine stoppt und ein Mensch übernimmt.

Die Lücke in all dem: Es gibt keine veröffentlichte Aussage dazu, ob ein Agenten-Chat, der Tokens und Rechenzeit verbraucht und dann mit einem Fehler abbricht, erstattet wird. Fehlgeschlagene Tool-Aufrufe sind abgedeckt. Fehlgeschlagene Workflows sind abgedeckt. Fehlgeschlagene Gespräche werden in keine Richtung adressiert, und da Tokens und Sitzungsminuten zu diesem Zeitpunkt schon verbraucht sind, ist die naheliegende Lesart, dass sie dich etwas kosten. Das ist die Frage, die ich vor der Unterschrift beim Vertrieb stellen würde.

Was Leute tatsächlich über die Rechnung sagen

Die Stimmung teilt sich sauber entlang einer Linie: wie lange der Workflow schon in Produktion ist. Nutzer in Woche eins mögen die Oberfläche. Nutzer im dritten Monat fangen an, "Credits" zu sagen.

"But Gumloop seems to freeze or have issues too frequently and then burns credits running faulty automation."

r/automation thread, Reddit

Es lohnt sich, hier präzise zu sein, denn das ist die am häufigsten wiederholte Beschwerde, und die Dokumentation beantwortet sie inzwischen teilweise. Gumloop berechnet fehlgeschlagene Tool-Aufrufe nicht, und ein fehlgeschlagener Workflow rechnet nur die bereits gelaufenen Nodes ab. Unadressiert bleibt der Agenten-Chat-Fall, und genau den beschreibt dieser Thread.

Die Lesart "einfacher, aber teurer" ist bemerkenswert konsistent über ein Jahr an Threads hinweg:

"-> Gumloop : Easy to build, easy to run but little more expensive."

Alexmamy, Reddit

"I think the biggest tradeoff with Gumloop is simplicity vs ownership. It's incredibly fast to prototype AI workflows, especially for non-devs, but once workflows become mission critical people start comparing reliability, hosting, and cost much more seriously."

EnvironmentalOil5959, Reddit

Gumloop muss man zugutehalten, dass der Preisdruck eine öffentliche Reaktion bekam statt eines Schulterzuckens. Der Einstiegspunkt von $37 existiert deshalb. Gumloops eigener Beitrag formulierte es als "making the starting point on Solo 10,000 credits for $37/mth down from $97/mth for 30,000 credits," und der Gründer verkündete es direkt:

"We heard you. Gumloop is getting a more affordable pricing tier. $37/month for 10,000 credits"

Max Brodeur-Urbas, X

Solo und Team wurden später in Pro zusammengeführt, daher stammt die aktuelle Zahl von 20.000 Credits für $37. Eine ehrliche Anmerkung zu dieser Migration: Unter 200k Credits bekamen Nutzer mehr für dasselbe Geld. An der Spitze der Leiter bekamen sie weniger, die 300k-Stufe fiel auf 250k und die 500k-Stufe auf 330k bei unveränderten Preisen. Vielnutzer mussten echte Einbußen hinnehmen.

Ein Vorbehalt zu den Bewertungsseiten. G2 zeigt 4,8/5 über 7 Bewertungen, und Capterra zeigt 5,0 über 2, und sechs der sieben G2-Bewertungen wurden innerhalb eines Zwei-Wochen-Fensters im Januar 2026 gepostet. Behandle diese Werte eher als dünn und frisch denn als abschließendes Urteil, in beide Richtungen.

Gumloop vs. Zapier, n8n, Make und Lindy bei der abrechenbaren Einheit

Der mit Abstand teuerste Fehler in dieser Kategorie ist es, Preise zu vergleichen, ohne Einheiten zu vergleichen. Sie sind nicht ineinander umrechenbar.

Die Lücke wird mit der Komplexität größer, nicht mit dem Volumen. Ein Trigger durch einen zehnstufigen Workflow, der 10 Datensätze verarbeitet, ist etwa 1 Ausführung bei n8n, etwa 10 Tasks bei Zapier und etwa 91 Operationen bei Make. n8n macht diesen Punkt auf der eigenen Preisseite und behauptet, eine einzelne Ausführung könne ersetzen, was anderswo 10.000 Operationen wären.

Dieses Einheitenproblem ist es wert, studiert zu werden, bevor man eine einzelne Dollarzahl vergleicht. Mein Vergleich Make vs n8n geht das im Detail durch. Für die Agenten-Ära-Version derselben Frage deckt AgentKit vs Zapier ab, wo die eigene Orchestrierung eines Modellanbieters gegenüber einem task-gemessenen etablierten Anbieter landet.

Wenn du mitten in der Shortlist statt mitten in der Migration hier gelandet bist, deckt die Übersicht Make-Alternativen das breitere Feld ab. Lindy-Alternativen ist die passendere Lektüre, wenn dich Credits pro Sitzplatz abschrecken.

Gumloops Einheit ist auf eine bestimmte Weise der Ausreißer: Sie ist die einzige, bei der die gleiche Aktion keinen stabilen Preis hat. Ein Zapier-Task ist ein Task, egal ob der KI-Schritt clever oder simpel war. Ein Gumloop-Credit folgt der darunterliegenden Modell-Rechnung, was gleichzeitig ehrlicher und schwerer vorhersagbar ist.

Für wen Gumloops Preismodell tatsächlich passt

Guter Fit: ein kleines Team, in dem ein oder zwei Leute viel bauen und konversationelle Agenten betreiben, bei denen der Wert pro Lauf hoch und das Volumen moderat ist. Recherche, Enrichment, Reporting, interne Wissens-Abfragen: Aufgaben, bei denen ein $2-Gespräch zwanzig Minuten aus jemandes Nachmittag ersetzt. Unbegrenzte Sitzplätze auf dem $37-Plan sind ungewöhnlich großzügig neben Zapiers Sitzplatz-Grenzen, und wenn du Enrichment- oder Recherchearbeit machst, bei der ein einzelner Lauf echtes Geld wert ist, sind die tatsächlichen Modellkosten plus 8% ein fairer Deal. Teams, die bereits einen Anbietervertrag haben und BYOK aktivieren können, fahren am besten.

Schlechter Fit: Automatisierung mit hohem Volumen und niedrigem Wert pro Lauf. Wenn du Tausende kleiner deterministischer Jobs abfeuerst, ist das Pro-Ausführung-Modell bei n8n oder die kostenlose Node-Struktur eines Gumloop-Workflows (kein Agent) der Ort, wo du sein willst, nicht konversationelle Agenten mit Compute und einem 8%-Aufschlag. Ebenfalls ein schlechter Fit, wenn du eine feste, vorhersehbare Monatszahl fürs Finanzteam brauchst, oder wenn 5 gleichzeitige Workflow-Läufe für dich eine echte Grenze sind, denn Pro bekommt an dieser Grenze eine harte HTTP-429-Ablehnung statt einer Warteschlange.

Kundenseitiges Volumen ist die schärfste Version dieses schlechten Fits. Support-Traffic schlägt genau an den Tagen aus, an denen du dir eine Überraschungsrechnung am wenigsten leisten kannst, weshalb ich KI-Kundenservice-Kosten zuerst als Volumenfrage und erst danach als Preisfrage behandle.

Meine Einschätzung: Gumloops Preismodell ist das intellektuell ehrlichste in dieser Kategorie und das am schwersten budgetierbare, und das ist dieselbe Eigenschaft, nur von zwei Seiten betrachtet. Passthrough-Abrechnung bedeutet, dass du nie einen Aufschlag auf ein günstiges Modell zahlst, das du nicht genutzt hast. Es bedeutet auch, dass deine Rechnung eine Funktion der Entscheidungen ist, die deine Agenten zur Laufzeit treffen. Geh mit einer bewusst gesetzten Overage-Grenze rein, nicht mit dem $5.000-Standardwert.

Was das bedeutet, wenn du den Support automatisierst

Ein Vorbehalt zu allem oben Genannten: allgemeine Automatisierungsplattformen sind für allgemeine Automatisierung bepreist. Wenn die konkrete Aufgabe die Support-Warteschlange ist, wird die Einheiten-Diskrepanz schärfer, denn ein Support-Ticket ist eine natürlich bemessene Arbeitseinheit und ein Credit ist es nicht. Man kann durchaus Kundenservice-Automatisierung auf einer credit-gemessenen Oberfläche bauen, und Leute tun das. Die Rechnung hört einfach auf, irgendetwas abzubilden, das deine Support-Leitung wiedererkennt.

Das ist die Design-Entscheidung hinter eesel. eesel berechnet $0,40 pro Ticket, und ein Ticket ist eine Aufgabe, egal wie viele Nachrichten hin und her gehen, wie oft der Kunde antwortet oder wie lange die KI darüber nachdenkt. Keine Plattformgebühr, keine Sitzplatzgebühr, kein Minimum. 1.000 Tickets im Monat sind $400, und das sind $400, egal ob jedes dieser Tickets zwei Runden oder zwölf brauchte. Der Zähler entspricht dem, was dein Team ohnehin schon zählt, sodass die Rechnung wie ein Support-Workflow-Report liest, nicht wie eine Compute-Rechnung.

Ein paar Dinge, auf die ich konkret hinweisen würde, weil sie daher kommen, dass ich beobachtet habe, wie es schiefgehen kann:

• Du kannst mit $50 kostenloser Nutzung ohne Kreditkarte starten, was ein anderes Angebot ist als ein Test, der eine Karte braucht und sich automatisch umwandelt.
• Es gibt ein monatliches Nutzungslimit, standardmäßig $250, mit E-Mail-Warnungen bei 50%, 75% und 100%. Agenten pausieren an der Grenze.
• Du kannst schrittweise ausrollen. Leite 200 deiner 1.000 monatlichen Tickets an die KI und du zahlst für 200, nie für die Tickets, die deine Menschen bearbeitet haben.
• Es trainiert auf deiner bestehenden Wissensdatenbank und deinen früheren Tickets, statt dass du erst eine Oberfläche aus Nodes von Hand bauen musst.
• eesel simuliert jeden Rollout gegen deine historischen Tickets, bevor es eine Live-Warteschlange berührt, denn ich habe schon erlebt, wie selbstbewusst klingende Bots falsche Antworten geben, und finde das lieber an den Tickets des letzten Quartals heraus als an denen von heute Morgen.

Es dockt an den Helpdesk an, den du schon betreibst, sodass ein Zendesk-Team nichts umziehen muss, um es auszuprobieren. Gleiches gilt für Freshdesk. Shopify-Shops auf Gorgias sind da nicht anders.

Der breitere Fall für Support-Ticket-Automatisierung ist eine eigene Lektüre, wenn du noch bei der Frage "lohnt sich das überhaupt" stehst.

Wenn deine Automatisierung Ops-Klebstoff über ein Dutzend SaaS-Tools ist, ist Gumloop das besser geeignete Tool, und das würde ich dir auch so sagen. Wenn es der Helpdesk ist und du willst, dass die Rechnung wie dein Ticketvolumen aussieht statt wie dein Token-Verbrauch, probiere eesel aus - es verbindet sich mit deinem bestehenden Ticketsystem und trainiert in ein paar Minuten auf deinen vergangenen Tickets.