Die Grundidee lässt sich an einem Alltagsbeispiel erklären. Ein Kunde schreibt in einen Chat auf der Website: „Ich möchte meinen Liefertermin verschieben.“ Damit eine Software sinnvoll reagieren kann, muss sie zweierlei verstehen – erstens das Anliegen (der Kunde will einen Termin ändern) und zweitens die relevanten Details (welcher Auftrag, welches neue Datum). Genau diese Übersetzung von frei formuliertem Text in strukturierte Absichten und Daten ist die Kernaufgabe von Dialogflow. Auf dieser Grundlage kann der Bot dann eine Antwort geben, eine Rückfrage stellen oder im Hintergrund ein anderes System ansprechen.
Dialogflow ist damit kein fertiger Chatbot, den man nur einschaltet, sondern ein Baukasten und eine Laufzeitumgebung. Das Unternehmen oder ein Dienstleister entwirft die Dialoge, hinterlegt Beispielsätze, definiert die Geschäftslogik und verbindet den Bot mit den eigenen Backend-Systemen. Google stellt die Infrastruktur, die Spracherkennung, die Sprachsynthese und – zunehmend – generative KI-Bausteine bereit.
Dialogflow hat eine längere Geschichte, als der Name vermuten lässt. Die Wurzeln liegen in einem Startup namens API.AI, das Google 2016 übernahm und kurz darauf in Dialogflow umbenannte. Über viele Jahre war Dialogflow eine der meistgenutzten Plattformen, um regelbasierte und absichtsgesteuerte Dialogsysteme zu bauen – lange bevor große Sprachmodelle den Markt veränderten. Wer in den vergangenen Jahren mit einem Service-Chatbot eines größeren Unternehmens kommuniziert hat, hat mit einiger Wahrscheinlichkeit indirekt mit Dialogflow oder einer vergleichbaren Plattform interagiert.
Diese Geschichte ist mehr als eine Randnotiz, denn sie erklärt den heutigen Charakter der Plattform. Dialogflow stammt aus der Ära strukturierter Dialogmodellierung und trägt diese Denkweise in sich. Mit der Verbreitung generativer Modelle musste Google die Plattform neu positionieren – ein Prozess, der bis heute andauert und der für die Bewertung von Dialogflow zentral ist. Wer Dialogflow nur als „klassischen Chatbot-Baukasten“ oder ausschließlich als „LLM-Plattform“ beschreibt, greift jeweils zu kurz.
Dialogflow richtet sich an Unternehmen, die Kundeninteraktionen automatisieren wollen – typischerweise im Kundenservice, im First-Level-Support, bei der Terminvereinbarung, bei Statusabfragen oder bei der Vorqualifizierung von Anfragen. Klassische Einsatzfelder sind Service-Chatbots auf Websites, Bots in Messaging-Kanälen und – ein für viele überraschender Schwerpunkt – Telefon-Voicebots, die Anrufe entgegennehmen und einfache Anliegen ohne menschlichen Agenten lösen.
Für den deutschen Mittelstand ist Dialogflow vor allem dann interessant, wenn wiederkehrende Standardanfragen einen großen Teil des Kommunikationsaufkommens ausmachen. Ein Handwerksbetrieb mit hohem Anrufvolumen, ein Online-Händler mit immer gleichen Fragen zu Versand und Retoure, ein Dienstleister mit Terminbuchungen – das sind die Konstellationen, in denen sich Automatisierung wirtschaftlich rechnet. INAGRO bewertet Dialogflow in solchen Projekten als solide, ausgereifte Plattform, deren Stärke in der Telefonie und in der tiefen Integration in die Google-Cloud-Welt liegt. Gleichzeitig ist die Plattform anspruchsvoller in der Einführung als manche werbliche Darstellung vermuten lässt.
Der wichtigste Unterschied zwischen ES und CX ist nicht der Funktionsumfang, sondern die Denkweise. In Dialogflow ES dreht sich alles um Intents und sogenannte Kontexte. Ein Intent beschreibt eine Absicht, und Kontexte steuern, welche Intents in welcher Situation aktiv sind. Bei einfachen Bots funktioniert das gut. Sobald ein Dialog jedoch viele Verzweigungen, Rückfragen und Zustände hat, wird das Geflecht aus Kontexten schnell unübersichtlich. Erfahrene Entwickler beschreiben das gern als „Kontext-Spaghetti“ – ein Dialog, dessen Logik kaum noch nachvollziehbar ist.
In Dialogflow CX hat Google deshalb ein anderes Modell eingeführt. Hier denkt man in Flows (abgegrenzte Themenbereiche) und Pages (einzelne Zustände innerhalb eines Flows). Der Bot befindet sich zu jedem Zeitpunkt in einem definierten Zustand und kennt klare Übergänge. Das entspricht dem bewährten Konzept eines Zustandsautomaten und macht selbst sehr große Dialoge handhabbar. Wer schon einmal ein komplexes Telefonmenü oder einen mehrstufigen Buchungsprozess modelliert hat, erkennt den Vorteil sofort: Die Struktur bleibt auch bei hundert Dialogschritten lesbar und wartbar.
Aus Sicht von INAGRO ist die Empfehlung in den meisten neuen Projekten eindeutig: Für ernsthafte, langfristig gedachte Bots ist CX die richtige Wahl. CX ist die Edition, in die Google aktiv investiert, sie trägt die generativen Funktionen und sie skaliert deutlich besser. ES wirkt zunächst einfacher, führt aber bei wachsenden Anforderungen häufig in eine Sackgasse, aus der nur ein kompletter Neuaufbau in CX herausführt.
Dialogflow ES kann dennoch sinnvoll sein – für sehr kleine, klar umrissene Bots mit wenigen Anliegen, bei denen niedrige Einstiegshürden und schnelle Ergebnisse zählen und absehbar keine Erweiterung geplant ist. Ein häufiger Fehler in der Praxis ist allerdings, dass Projekte „zum Ausprobieren“ in ES starten, dann wachsen und schließlich teuer migriert werden müssen. Wer von Beginn an Skalierung mitdenkt, fährt mit CX meist besser. Es ist wichtig zu betonen, dass eine Migration von ES nach CX kein einfacher Knopfdruck ist, sondern in der Regel eine Neumodellierung des Dialogs bedeutet.
Ein Intent ist die erkannte Absicht eines Nutzers. Wenn jemand schreibt „Wann kommt mein Paket?“, „Wo ist meine Lieferung?“ oder „Sendungsstatus bitte“, steckt dahinter immer dasselbe Anliegen – eine Statusabfrage. In Dialogflow definiert man dafür einen Intent und hinterlegt mehrere Beispielsätze, die alle dasselbe Anliegen ausdrücken. Aus diesen Beispielen lernt das System, auch unbekannte Formulierungen demselben Intent zuzuordnen. Man trainiert den Bot also nicht mit starren Schlüsselwörtern, sondern mit Beispielen für gemeinte Bedeutungen.
Die Qualität eines Bots steht und fällt mit der Sorgfalt bei den Intents. Zu wenige Beispielsätze führen zu schlechter Erkennung, zu stark überlappende Intents führen zu Fehlzuordnungen. In der Praxis ist das Modellieren guter Intents eine der zeitintensivsten und zugleich wichtigsten Tätigkeiten – und ein Bereich, in dem Erfahrung deutlich den Unterschied macht.
Während der Intent das Anliegen erfasst, beschreiben Entities die konkreten Informationen innerhalb einer Äußerung. Im Satz „Ich möchte einen Termin am Dienstag um 14 Uhr in der Filiale Köln“ steckt der Intent „Termin vereinbaren“ – und gleich mehrere Entities: ein Datum, eine Uhrzeit und ein Ort. Dialogflow bringt zahlreiche vordefinierte Entity-Typen mit, etwa für Datum, Zeit, Zahlen, Währungen oder geografische Angaben. Darüber hinaus lassen sich eigene Entities definieren, beispielsweise für Produktnamen, Tarife oder unternehmensspezifische Begriffe.
Entities sind der Mechanismus, mit dem aus unstrukturiertem Text strukturierte Daten werden – also genau die Daten, die ein nachgelagertes System wie ein Buchungssystem oder eine Auftragsverwaltung benötigt. Eine durchdachte Entity-Struktur ist deshalb die Brücke zwischen natürlicher Sprache und Geschäftslogik.
In Dialogflow CX organisieren Flows und Pages den Gesprächsverlauf. Ein Flow bündelt einen zusammenhängenden Themenbereich – etwa „Terminbuchung“, „Reklamation“ oder „Tarifwechsel“. Innerhalb eines Flows beschreiben Pages die einzelnen Schritte, also Zustände, in denen sich der Bot befindet. Auf einer Page sammelt der Bot beispielsweise gezielt die Informationen, die ihm noch fehlen, und wechselt anschließend zur nächsten Page.
Dieses Zustandsmodell ist der Grund, warum CX auch sehr komplexe Dialoge beherrschbar hält. Statt eines unübersichtlichen Geflechts gibt es klar abgegrenzte Schritte mit definierten Übergängen. Der Bot „weiß“ zu jedem Zeitpunkt, wo im Gespräch er sich befindet, was er bereits erfragt hat und was noch fehlt – ein wesentlicher Unterschied zur lockeren Kontextlogik in ES.
Bis hierher kann ein Bot Sprache verstehen und Dialoge führen – aber er kennt keine echten Geschäftsdaten. Genau das leisten Webhooks. Ein Webhook ist eine Schnittstelle, über die Dialogflow während eines Gesprächs ein externes System aufruft. Wenn ein Kunde nach dem Status seiner Bestellung fragt, ruft der Bot per Webhook die Auftragsverwaltung auf, holt den aktuellen Status und gibt ihn in der Antwort zurück. Ohne Webhooks bleibt ein Bot ein nettes Gesprächsspielzeug; mit Webhooks wird er zu einem produktiven Werkzeug, das echte Vorgänge abwickelt.
Die Webhook-Anbindung ist technisch der anspruchsvollste Teil eines Dialogflow-Projekts und meist der Punkt, an dem die eigentliche Entwicklungsarbeit beginnt. Sie erfordert eine programmierte Logik – oft als Cloud Function bei Google Cloud realisiert – sowie sauber dokumentierte Schnittstellen der angebundenen Systeme. Realistischerweise liegt hier ein Großteil des Projektaufwands, und hier entscheidet sich, ob ein Bot tatsächlich Mehrwert liefert oder nur Standardtexte ausgibt.
Klassisches Dialogflow ist regelbasiert. Der Bot kann nur das, was vorher modelliert wurde – jeder Intent, jede Antwort, jeder Übergang muss von Hand angelegt werden. Das gibt maximale Kontrolle, ist aber arbeitsintensiv und unflexibel: Eine Frage, die niemand vorhergesehen hat, beantwortet ein rein regelbasierter Bot nicht. Generative KI dreht dieses Prinzip um. Ein Sprachmodell kann auch unerwartete Formulierungen verstehen, frei antworten und auf Basis hinterlegter Dokumente argumentieren – ohne dass jede Variante vorab definiert wurde.
In den Conversational Agents lassen sich generative Bausteine an mehreren Stellen einsetzen. Erstens kann ein Bot über sogenannte Datenspeicher oder Wissensquellen auf hinterlegte Dokumente zugreifen – Handbücher, FAQ-Seiten, Produktinformationen – und daraus eigenständig Antworten formulieren. Dieses Vorgehen, bei dem ein Sprachmodell seine Antworten auf konkrete Quelldokumente stützt, nennt man Retrieval-augmented Generation. Der praktische Effekt: Statt hundert FAQ-Intents von Hand zu pflegen, lädt man die vorhandene Wissensbasis hoch und der Bot beantwortet darauf gestützte Fragen weitgehend selbst.
Zweitens können generative Modelle das Verstehen verbessern, indem sie auch ungewöhnliche oder unvollständige Eingaben sinnvoll interpretieren. Drittens lassen sich Antworten natürlicher und flüssiger formulieren, weil sie nicht mehr aus starren Textbausteinen bestehen. Damit nähert sich Dialogflow dem an, was Nutzer von modernen Chat-Assistenten gewohnt sind.
Entscheidend für die Praxis ist, dass Dialogflow keinen Entweder-oder-Zwang aufmacht. Die Stärke der neuen Generation liegt im Hybrid-Ansatz: kritische, regulierte oder transaktionale Abläufe werden weiterhin strikt regelbasiert über Flows modelliert, während offene Wissens- und Beratungsfragen generativ beantwortet werden. Ein Bot kann also einen Kontostand oder eine Terminbuchung streng kontrolliert abwickeln und gleichzeitig allgemeine Fragen frei beantworten.
Dieser kombinierte Ansatz ist aus Sicht von INAGRO der eigentliche Reifegrad-Vorteil der Plattform. Reine LLM-Lösungen sind flexibel, aber bei sensiblen Transaktionen schwer kontrollierbar; rein regelbasierte Bots sind kontrolliert, aber starr. Die Kombination erlaubt es, beide Welten dort einzusetzen, wo sie jeweils ihre Stärken ausspielen.
Die generativen Funktionen befinden sich zudem in laufender Weiterentwicklung. Was heute als Vorschau verfügbar ist, kann morgen erweitert oder umbenannt werden. Für Unternehmen bedeutet das: Die generativen Möglichkeiten von Dialogflow sind real und nutzbar, aber die Plattform ist in diesem Bereich noch in Bewegung. Eine Entscheidung sollte sich am tatsächlich verfügbaren Funktionsstand zum Projektzeitpunkt orientieren, nicht an Ankündigungen.
Dialogflow bringt die dafür nötigen Bausteine mit: automatische Spracherkennung, die gesprochene Sprache in Text umwandelt, und Sprachsynthese, die Antworten in natürlich klingende Stimme zurückübersetzt. Beide Komponenten stammen aus dem reifen Google-Cloud-Portfolio und gehören qualitativ zu den besseren am Markt – auch und gerade für die deutsche Sprache. Für ein Telefon-Voicebot-Projekt ist das ein gewichtiges Argument, denn die Qualität von Erkennung und Stimme entscheidet maßgeblich über die Akzeptanz bei Anrufern.
Der konzeptionelle Charme von Dialogflow ist, dass der modellierte Dialog weitgehend kanalunabhängig funktioniert. Ein Bot, der Intents, Entities und Flows kennt, kann denselben Dialog über Chat oder über Telefon abwickeln – die Sprachschicht wird vorgeschaltet. In der Praxis erfordert ein guter Voicebot dennoch eigene Aufmerksamkeit: Gesprochene Sprache ist unsauberer als getippter Text, Anrufer unterbrechen, sprechen undeutlich oder im Dialekt, und ein Telefondialog verträgt keine langen Aufzählungen. Ein guter Voicebot ist deshalb kein einfach „vorgelesener Chatbot“, sondern muss für das Medium Stimme gestaltet werden.
Typische Einsatzfälle sind die Anrufannahme außerhalb der Geschäftszeiten, die Vorqualifizierung und Weiterleitung von Anrufen, einfache Statusabfragen oder Terminvereinbarungen. Gerade für Unternehmen mit hohem Anrufvolumen und vielen gleichartigen Anliegen kann ein Voicebot spürbar entlasten – vorausgesetzt, die Erwartung ist realistisch und komplexe Fälle werden sauber an Menschen übergeben.
Dialogflow ist Teil eines größeren Google-Cloud-Angebots für Kundenservice, das unter dem Begriff Contact Center AI (CCAI) zusammengefasst wird. Dazu gehören neben dem Virtual Agent – also dem auf Dialogflow basierenden Bot – auch Bausteine, die menschliche Agenten unterstützen, etwa Live-Vorschläge während eines Gesprächs oder die automatische Auswertung von Gesprächsinhalten. Für größere Service-Organisationen ist diese Einbettung relevant, weil sie Automatisierung und menschliche Bearbeitung zu einem Gesamtkonzept verbindet.
Für den Mittelstand ist CCAI zunächst nur insofern wichtig, als es zeigt, dass Dialogflow kein isoliertes Werkzeug ist, sondern in eine Contact-Center-Strategie eingebettet werden kann. Ein typisches mittelständisches Projekt beginnt meist mit einem klar umrissenen Bot und nutzt die weiteren CCAI-Bausteine erst, wenn die Service-Automatisierung organisatorisch verankert ist. Wer von Anfang an das gesamte CCAI-Paket einführen will, sollte den damit verbundenen Komplexitäts- und Kostensprung kennen.
Klassisches Dialogflow steht für strukturierte, kontrollierte Dialoge: Jeder Schritt ist definiert, jede Antwort vorhersehbar. Moderne LLM-Agenten stehen für das Gegenteil – Flexibilität, Sprachverständnis und Antwortqualität ohne aufwendige Vormodellierung, dafür mit weniger direkter Kontrolle über das Verhalten. Beide Ansätze haben ihre Berechtigung, und die Kunst liegt darin, das richtige Werkzeug für das jeweilige Problem zu wählen.
Bemerkenswert ist, dass der Wandel sich in Googles eigenem Portfolio widerspiegelt. Neben Dialogflow hat Google mit dem Vertex AI Agent Builder eine modernere Umgebung geschaffen, in der KI-Agenten stärker um Sprachmodelle herum gebaut werden. Die Grenzen zwischen Dialogflow CX, den Conversational Agents und dem Agent Builder verschwimmen zunehmend – sie sind Teil derselben strategischen Richtung. Für Unternehmen bedeutet das vor allem, dass die Produktbezeichnungen in diesem Feld weniger stabil sind als anderswo und sich Namen und Zuschnitte verschieben können.
Die praktisch wichtige Botschaft lautet daher: Man sollte nicht „eine Plattform für die Ewigkeit“ auswählen, sondern eine Architektur, die zum konkreten Anwendungsfall passt und die nicht von einer einzelnen Produktbezeichnung abhängt. Ein gut definierter Dialog, saubere Schnittstellen und klare Prozesse sind langlebiger als das jeweilige Produkt-Label.
Dialogflow ist heute besonders dort stark, wo Kontrolle, Telefonie und transaktionale Sicherheit zählen. Ein Voicebot, der verbindlich Termine bucht, ein Service-Bot, der streng kontrolliert Statusabfragen abwickelt, eine Lösung mit hohen Anforderungen an Nachvollziehbarkeit – das sind Felder, in denen die strukturierte Natur von Dialogflow ein echter Vorteil ist. Auch die tiefe Einbettung in die Google-Cloud-Infrastruktur spricht für Unternehmen, die ohnehin auf Google Cloud setzen.
Umgekehrt kann ein reiner LLM-Agent die bessere Wahl sein, wenn es um offene Wissensvermittlung, Beratungsgespräche oder schnell wechselnde Inhalte geht und wenn die volle Kontrolle über jede Antwort weniger kritisch ist. INAGRO empfiehlt deshalb, vor der Werkzeugwahl immer den Anwendungsfall zu schärfen: Geht es um kontrollierte Transaktionen oder um flexible Konversation? Aus dieser Antwort ergibt sich die Architektur fast von selbst – und nicht selten ist es eine Kombination aus beidem.
Eine der wichtigsten Integrationen ist die nahtlose Übergabe an einen menschlichen Mitarbeiter, wenn der Bot an seine Grenzen stößt. Diese Eskalation – in der Fachsprache oft „Human Handoff“ genannt – kann an ein Service-Postfach, ein Ticketsystem oder eine Live-Chat-Lösung erfolgen. Ein gut gebauter Bot erkennt früh, wann er nicht weiterkommt, und übergibt das Gespräch inklusive bisherigem Verlauf, sodass der Kunde nicht alles wiederholen muss. INAGRO betrachtet eine durchdachte Eskalation als Pflichtbestandteil jedes ernsthaften Bot-Projekts.
So flexibel die Anbindungsmöglichkeiten sind – die Integration ist auch der Teil eines Projekts, der den größten Aufwand verursacht und das größte Risiko trägt. Sie steht und fällt mit der Qualität der Schnittstellen der angebundenen Systeme. Ist die Auftragsverwaltung über eine saubere, dokumentierte Schnittstelle erreichbar, ist die Anbindung überschaubar. Existiert keine geeignete Schnittstelle, wird aus einem Bot-Projekt schnell ein Integrationsprojekt mit eigenem Umfang. Diese Einschätzung gehört in jede seriöse Aufwandsschätzung – und sie ist häufig der Grund, warum Bot-Projekte teurer werden als zunächst erwartet.
Wir nennen hier bewusst keine festen Eurobeträge, denn die Preise hängen von Edition, Kanal, Nutzungsvolumen und den Konditionen des jeweiligen Google-Cloud-Vertrags ab und ändern sich über die Zeit. Verlässliche Zahlen liefert nur die offizielle, tagesaktuelle Preisliste von Google Cloud in Kombination mit einer auf das eigene Volumen gerechneten Schätzung. Was wir jedoch belastbar einordnen können, sind die Kostentreiber und die typischen Denkfehler bei der Kalkulation.
Drei Faktoren bestimmen die laufenden Plattformkosten besonders stark. Erstens das Interaktionsvolumen – je mehr Gespräche, desto höher die nutzungsbasierten Gebühren. Zweitens der Kanal: Telefon-Voicebots sind durch die zusätzliche Sprachverarbeitung deutlich teurer als reine Text-Bots. Drittens der Anteil generativer Funktionen, der eigene, verbrauchsabhängige Kosten verursacht. Diese drei Hebel sollten in jeder Kalkulation explizit auftauchen.
Aus der Beratungspraxis von INAGRO ist der häufigste Kalkulationsfehler, ausschließlich die laufenden Google-Cloud-Gebühren zu betrachten. In Wahrheit ist der dominierende Kostenblock fast immer die Projekt- und Betriebsarbeit: das Konzept, die Dialogmodellierung, die Webhook-Entwicklung, die Integration in Backend und CRM, das Testen und – nicht zu vergessen – die laufende Pflege. Ein Bot ist kein einmaliges Produkt, sondern ein lebendes System, das mit neuen Fragen, geänderten Prozessen und neuen Produkten mitwachsen muss. Wer diese Pflege nicht einplant, erlebt, wie die Qualität des Bots über die Monate verfällt.
Wirtschaftlich attraktiv wird Dialogflow vor allem dort, wo ein hohes Volumen gleichartiger Anfragen anfällt und wo jede automatisierte Interaktion echte Bearbeitungszeit ersetzt. Ein Bot, der täglich hunderte Standardanfragen löst, amortisiert seine Entwicklungskosten oft schnell. Ein Bot für ein Nischenanliegen mit wenigen Anfragen pro Woche rechnet sich dagegen kaum. Die ehrliche Vorab-Analyse des Anfragevolumens ist deshalb der erste Schritt jeder seriösen Wirtschaftlichkeitsbetrachtung – und sie ist wichtiger als jeder Preisvergleich der Plattformgebühren.
Ein eigener Aufmerksamkeitspunkt sind Gesprächsprotokolle. Bots zeichnen Interaktionen auf, was für Verbesserung und Qualitätssicherung wertvoll ist, datenschutzrechtlich aber heikel sein kann – besonders bei Voicebots, wo Stimmaufnahmen entstehen. Hier sind klare Regeln zu Speicherung, Anonymisierung und Löschung erforderlich. Bei generativen Funktionen kommt hinzu, dass übermittelte Inhalte an Sprachmodelle weitergegeben werden; auch hier ist zu prüfen, welche Daten in welche Verarbeitung fließen und wie eine Nutzung zu Trainingszwecken vertraglich ausgeschlossen ist.
Für besonders sensible Bereiche – etwa Gesundheitsdaten, Finanzdaten oder Berufsgeheimnisträger – empfiehlt INAGRO eine besonders vorsichtige Gestaltung: möglichst keine sensiblen Daten im offenen Dialog erheben, frühzeitige Übergabe an Menschen bei kritischen Anliegen und eine enge Abstimmung mit dem Datenschutzbeauftragten. In manchen Konstellationen kann auch eine europäische Alternative oder ein stärker abgeschotteter Betrieb sinnvoll sein.
Eine erfolgreiche Bot-Einführung im Mittelstand folgt einem strukturierten Muster. Wichtig ist, nicht mit der Technik, sondern mit dem Anwendungsfall und den Prozessen zu beginnen.
