Die Daten waren da. Der Weg zu ihnen nicht.
Ein Autohaus trägt eine Menge Daten: Live-Inventar mit Preisen und Verfügbarkeit, an VINs gebundene Fahrzeugspezifikationen, Inzahlungnahme-Bewertungen, die sich täglich ändern, Finanzierungsoptionen, Servicetermine. Diese Daten verteilten sich auf vAuto für das Inventar, TradePending für Inzahlungnahme-Angebote, ChromeData für Fahrzeugspezifikationen und das jeweils eigene CRM jedes Händlers. Nichts davon wurde Käufern in dem Moment zugänglich gemacht, in dem sie entschieden.
Das Kaufgespräch — was passt in mein Budget, was würden Sie mir für meine Inzahlungnahme geben, können Sie es nächste Woche warten — fand telefonisch oder im Schauraum statt, Stunden oder Tage später. Händler verloren Leads, die nicht schnell genug eine Antwort bekamen.
Das Briefing: Bringt auf jede Händler-Website eine Chat-Oberfläche, die diese Fragen in Echtzeit beantworten kann, verbunden mit den Systemen, die die Antworten bereits hatten.
Ein visueller Konstruktor für Händler, ein Chat-Widget für Käufer.
Die Plattform hatte zwei unterschiedliche Oberflächen. Händler nutzten im Admin einen visuellen Flow-Konstruktor — einen Kartengraph-Editor, in dem sie Gesprächsabläufe bauten, indem sie Fragekarten, Antwortzweige und Aktionskarten verbanden: Inventar anzeigen, ein Inzahlungnahme-Angebot abrufen, einen Servicetermin buchen, einen Lead erfassen. Kein Code erforderlich. Jeder Händler komponierte seinen eigenen Bot; die Plattform übernahm Rendering und Routing.
Käufer sahen ein einbettbares Chat-Widget auf der Website des Händlers. Das Widget führte die konfigurierten Abläufe aus, zog Live-Inventar aus vAuto, blendete TradePending-Inzahlungnahme-Bewertungen inline ein, wenn ein Käufer sein aktuelles Auto beschrieb, und erfasste Kontaktdaten im ADF-Format für das CRM des Händlers. Das Gespräch formte sich um das, was der Händler konfiguriert hatte, und um das, was der Käufer fragte.
Die Plattform war vom ersten Tag an mandantenfähig. Jeder Händler erhielt seine eigene Bot-Konfiguration, seinen eigenen Flow-Graphen, seine eigene Inventar- und CRM-Anbindung. Ein Konto konnte mehrere Autohäuser verwalten. Auth, Abrechnung und Mandantenfähigkeit lebten in MySQL; alles andere lebte in den Speichern, die dazu passten.
- F · 01Visueller Flow-Konstruktor
- Händler bauten Gesprächsabläufe in einem Kartengraph-Editor — Fragen, Antwortzweige, Inventarabfragen, Inzahlungnahme-Angebote, Lead-Erfassung. Kein Code erforderlich. Jeder Händler konfigurierte seinen eigenen Bot.
- F · 02vAuto-Inventar-Feed
- Ein Redis-gestützter Queue-Job parste vAuto-FTP-Exporte, aktualisierte MongoDB-Produktdaten und reindizierte Elasticsearch pro Händler. Feed-Änderungen blieben auf einen Job isoliert.
- F · 03TradePending-Inzahlungnahme-Integration
- Das Chat-Widget rief Inzahlungnahme-Bewertungen von TradePending inline ab und blendete ein Angebot im Gespräch ein, wenn ein Käufer sein aktuelles Fahrzeug beschrieb.
- F · 04ADF-Lead-Export
- Im Chat erfasste Käufer-Kontaktdaten wurden als ADF-XML formatiert und an das CRM des Händlers geleitet. Das branchenübliche Format bedeutete keine eigene Integration pro Autohaus.
- F · 05Drei-Datenbank-Backend
- MongoDB für sich entwickelnde Bot- und Inventar-Schemata, MySQL für mandantenfähige Auth und Abrechnung, Elasticsearch für die Inventarsuche pro Händler. Jeder Speicher besaß eine Aufgabe.
- F · 06Browser-Automatisierungs-Testsuite
- Laravel Dusk deckte die vollständigen Gesprächsabläufe Ende zu Ende ab. Kartentyp- und Schemaänderungen in MongoDB brachen die Widget-Pfade nicht; die Testsuite fing es ab, wenn sie es taten.
Drei Datenbanken, jede verdient ihren Platz.
Die Entscheidung, drei Speicher parallel zu betreiben, war bewusst und wurde am ersten Tag begründet. Die Versuchung bei einem Projekt wie diesem ist, alles in einen Speicher zu normalisieren und die Reibung an den Rändern hinzunehmen. Das taten wir nicht.
MongoDB hielt die Bot-Konfigurationen und Gesprächsabläufe — Kartentypen, Verzweigungslogik, Schnellantwort-Optionen, das sich entwickelnde Inventaranzeige-Schema. Dieses Schema änderte sich in jedem Sprint, während der Funktionsumfang wuchs. Eine relationale Migration bei jeder Ergänzung eines Kartentyps hätte die Auslieferung erstickt. MongoDB nahm diese Änderungen ohne Umstände auf.
MySQL übernahm alles, was transaktionale Integrität brauchte: Authentifizierung, Abrechnung und Mandantengrenzen der Händler. Wir würden eventuelle Konsistenz nicht in die Nähe der Zugriffskontrolle oder des Abonnementstatus lassen. Elasticsearch indizierte jedes aktive Inventarprodukt pro Händler, angereichert mit vAuto-Feed-Daten und den Angeboten und Interaktiven, die jeder Händler konfiguriert hatte. Wenn ein Käufer im Chat nach einem bestimmten Auto fragte, fragte das Widget Elasticsearch ab — nicht eine relationale Tabelle. Die Qualität der Treffer entsprach dem, was der Anwendungsfall brauchte.
Drei Datenbanken sind keine Komplexität — sie sind Präzision. Ein Speicher, der versucht, alle drei Aufgaben zu erledigen, wäre die komplexe Wahl gewesen.
Die vAuto-Integration lief als dedizierter Queue-Worker. vAuto veröffentlichte Inventardateien per FTP; ein Redis-gestützter Laravel-Queue-Job nahm sie auf, parste den Feed, aktualisierte MongoDB mit den neuen Produktdaten und reindizierte das betroffene Inventar in Elasticsearch. Jeder Schritt war isoliert. Wenn vAuto ein Dateiformat änderte, änderte sich ein Job, nicht der ganze Stack. Die Browser-Automatisierungs-Testsuite in Laravel Dusk verhinderte, dass die vollständigen Gesprächsabläufe regredierten, während sich Kartentypen und Schemata entwickelten. 1.736 Commits über rund zwei Jahre. Die Architektur hielt.
Zwei Jahre in Produktion; null Neuschreibungen.
Die Plattform ging Ende 2017 an die ersten Händler. Das Multi-Datenbank-Design — das auf dem Architekturdiagramm wie Komplexität ausgesehen hatte — bewies seinen Wert im Betrieb. Ausfälle blieben auf ihre Schicht beschränkt. Ein Parse-Fehler eines vAuto-Feeds berührte die Abrechnung nicht. Eine Elasticsearch-Reindizierung blockierte kein Käufergespräch. Jeder Speicher fiel auf die Art aus, auf die sein Typ ausfällt, und nicht mehr.
Die Akzeptanz der Händler hielt. Wenn das Widget Fragen stellt, statt ein Kontaktformular anzuzeigen, antworten Käufer. Der Inzahlungnahme-Ablauf — einen Käufer nach seinem aktuellen Auto zu fragen, eine TradePending-Bewertung abzurufen, sie inline anzuzeigen — lief, ohne Händlerpersonal zu erfordern.
Das Projekt schloss mit 708 Quelldateien, einer vollständigen PHPUnit- und Dusk-Abdeckungssuite und einer Datenschicht, die das Team des Kunden nach der Übergabe selbst erweiterte. Neue Kartentypen, neue Integrationskonnektoren — sie fügten sie ohne uns hinzu. Drei Datenbanken, die drei Aufgaben erledigen, und keine davon erledigt die eines anderen.