
KI Dieser Artikel wurde mit Hilfe von KI erstellt.
Wichtige Erkenntnisse
Wenn du Voice-to-CRM bewertest, fängt die Diskussion fast immer bei der Wortfehlerrate an. Der Wert hat eine klare Definition: Die WER ist die Summe aus Ersetzungen, Auslassungen und Einfügungen, geteilt durch die Wortzahl des menschlich erstellten Referenztranskripts[1]. Das ist eine saubere Metrik für Spracherkennungsmodelle. Für deine CRM-Datenqualität reicht sie nicht.
Wichtig zur Einordnung: Das hier ist keine allgemeine Rangliste von Sprachmodellen. Es geht um die Grenze der Metrik. Ein niedriger WER ist eine notwendige, aber keine hinreichende Bedingung für saubere CRM-Daten. Deshalb prüfst du Voice-to-CRM an den Werten, die deine Pipeline wirklich trägt: Namen, Beträge, Mengen und Produktcodes.
Dein Testset braucht Verwechslungspaare, die im echten Vertriebsalltag auseinandergehalten werden müssen. Fiktive, aber realistische Fälle reichen dafür völlig: Sie müssen nur die Fehlermuster abdecken, die später auch deine echten Deals treffen.
Zu jedem Fall notierst du vorab zwei Dinge: den Sollwert und das Ziel-CRM-Feld. Erst dieser Soll-Ist-Vergleich macht den Test auswertbar. Ohne die Notierung diskutierst du hinterher, was der Assistent 'gemeint' haben könnte, statt messen zu können.
Der letzte Punkt ist der wichtigste. Entitätsfehler, also ein falscher Name oder eine falsche Nummer, schaden deinen Daten mehr als ein halber Punkt Gesamt-WER. Ein generisches Testset mit Standardsätzen blendet genau diese Fehler aus.
Ein Test im stillen Büro sagt wenig aus über den Moment, in dem es zählt: nach dem Kundentermin, im Auto, auf der Straße. Du wiederholst dieselben Fälle über denselben Kanal, den du auch im Alltag nutzt, unter zwei Bedingungen.
Zur Einordnung der Stichprobe: Microsoft verlangt für aussagekräftige Genauigkeitstests 30 Minuten bis 5 Stunden repräsentatives Audio[2]. Ein einzelner Testlauf liegt weit darunter. Leite daraus keinen repräsentativen Benchmark ab, sondern behandle ihn als Momentaufnahme. Die WER hängt stark von Bedingung und Umgebung ab; dieselben Fälle können im Büro sauber und im stehenden Auto fehlerhaft erkannt werden.
Praktisch heißt das: Plane mehrere kurze Läufe über mehrere Tage ein, nicht einen langen Marathon. Notiere pro Lauf, welche Fälle wiederholt scheitern. Wiederholte Fehler unter gleichen Bedingungen sind ein echtes Muster, ein einmaliger Ausreißer ist meist nur Lärm.
Wenn ein Wert falsch im CRM landet, kann das vier verschiedene Ursachen haben. Erst wenn du die Ebenen trennst, weißt du, wo du ansetzen musst: beim Sprachmodell, bei der Normalisierung, bei der Feldzuordnung oder beim Datensatz-Matching.
Das Endziel ist das strukturierte CRM-Update aus dem Sprachdebrief: Die Daten müssen im richtigen Feld und im richtigen Format ankommen, nicht nur im Transkript stehen. Genau so arbeiten die Phone Assistants: Aus dem gesprochenen Debrief entstehen strukturierte Updates, die im CRM in den richtigen Feldern landen[3].
Pro Fehler hältst du fest, welche Korrektur nötig war und wie lange sie gedauert hat. Das ist deine eigentliche Währung: nicht die Fehlerzahl, sondern der verbleibende Korrekturaufwand pro Fall. Das Datensatz-Matching selbst, also die Zuordnung eines Gesprächs zum richtigen CRM-Eintrag, ist ein eigenes Thema und bleibt einem eigenen Artikel vorbehalten.
Es gibt eine technische Möglichkeit, kritische Begriffe zu stärken: Phrase-Listen. Das sind vorab hinterlegte Begriffslisten, die das Erkennungsgewicht dieser Wörter erhöhen, ohne ein eigenes Modell zu trainieren. Microsoft beschreibt das für die Azure Speech Services: Namen, Orte, Homonyme und branchenspezifische Begriffe lassen sich per Phrase-Liste gewichten, und das Gewicht lässt sich in einer Spanne von 0,0 bis 2,0 einstellen[4].
Azure ist hier ein Beispiel für die technische Machbarkeit, kein Nachweis über eine konkrete Produktarchitektur: Welcher Anbieter welche Engine im Hintergrund nutzt, kannst du von außen meist nicht prüfen. Die Frage, die du deinem Anbieter stellst, bleibt aber dieselbe, egal welche Engine läuft.
Der dritte Punkt ist oft wirksamer als jede Modellmetrik. Eine Rückfrage kostet Sekunden. Ein falscher Betrag im Forecast kostet Glaubwürdigkeit, bei der nächsten Pipeline-Review und gegenüber der Geschäftsführung. Ein Assistent, der kritische Werte aktiv bestätigt, entlastet dich mehr als ein Transkript, das flüssig aussieht, aber im Detail danebenliegt.
Am Ende zählt ein Abnahmebogen, kein Demo-Eindruck. Du füllst ihn mit deinen eigenen Fällen und legst die Schwellen vor dem Test fest, gemeinsam mit Sales-IT und Team. Übernimm keine Genauigkeitsgarantie aus Vendor-Demos; ein Vorschlag für Schwellen ist genau das: ein Vorschlag, den ihr vor dem Test abstimmt.
Die problematischen Fälle aus deinem Testset wiederholst du gezielt mit den Bliro Phone Assistants (Vicky & Tim). Die Assistenten führen vor und nach dem Kundentermin ein echtes Sprachgespräch, strukturieren den Debrief zu einem Besuchsbericht und füllen CRM-Felder aus dem Gesagten, statt getippt zu werden[3]. Genau dieser Weg, vom gesprochenen Satz bis zum gefüllten Feld, ist das, was dein Abnahmebogen prüft.
Bliro besteht deinen Praxistest also dann, wenn die kritischen Werte aus deinem echten Sortiment zuverlässig im richtigen Feld landen, ungelöste Fehler unter deiner Schwelle bleiben und die Korrekturzeit im Rahmen bleibt. Alles andere ist Demo.
Du hast jetzt zwei Werkzeuge: ein Testset mit Verwechslungspaaren, Sollwerten und Ziel-CRM-Feldern, und einen Abnahmebogen mit drei Messgrößen. Beides funktioniert ohne Vendor-Unterstützung. Nimm beides und teste deine eigenen Namen, Beträge und Produktcodes, nicht die eines Demo-Accounts.