I dati c'erano. Il percorso verso di essi no.
Una concessionaria auto porta con sé molti dati: inventario live con prezzi e disponibilità, specifiche dei veicoli legate ai VIN, valutazioni di permuta che cambiano di giorno in giorno, opzioni di finanziamento, slot di assistenza. Quei dati erano sparsi tra vAuto per l'inventario, TradePending per i preventivi di permuta, ChromeData per le specifiche dei veicoli e il CRM proprio di ciascun concessionario. Nessuno di essi veniva portato all'acquirente nel momento in cui stava decidendo.
La conversazione d'acquisto — cosa rientra nel mio budget, quanto mi date per la mia permuta, potete fare l'assistenza la prossima settimana — avveniva al telefono o nello showroom, ore o giorni dopo. I concessionari perdevano lead che non riuscivano a ottenere una risposta abbastanza in fretta.
Il brief: mettere un'interfaccia di chat sul sito di ogni concessionario capace di rispondere a quelle domande in tempo reale, collegata ai sistemi che già avevano le risposte.
Un costruttore visuale per i concessionari, un widget di chat per gli acquirenti.
La piattaforma aveva due superfici distinte. I concessionari usavano un costruttore visuale di flussi nell'amministrazione — un editor a grafo di card in cui costruivano flussi di conversazione collegando card-domanda, ramificazioni di risposta e card-azione: mostra l'inventario, recupera un preventivo di permuta, prenota un appuntamento di assistenza, cattura un lead. Nessun codice richiesto. Ogni concessionario componeva il proprio bot; la piattaforma gestiva il rendering e l'instradamento.
Gli acquirenti vedevano un widget di chat incorporabile sul sito del concessionario. Il widget faceva girare i flussi configurati, prelevava l'inventario live da vAuto, faceva emergere le valutazioni di permuta TradePending in linea quando un acquirente descriveva la propria auto attuale e catturava i dati di contatto in formato ADF per il CRM del concessionario. La conversazione si plasmava attorno a ciò che il concessionario aveva configurato e a ciò che l'acquirente chiedeva.
La piattaforma era multi-tenant fin dal primo giorno. Ogni concessionario aveva la propria configurazione del bot, il proprio grafo di flussi, la propria connessione a inventario e CRM. Un singolo account poteva gestire più concessionarie. Autenticazione, fatturazione e tenancy vivevano in MySQL; tutto il resto viveva negli store a esso adatti.
- F · 01Costruttore visuale di flussi
- I concessionari costruivano flussi di conversazione in un editor a grafo di card — domande, ramificazioni di risposta, ricerche nell'inventario, preventivi di permuta, cattura di lead. Nessun codice richiesto. Ogni concessionario configurava il proprio bot.
- F · 02Feed di inventario vAuto
- Un job di coda supportato da Redis analizzava gli export FTP di vAuto, aggiornava i dati di prodotto in MongoDB e re-indicizzava Elasticsearch per concessionario. Le modifiche al feed erano isolate a un solo job.
- F · 03Integrazione permuta TradePending
- Il widget di chat recuperava le valutazioni di permuta da TradePending in linea, facendo emergere un preventivo nella conversazione quando un acquirente descriveva il proprio veicolo attuale.
- F · 04Esportazione lead ADF
- I dati di contatto dell'acquirente catturati nella chat venivano formattati come XML ADF e instradati al CRM del concessionario. Il formato standard del settore eliminava la necessità di un'integrazione personalizzata per ogni concessionaria.
- F · 05Backend a tre database
- MongoDB per gli schemi in evoluzione di bot e inventario, MySQL per autenticazione e fatturazione multi-tenant, Elasticsearch per la ricerca di inventario per concessionario. Ogni store possedeva un solo lavoro.
- F · 06Suite di test di automazione del browser
- Laravel Dusk copriva i flussi di conversazione completi end-to-end. Le modifiche ai tipi di card e agli schemi in MongoDB non rompevano i percorsi del widget; la suite di test lo rilevava se accadeva.
Tre database, ciascuno che si guadagna il posto.
La decisione di far girare tre store in parallelo è stata deliberata e argomentata fin dal primo giorno. La tentazione in un progetto come questo è normalizzare tutto in un unico store e accettare l'attrito ai margini. Non l'abbiamo fatto.
MongoDB conteneva le configurazioni dei bot e i flussi di conversazione — tipi di card, logica di ramificazione, opzioni di risposta rapida, lo schema in evoluzione per la visualizzazione dell'inventario. Quello schema cambiava a ogni sprint man mano che il set di funzionalità cresceva. Una migrazione relazionale a ogni aggiunta di un tipo di card avrebbe strozzato la consegna. MongoDB ha assorbito quei cambiamenti senza cerimonie.
MySQL gestiva tutto ciò che aveva bisogno di integrità transazionale: autenticazione, fatturazione e confini di tenancy dei concessionari. Non avremmo lasciato la coerenza eventuale avvicinarsi al controllo degli accessi o allo stato degli abbonamenti. Elasticsearch indicizzava ogni prodotto di inventario attivo per concessionario, arricchito con i dati del feed vAuto e con le offerte e gli elementi interattivi che ciascun concessionario aveva configurato. Quando un acquirente chiedeva di un'auto specifica nella chat, il widget interrogava Elasticsearch — non una tabella relazionale. La qualità del recupero corrispondeva a ciò di cui il caso d'uso aveva bisogno.
Tre database non sono complessità — sono precisione. Un unico store che cercava di fare tutti e tre i lavori sarebbe stata la scelta complessa.
L'integrazione vAuto girava come worker di coda dedicato. vAuto pubblicava i file di inventario via FTP; un job di coda Laravel supportato da Redis li prelevava, analizzava il feed, aggiornava MongoDB con i nuovi dati di prodotto e re-indicizzava l'inventario interessato in Elasticsearch. Ogni passo era isolato. Quando vAuto cambiava il formato di un file, cambiava un job, non l'intero stack. La suite di test di automazione del browser in Laravel Dusk impediva ai flussi di conversazione completi di regredire man mano che tipi di card e schemi evolvevano. 1.736 commit in circa due anni. L'architettura ha tenuto.
Due anni in produzione; zero riscritture.
La piattaforma è stata pubblicata per i primi concessionari alla fine del 2017. Il design multi-database — che sul diagramma di architettura era sembrato complessità — ha dimostrato il proprio valore in operatività. I guasti erano contenuti nel loro livello. Un guasto di parsing del feed vAuto non influiva sulla fatturazione. Una re-indicizzazione di Elasticsearch non bloccava una conversazione d'acquisto. Ogni store si guastava nel modo in cui si guasta il suo tipo, e non oltre.
L'adozione da parte dei concessionari ha tenuto. Quando il widget pone domande invece di mostrare un modulo di contatto, gli acquirenti rispondono. Il flusso di permuta — chiedere all'acquirente della propria auto attuale, recuperare una valutazione TradePending, mostrarla in linea — girava senza richiedere alcun membro del personale del concessionario.
Il progetto si è chiuso con 708 file sorgente, una suite completa di copertura PHPUnit e Dusk e un livello dati che il team del cliente ha esteso dopo il passaggio di consegne. Nuovi tipi di card, nuovi connettori di integrazione — li hanno aggiunti senza di noi. Tre database che fanno tre lavori, e nessuno di essi che fa quello di un altro.