Gemini Robotics 2: Was DeepMinds eigene Zahlen zeigen

Was Gemini Robotics 2 wirklich ist

Die Namensgebung tut hier niemandem einen Gefallen, also die einfache Version. „Gemini Robotics 2" ist der Familienname und zugleich der Name eines bestimmten Modells innerhalb dieser Familie. Drei Modelle wurden am selben Tag gemeinsam veröffentlicht, und jedes erledigt eine andere Aufgabe.

Diese Aufteilung ist wichtig, denn es ist dieselbe Architektur, die ich für jedes ernstzunehmende Agentensystem zeichnen würde. Ein Modell überlegt, was zu tun ist, und verfolgt, ob es funktioniert hat. Ein separates, schnelleres Teil übernimmt die Ausführung. DeepMind sagt ausdrücklich, dass ER 2 „die Motorausführung an ein beliebiges gegebenes untergeordnetes Vision-Language-Action(VLA)-Modell übergibt", das heißt, der Planer bleibt bewusst neutral gegenüber den Händen.

Ein Detail in der Dokumentation stellt das Ganze in ein neues Licht: ER 2 ist auf Gemini 3.5 Flash aufgebaut. Kein Pro-Tier-Derivat. Auch keine maßgeschneiderte Architektur. Es ist ein Flash-Klasse-Modell, in das räumliches Reasoning, das Finden von Video-Momenten und Multi-Roboter-Orchestrierung eingearbeitet wurden. Wer Gemini 3.6 Flash verfolgt hat, weiß bereits ungefähr, wie das Compute-Budget dahinter aussieht, und die Flash-Lite-Reihe erzählt dieselbe Geschichte.

Das Zeigen und die Koordinatenarbeit stammen aus derselben Linie wie Geminis agentische Vision. Und wer die Familie als Ganzes abwägt, dem empfehle ich meine laufend aktualisierte Liste der Gemini-Alternativen.

Die Behauptung der Ganzkörpersteuerung ist real und es lohnt sich, das klarzustellen. Frühere Versionen steuerten nur den Oberkörper eines Humanoiden, für Arbeiten auf einem Tisch. Diese steuert auch die Beine. Der Demo-Prompt, den DeepMind veröffentlichte, lautet „stelle die Gießkanne in die grüne Box im untersten Regal", und Apptronikss Apollo 2 geht zum Tisch, hebt die Gießkanne auf, geht zu den Regalen und stellt sie ab. Derselbe Modell-Checkpoint steuert auch einen Franka Duo, ausgestattet mit zweifingrigen Greifern, was der leiser beeindruckende Teil davon ist.

Die Zahlen, die DeepMind über sich selbst veröffentlicht hat

Hier ist die vollständige Tabelle, genau wie DeepMind sie berichtet hat. Alle drei Fähigkeitsgruppen laufen auf einem gemeinsamen Checkpoint, über drei verschiedene Roboterkörper hinweg, und deshalb ist die Streuung hier interessant statt peinlich.

Lesen Sie das obere und das untere Ende der Mehrfingergruppe zusammen, denn genau dieses eine Paar erzählt die ganze Geschichte davon, wo das Roboterlernen 2026 steht. Eine Glühbirne herausdrehen ist 92%. Eine einschrauben ist 36%. Beide verwenden dieselbe fünffingrige SharpaWave-Hand mit 22 Freiheitsgraden, am selben Roboter. Was sich unterscheidet, ist die Bewegung. Herausdrehen ist locker und verzeihend; Einschrauben verlangt, eine Ausrichtung zu halten, während man Drehmoment aufbringt. Das eine ist ein Griff. Das andere ist ein Regelungsproblem.

Die Greifer-Gruppe schlägt die Hand-Gruppe fast überall, und das ist der zweite Punkt, der es wert ist, kurz darüber nachzudenken. Ein zweifingriger Robotiq-Greifer am Franka Duo erreicht 89,6% beim präzisen Einsetzen, während die menschenähnliche Hand bei einem Ziplock-Beutel nur 40% schafft. Mehr Freiheitsgrade brachten schlechtere Ergebnisse bei der Feinarbeit. Zumindest vorerst.

Und DeepMind hat es selbst gesagt. Die Bildunterschrift lautet: „Während Gemini Robotics 2 bei Ganzkörper- und greiferbasierten geschickten Aufgaben eine mittlere bis hohe Erfolgsrate erreicht, bleibt die feinmotorische Manipulation mit mehreren Fingern eine Herausforderung." An anderer Stelle auf derselben Seite: „unsere Roboter müssen sich bei der Bewegungsgeschwindigkeit noch weiterentwickeln", wobei menschliche Fingerfertigkeit als Ziel formuliert wird, nicht als Behauptung.

Warum eine einzige gemischte Zahl all das versteckt hätte

Bildet man aus diesen fünf Mehrfinger-Aufgaben einen Durchschnitt, landet man irgendwo in der Mitte der Vierzigerwerte, ohne etwas gelernt zu haben. Man würde nicht wissen, dass das Modell bei einer Bewegung fast ausgereift und bei einer anderen kaum funktionsfähig ist. Man würde auch nicht wissen, um welche Aufgabe man beim Produktdesign einen Bogen machen sollte.

Das ist überhaupt kein Robotik-Problem. Es ist der Standardzustand von KI-Marketing in jeder Kategorie, meiner eigenen eingeschlossen, in der eine einzige Tier-1-Deflection-Zahl genau dieselbe Streuung verdeckt. Bewegen Sie die Zahlen selbst und beobachten Sie, wie leicht sich die Schlagzeile steuern lässt:

Probier "Nur die günstigen 4" aus, und heraus kommt eine Zahl, die jedes Marketingteam gerne drucken würde. Gleiches Modell, gleicher Tag, gleiches Labor. Es wurde absolut nichts erfunden, um sie zu erzeugen. Das ist der Trick, und er steht jedem Anbieter zur Verfügung, der eine einzige Zahl berichtet.

Die interessanteste Zahl handelt von Menschen, nicht von Robotern

Vergraben in den ER-2-Benchmarks steckt ein Vergleich, den DeepMind auf drei Arten durchführt. Er misst, wie gut das Reasoning-Modell einen nachgeschalteten Ausführenden lenkt, und was sich ändert, ist dieser Ausführende: erst ein echter Roboter, dann ein simulierter, dann ein menschlicher Teleoperator.

Derselbe Planer ist 14 Punkte besser darin, einen Menschen zu lenken, als einen Roboter zu lenken. Das Modell ist in keinem der beiden Fälle schlechter. Der Mensch auf der anderen Seite absorbiert einfach die Ambiguität, erholt sich von einem schlechten Griff, füllt aus, welche Absicht die Anweisung ausgelassen hat.

Ein Reddit-Kommentator, der sich das Demo-Material ansah, kam von außen zum selben Schluss:

"The bottleneck seems to be software. So until we get ai good enough to pilot a robot, it's going to remain slow.

If you see robots piloted by humans, they are much faster."

u/dranaei, Reddit

Das ist der Befund, den ich an eine Wand hängen würde, und es ist eigentlich kein Robotik-Befund. Es ist das KI-Copilot-Argument mit einer Zahl daran. Ein Modell, das plant und dann an einen fähigen Menschen übergibt, übertrifft dasselbe Modell, das den Endeffektor allein steuert, und die Lücke ist messbar. In der Support-Arbeit ist das der Unterschied zwischen einem Agenten, der eine Antwort entwirft, die jemand absendet, und einem Agenten, der selbst antwortet. Die ehrliche Antwort darauf, was besser abschneidet, ist dieselbe wie bei DeepMind: die mit einem Menschen im Regelkreis, bis die Zahlen pro Aufgabe etwas anderes sagen.

Nichts davon ist ein Argument gegen Autonomie. Es ist ein Argument dafür, die Zahl zu kennen, bevor man wählt, und diese Zahl bewegt sich schnell, schnell genug, dass die besten KI-Agenten von vor sechs Monaten nicht die sind, die man heute wählen würde.

Der Rest des ER-2-Vergleichssets ist stark, und es lohnt sich, fair darüber zu berichten:

Die Fortschrittsklassifizierung ist die größte Marge auf der ganzen Seite: 57,4% gegenüber 46,2% beim besten Nicht-Robotik-Modell. Die Metrik lautet „kann man sagen, wie weit man in einer Aufgabe fortgeschritten ist", bewertet pro Frame in fünf Kategorien. Unglamourös, und es ist genau das, was ein Agent wissen muss, bevor er entscheidet, ob er weitermacht oder um Hilfe bittet. DeepMind berichtet außerdem eine Genauigkeit von 91,3% beim Auffinden von Momenten, mit einem mittleren absoluten Abstand von 0,96 Sekunden, bei der 4-fachen Ausführungsgeschwindigkeit größerer Modellkategorien.

Es lohnt sich auch anzumerken, dass diese gleichen 57,4% bedeuten, dass es den Fortschritt ungefähr viermal von zehn falsch einschätzt. Bestes seiner Klasse, und liegt trotzdem so oft falsch, was in diesem Bereich ein normaler Zustand ist. Es ist auch genau die Art von Sache, die eine einzeilige „State of the Art"-Behauptung verwischt.

Der Sicherheitssprung, über den niemand spricht

Das ist die Zahl, die mich aufhorchen ließ. Ich habe sie bisher nirgendwo besprochen gesehen.

Gemini Robotics ER 1.6 befolgte Sicherheitsanweisungen in 47,2% der Fälle. Dieses Modell erschien im April 2026, also vor vier Monaten, und lag bei beiden Sicherheitsmetriken unter Opus 5 und unter GPT 5.6 Sol. Ein für Robotik feinabgestimmtes Modell, schlechter bei der Robotersicherheit als die allgemeinen Textmodelle, gegen die es verglichen wurde.

ER 2 behebt das gründlich, bis auf 97,9% und 93,0%. Gut. Die nützliche Lehre ist jedoch, was die Zahl der vorherigen Generation über das Vertrauen in ein Versions-Label aussagt. „Neuestes Robotik-Modell eines führenden Labors" war bis vor einer Woche etwas, das eine Sicherheitsvorgabe in weniger als der Hälfte der Fälle befolgte. DeepMind hat dafür auch einen neuen Benchmark veröffentlicht, ASIMOV-Agentic, als öffentlichen Datensatz. Er misst, ob der Reasoning-Agent einen unsicheren Tool-Call ablehnt, ob er vorhersagen kann, dass eine Aufgabe unmöglich ist, und dann, ob er bei Unsicherheit einen Menschen um Hilfe bittet.

Ablehnen, Fehlschläge vorhersagen, bei Unsicherheit eskalieren. Das ist eine bessere Beschreibung eines gut gebauten Support-Agenten, als es die meiste Support-KI-Dokumentation hinbekommt, und es überträgt sich direkt auf Eskalationsmanagement. Die Übergabe ist eine eigene Disziplin darüber hinaus, und Chat-Übergabe ist der Fall, den die meisten Teams zuerst falsch machen.

Es lohnt sich, hier bei den Grenzen präzise zu sein. Der Blog behauptet, ER 2 sei DeepMinds bisher sicherstes Robotik-Modell, veröffentlicht aber keinen numerischen Wert für die ASIMOV-Agentic-Ergebnisse selbst. Diese stehen in einem separaten Sicherheits-Technikbericht. Und die Entwicklerdokumentation ist unverblümt darüber, wo die Haftung liegt: „es liegt in Ihrer Verantwortung, eine sichere Umgebung um den Roboter herum aufrechtzuerhalten".

Was es kostet, und die Fallstricke in der Dokumentation

Nur ER 2 hat einen Preis. Die beiden Modelle, die Hardware anfassen, haben überhaupt keinen, aus dem einfachen Grund, dass man sie nicht kaufen kann.

Der Preis hat sich verdoppelt. ER 2 kostet sowohl beim Input als auch beim Output das Doppelte von ER 1.6, obwohl der pauschale Input-Satz bedeutet, dass audio-intensive Arbeit einen kleineren relativen Anstieg sieht als visionslastige Arbeit. Das Kontextfenster ist überhaupt nicht gewachsen. Es gibt auch ein Streaming-Geschwistermodell, gemini-robotics-er-2-streaming-preview, zum gleichen Grundtarif, ohne Batch-Tarif und ohne Caching.

Vier Dinge in der Dokumentation, die einen einen Nachmittag kosten, wenn man sie nicht vorher liest:

1. Ein uneingeschränkter API-Schlüssel bekommt einen harten 403. Robotik ist die einzige Gemini-Oberfläche, die einen Standardschlüssel ablehnt, also vor dem ersten Aufruf in AI Studio Einschränkungen hinzufügen.
2. Der Streaming-Endpunkt begrenzt Bildeingaben auf JPEG, 1 Frame pro Sekunde. Was seltsam gegen die ganze Echtzeit-Rahmung wirkt. Ein Roboter, der Kamera-Frames mit höchstens einem pro Sekunde streamt.
3. Der Streaming-Endpunkt lässt strukturierte Ausgaben und Code-Ausführung weg. Der JSON-Schema-Pfad gehört also dem Nicht-Streaming-Modell, und der agentische Vision-Pfad ebenfalls.
4. Die Dokumentation empfiehlt für Latenz ein medium-Denk-Level, aber das Erste-Schritte-Beispiel wird mit high ausgeliefert. Kopiert man es, erbt man die langsame Standardeinstellung.

Es gibt auch einen Datenschutzhinweis, der diesen Modellen angehängt ist und den keine gewöhnliche Gemini-Seite trägt. Da die Modelle „Video- und Audiodaten nutzen, um Ihre Hardware zu betreiben und zu bewegen", verlangt Google, dass keine identifizierbaren Personen im Umfeld des Roboters anwesend sind, bevor sie benachrichtigt wurden und eingewilligt haben, und fordert zusätzlich eine Gesichtsverpixelung. Stellt man das neben das „wird zur Verbesserung unserer Produkte verwendet: ja" der kostenlosen Stufe, wird ein Roboter der kostenlosen Stufe mit einer auf Menschen gerichteten Kamera zu einem Einwilligungsproblem, nicht zu einem Kontingentproblem.

Und ein Termin-Hinweis, den es sich lohnt, im Kalender zu vermerken: gemini-robotics-er-1.6-preview wird am 31. August 2026 abgeschaltet. ER 1.5 wurde bereits im April eingestellt. Also, zwei innerhalb eines Jahres eingestellte Endpunkte, und jeder aktuelle Modellcode trägt immer noch ein -preview-Suffix, ohne einen stabilen Alias, auf den man sich festlegen könnte.

Anpassung an neue Roboter, und der Multi-Roboter-Teil

Gemini Robotics On-Device 2 ist das Teil, das ich am unauffälligsten bedeutsam finde. Es läuft lokal, erbt die Motion-Transfer-Arbeit von Gemini Robotics 1.5, und passt sich an einen völlig neuen Zweiarm-Roboter an, „mit nur wenigen Stunden Anpassungszeit, typischerweise mit weniger als 200 Beispielen". Neue Formen, neue Sensoren, nicht passende Freiheitsgrade.

Weniger als 200 Demonstrationen, um einen neuen Roboterkörper hochzuziehen, das ist die Zahl, die die Ökonomie des Feldes verändert. Die Aufgaben in diesem Raster liefen auf Dexmate-, SO101- und Trossen-Plattformen, keine davon der Flaggschiff-Humanoide. Ein Panel zeigt einen Roboterarm, der eine „Ich bin ein Roboter"-Checkbox anklickt, was ich für einen Scherz halte und den ich zu schätzen weiß.

Multi-Roboter-Zusammenarbeit ist die andere neue Fähigkeit. Roboter, die kommunizieren, die körperlichen Stärken des anderen erkennen und sich dann gegenseitig Aufgaben zuweisen. In der Demo arbeitet ein Apollo-2-Humanoide neben einem Franka-Arm, mit einem Monitor, der zeigt, was das Modell sieht.

DeepMind bedankte sich bei Apptronik, Boston Dynamics und Agile Robots als Partner, und in einer separaten Demo holt ein Boston-Dynamics-Spot über orchestrierte Spot-APIs Popcorn. Auf der Hardware-Seite: Apptronik sammelte im Februar 2026 eine Serie A-X über 520 Mio. $ ein, wodurch das Gesamtvolumen auf fast 1 Mrd. $ steigt. Es lohnt sich zu vermerken, dass Apollo 2 eine Datensammlungsplattform ist und nicht die kommerzielle Einheit. Die kommerzielle ist Apollo 3, und dafür gibt es noch keinen angekündigten Termin. Keine veröffentlichten Spezifikationen und kein veröffentlichter Preis, von keinem der vier beteiligten Hardware-Anbieter.

Was Praktiker tatsächlich sagten

Der Hacker-News-Thread erreichte 619 Punkte und 553 Kommentare, und er ist die bessere Lektüre als jede der Berichterstattungen. Der nützlichste Kommentar dort kam von jemandem, der an diesen Modellen arbeitet:

"Plus we have no good reliable accuracy testing data in most cases (most tests occur on a few demos, but that isn't a good representation of how must things work), popular benchmarks, such as libero have been saturated, and nearly everything gets 95% there, most companies and researchers have their own benchmarks here."

adityashankar, Hacker News

Gesättigte Benchmarks, und alle bewerten ihre eigenen Hausaufgaben. Das beschreibt auch die Bewertung von Software-KI, fast wortwörtlich, und deshalb setzt OpenAIs eigene Bewertungsanleitung so stark darauf, ein eigenes Evaluationsset zu bauen, statt einem öffentlichen Leaderboard zu vertrauen.

Die schärfste Kritik betrifft überhaupt nicht das Modell. Sie betrifft die Video-Grammatik:

"This is why we need long continuous shots of robots interacting doing tasks, rather than the sizzle reels with 5 second shots. The long shots tell the true story of how far along the technology is, while the short shots make it look way more advanced than it really is. Still, great to see the progress being made."

u/edgroovergames, Reddit

Ein HN-Kommentator ging noch weiter und bezeichnete die Demos als „glorifiziertes Pick-and-Place mit niedrigen Erfolgsraten auf einem unnötig komplexen Roboter", und sagte, er bevorzuge das offen teleoperierte Material eines Konkurrenten, weil es näher am realen Einsatz liege. Hart. Angesichts der 45,7% aber auch nicht unvernünftig.

Diese 36%-Zahl wurde dann als Beleg für ein breiteres Argument aufgegriffen:

"A 36% success rate on screwing in a light bulb means there's probably something to LeCunn's take that VLM/VLA models aren't going to be the thing powering tomorrow's robots, but only time will tell."

cowboy_henk, Hacker News

Die beste Erwiderung kam in einer Zeile, und auf die würde ich setzen:

"It's still very early days. There are many benchmarks that LLMs scored 36% on just 18 months ago that they're now at 100% on."

heaney-555, Hacker News

Und dann ein Robotiker, der erklärt, warum „langsam und vorsichtig" eine andere Problemklasse ist als „schnell und flüssig":

"An algorithm to fold tshirts 90% of the time is easy. The cloth hangs down by gravity and you can just look for right angles (corners), find their coordinates with binocular matching, and move them to meet each other. Getting 99%, or folding them quickly, so that the fabric is actually moving instead of just hanging still- incredibly, incredibly more complex."

hwillis, Hacker News

Es gab dort auch eine ordentliche Menge an „hat Figure das nicht schon gezeigt", was mich zu dem Vergleich bringt, der tatsächlich zählt.

Niemand sonst veröffentlicht diese Tabelle

Ich habe nach den entsprechenden Zahlen pro Aufgabe von jedem anderen Labor in diesem Bereich gesucht. Hier ist, was öffentlich ist, alles davon.

DeepMind ist der einzige, der absolute Fehlerraten pro Aufgabe auf der eigenen Launch-Seite veröffentlicht hat. Figure benennt Fingerfertigkeits-Aufgaben und zeigt einen vierminütigen Geschirrspüler-Durchlauf im Video, ohne dem irgendeine Zahl beizufügen. Tesla hat noch nie ein Optimus-Modell benannt, überhaupt nicht. Physical Intelligence stellt zwar Werte pro Aufgabe grafisch dar, aber gegen eine RL-Spezialisten-Baseline, und mit clientseitig gerenderten statt angegebenen Werten.

Die ehrliche Lesart von Gemini Robotics 2 lautet also nicht „Googles Roboter hinkt hinterher". Google ist der einzige, der zeigt, wo sein Roboter tatsächlich steht, und wird dann für die Zahlen kritisiert, die es zu veröffentlichen entschieden hat. Das ist ein schlechter Anreiz. Wenn das so bleibt, veröffentlicht das nächste Labor einfach nur noch Videos.

Was das bedeutet, wenn man KI-Agenten kauft

Ich arbeite nicht an Robotern. Ich baue KI-Agenten, die Support-Tickets bearbeiten, und diese Veröffentlichung hat tatsächlich verändert, was ich denke, dass ein Anbieter mir zeigen sollte.

Es gab einen Kunden, ein dänisches B2B-Team für Fahrzeug-Telematik, das rund 200 Tickets im Monat über Zendesk bearbeitete und auf 2.000 zusteuerte, dessen Agent begann, Kunden selbstbewusst zu erzählen „ja, wir unterstützen Ihr Automodell" für Marken, die nicht in der Datenbank standen. Die Wissensdatenbank sagte „wir unterstützen alle Modelle". Der Bot glaubte es. Ihre eigene Zusammenfassung dieser frühen Einrichtung war „am Anfang Versuch und Irrtum". Dieser Tickettyp hätte in einer Tabelle pro Aufgabe eine glatte Null erzielt, und in der gemischten Zahl war er einfach unsichtbar. Das ist die gewöhnliche Fehlerform in der Automatisierung des Kundenservice, nichts Exotisches, und deshalb ist Halluzinationsprävention eher eine Konfigurationsfrage als eine Modellfrage.

Deshalb führt jedes eesel-Rollout zuerst eine Simulation gegen die eigene Ticket-Historie des Kunden durch. Man nimmt einen Stapel gelöster Tickets, generiert, was der Agent gesagt hätte, vergleicht das mit dem, was der Mensch tatsächlich geschickt hat, bewertet es, und erstellt dann einen Lückenbericht, bevor ein einziger echter Kunde beteiligt ist. Es ist DeepMinds Tabelle, nur aus den eigenen Tickets statt aus Glühbirnen gebaut. Eine CX-Leiterin bei einer D2C-Nahrungsergänzungsmittel-Marke hat die Anforderung besser formuliert, als ich es könnte:

"The AI will never be able to answer 100% of the questions... I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

Drei Dinge, die ich aus dieser Veröffentlichung in jeden KI-Agenten-Kauf mitnehmen würde, physisch oder nicht:

1. Nach der Tabelle pro Aufgabe fragen, nicht nach der Schlagzeile. Wenn ein Anbieter eine einzige Deflection-Zahl nennt, danach fragen, sie nach Intent oder Tickettyp aufzuschlüsseln. Die Streuung ist, wo die Wahrheit liegt, und KI-Leistungskennzahlen sind nur bei dieser Granularität nützlich. Dasselbe gilt für First Contact Resolution.
2. Vor dem Live-Gang mit der eigenen Historie testen. Ein Benchmark, der auf den Aufgaben eines anderen läuft, sagt nichts über die Grenzfälle der eigenen Rückerstattungsrichtlinie voraus. Derselbe Instinkt wie bei adversarialen Tests, und der Grund, warum Agenten zu evaluieren besser ist, als einer Demo zu vertrauen.
3. Für die 32%-Aufgabe designen, nicht für die 92%-Aufgabe. Wissen, welche Arbeit der Agent ablehnen sollte. Konfidenzschwellen bewusst setzen, die Übergabe sauber halten. Eine selbstbewusst falsche Antwort zu verhindern ist mehr wert als ein Prozentpunkt Coverage.

Der letzte Punkt ist das ganze Spiel. Ein Agent, der 60% der Tickets löst und den Rest dann sauber eskaliert, ist ein besseres Produkt als einer, der 100% versucht und bei einem von fünf falsch liegt, und Kunden sagen mir das ständig. Auch die Rechnung der Kosten pro Lösung fällt besser aus, sobald man die Tickets einpreist, die eine schlechte Antwort erzeugt.

Wer das umfassendere Messbild sucht, mein Artikel zur Bewertung des Kundenservice geht tiefer, als ich es hier kann, ebenso der Vergleich Agent-Kosten gegenüber Mensch-Kosten. Und wer noch ein Basismodell wählt, für den ist welches LLM für den Support am besten passt eine bessere Ausgangsfrage als jeder Robotik-Benchmark.

eesel ausprobieren

Wer nach agentischer Kundenservice-Software sucht und die Ehrlichkeit pro Aufgabe will, für die dieser Beitrag immer wieder plädiert, für den wurde eesel mehr oder weniger genau dafür gebaut. Es lässt sich in Zendesk oder jedes bereits genutzte Helpdesk einbinden, Freshdesk eingeschlossen. Es lernt aus Makros und vergangenen Tickets. Dann führt es eine Simulation über die echte Historie durch, sodass man die Form seiner Genauigkeit pro Tickettyp sieht, bevor es je einem Kunden antwortet.

Der konkrete Unterschied: Man entscheidet selbst, welche Tickettypen berührt werden und welche unangetastet bleiben, und man erhält Genehmigungs- und Ablehnungszahlen pro Aktion statt eines einzigen Deflection-Prozentsatzes. Gridwise sah im ersten Monat 73% der Tier-1-Anfragen gelöst und wusste, welche der 27% es nicht waren. Die Preisgestaltung erfolgt pro Ticket, sodass man keine Sitzplätze für einen Agenten kauft, der nur einen Bruchteil der Warteschlange bearbeitet.

eesel ausprobieren, kostenlos, oder einfach hundert alte Tickets darauf richten und sehen, was der Lückenbericht sagt.