Indice
Perché la maggior parte delle implementazioni di IA fallisce nelle piccole concessionarie
Settimana 0: scegliere una perdita concreta
Settimana 1: documentare il flusso attuale così come avviene
Settimana 2: preparare dati, permessi e limiti
Settimane 3 e 4: lanciare con un perimetro ridotto
Il cruscotto del pilota: quattro metriche
Quando ampliare e quando fermarsi
Il documento di scopo di una pagina
La ripartizione delle responsabilità prima di configurare qualsiasi cosa
Il piano di test prima di aprire al pubblico
La prima riunione di revisione
Oltre 750 autosaloni usano già Dealcar per la loro operatività quotidiana
Domande frequenti
Perché la maggior parte delle implementazioni di IA fallisce nelle piccole concessionarie
Le implementazioni di IA che non generano un ritorno nei primi 60 giorni hanno solitamente la stessa diagnosi: il progetto è iniziato con un obiettivo vago, senza un flusso di lavoro documentato, senza dati preparati e senza un responsabile che verifichi i risultati settimana dopo settimana.
"Automatizzare le vendite", "usare l'IA per lo stock" o "migliorare il marketing con l'IA" non sono punti di partenza operativi: sono aspirazioni che non dicono nulla su quale processo specifico debba essere modificato, di quali dati il sistema abbia bisogno per funzionare e come sapere se sta funzionando.
Il metodo che funziona per i rivenditori indipendenti è l'opposto: iniziare da una perdita concreta e osservabile, progettare il più piccolo pilota possibile che permetta di misurare tale perdita, lanciarlo con limiti chiari e rivederlo ogni settimana prima di espanderlo. Questo processo richiede quattro settimane di preparazione, non quattro mesi.
Vedi anche quanto costa implementare l'IA in una concessionaria.
Settimana 0: scegliere una perdita concreta
Il punto di partenza è una frase osservabile che descrive qualcosa che sta accadendo nell'attività e che ha un costo reale. Questa frase definisce il problema che il pilota di IA deve risolvere.
Consulta i 25 casi d'uso dell'IA per concessionarie per identificare quale risolve la tua perdita specifica.
Alcuni esempi di punti di partenza validi: "rimangono tra i 30 e i 50 lead senza risposta ogni fine settimana perché nessuno risponde fuori orario", "impieghiamo tra i 2 e i 3 giorni per pubblicare ogni nuova auto perché l'editing delle foto e la descrizione sono manuali", "non rivediamo i prezzi delle auto finché non rimangono invendute per 90 giorni perché nessuno ha il tempo di farlo ogni settimana".
Ognuna di queste frasi porta a un tipo di strumento diverso, a un flusso di lavoro diverso e a una metrica di successo diversa. La prima porta alla gestione automatica dei lead fuori orario. La seconda porta all'editing delle foto con IA e alla generazione di descrizioni. La terza porta ad avvisi sui prezzi e alla rotazione dello stock.
Ciò che va evitato sono gli obiettivi vaghi che non dicono nulla sul processo specifico né su come misurare il risultato:
Pessimo punto di partenza | Buon punto di partenza |
|---|---|
Automatizzare le vendite | Rispondere ai lead web in meno di 2 minuti fuori orario |
Usare l'IA per lo stock | Rivedere ogni lunedì le auto con più di 45 giorni senza lead |
Migliorare il marketing | Pubblicare ogni nuovo inserimento con foto editate e testo il giorno stesso dell'arrivo |
Con il problema specifico definito, il passo successivo è capire esattamente come avviene quel processo oggi.
Settimana 1: documentare il flusso attuale così come avviene
Prima di configurare qualsiasi strumento, è necessario documentare il flusso di lavoro attuale per il processo che si intende automatizzare. Non il flusso ideale, ma quello che avviene realmente.
Il modo più rapido è raccogliere dieci esempi reali del processo: dieci lead arrivati fuori orario, dieci auto inserite nell'ultimo mese, dieci auto in stock da più di 45 giorni. Per ogni esempio, si documenta l'intero percorso: cosa entra (il lead, l'auto, il prezzo), quali dati vengono consultati, quale decisione viene presa e da chi, quale azione ne consegue e quanto tempo ha richiesto.
Questo esercizio rivela tre elementi che altrimenti non sarebbero visibili. Il primo riguarda i dati di cui il processo ha bisogno e dove si trovano: se la gestione dei lead richiede di sapere quali auto sono disponibili, bisogna sapere se questo dato si trova nel CRM, nel DMS o in un foglio Excel. Il secondo sono le eccezioni che non seguono il flusso standard: un lead di un cliente che ha già acquistato in passato, un'auto prenotata che risulta ancora disponibile, un prezzo che è oggetto di trattativa attiva. Il terzo è chi sia il reale proprietario del processo: la persona che prende la decisione finale quando qualcosa non è chiaro.
Senza questa documentazione, il pilota di IA si scontrerà con situazioni impreviste nei primi giorni e non ci sarà modo di risolverle in modo sistematico.
Settimana 2: preparare dati, permessi e limiti
Il secondo errore più comune nelle implementazioni di IA è non definire cosa il sistema può fare prima di lanciarlo. Un sistema senza limiti chiari genera risposte che il team deve correggere, creando diffidenza e abbandono.
La preparazione dei dati e dei permessi richiede cinque decisioni da prendere prima di configurare qualsiasi cosa.
I dati di lettura definiscono cosa il sistema può consultare: lo stock disponibile, la cronologia del cliente, l'agenda degli appuntamenti. Ogni dato che il sistema può leggere deve essere aggiornato e strutturato.
Le azioni di scrittura definiscono cosa il sistema può fare: creare un appuntamento, aggiungere una nota nel CRM, creare un compito per il venditore. Ogni azione di scrittura deve essere definita con precisione: in quale sistema viene creata, con quali campi e a quali condizioni.
I dati vietati sono quelli di cui il sistema non ha bisogno per il caso d'uso e che non dovrebbe consultare: informazioni finanziarie personali, dati sanitari, documentazione legale. Definirli esplicitamente impedisce al sistema di accedere a dati sensibili per errore.
La conservazione definisce per quanto tempo vengono salvate le conversazioni e le registrazioni: 30 giorni, 90 giorni o il tempo minimo richiesto dalla normativa sulla privacy (GDPR) per il tipo di dati in questione.
Il responsabile è la persona che esamina gli errori e aggiorna le regole quando il sistema sbaglia. Senza un responsabile designato, gli errori rimangono irrisolti e il sistema si deteriora.
Il collegamento con il CRM o il DMS non è una questione di sì o no: si tratta di capire quali campi vengono letti, con quale frequenza e in quale direzione. Un sistema che legge lo stock una volta al giorno può funzionare per generare un report mattutino, ma non per rispondere in tempo reale se un'auto è ancora disponibile.
Leggi anche IA integrata nel DMS vs strumenti indipendenti.
Settimane 3 e 4: lanciare con un perimetro ridotto
Il pilota deve essere il più piccolo possibile per consentire di misurare il risultato. Un solo canale, una sola sede o una sola fascia oraria. Non tutta l'attività contemporaneamente.
Per la gestione dei lead fuori orario, il perimetro può essere limitato ai soli lead che arrivano tra le 20:00 e le 9:00 nei fine settimana. Per la pubblicazione automatica delle auto, può riguardare solo le auto di un determinato tipo di carrozzeria o fascia di prezzo. Per gli avvisi sui prezzi, può interessare solo le auto in stock da oltre 45 giorni.
Vedi anche cosa sono gli agenti di IA per le concessionarie e cosa possono fare.
Questo perimetro ridotto offre tre vantaggi. Il primo è che limita l'impatto degli errori: se il sistema sbaglia, interessa solo una parte dell'attività. Il secondo è che genera dati di qualità sufficiente per prendere decisioni in quattro settimane, senza dover attendere mesi. Il terzo è che mantiene il team coinvolto: se il pilota è troppo grande, nessuno riesce a monitorarlo con attenzione.
Durante le prime due settimane del pilota, è fondamentale mantenere una via d'uscita umana visibile e accessibile. L'acquirente che preferisce parlare con una persona deve poterlo fare senza attriti. Il venditore deve poter assumere il controllo del sistema quando rileva una situazione che l'IA non gestisce bene, senza dover aprire un ticket tecnico.
La revisione quotidiana delle prime conversazioni o azioni del sistema è obbligatoria durante le prime due settimane. Non come un audit esaustivo, ma come un controllo rapido di 10 o 15 minuti per rilevare se ci sono pattern di errore da correggere prima che si accumulino.
Il cruscotto del pilota: quattro metriche
Il pilota deve disporre di un cruscotto con quattro metriche definite prima del lancio, non dopo. Queste metriche determinano se il pilota è un successo o un fallimento.
Il tempo per la prima azione misura la velocità reale del sistema. Per un pilota di gestione dei lead, è il tempo che intercorre tra l'arrivo del lead e la risposta del sistema. Viene monitorato quotidianamente durante le prime due settimane.
La percentuale di casi risolti misura quante conversazioni o attività il sistema completa senza intervento umano. Un sistema che risolve il 70% dei casi in modo autonomo e trasferisce il 30% a una persona è un sistema che funziona. Viene verificato settimanalmente.
Le correzioni umane misurano quante volte il team deve intervenire per correggere una risposta o un'azione del sistema. Questa metrica rivela la qualità e i rischi del pilota. Se le correzioni sono costanti nello stesso tipo di situazione, c'è una regola mal definita che va corretta. Viene verificato settimanalmente.
L'impatto sul business è la metrica che giustifica l'investimento: appuntamenti aggiuntivi generati, auto inserite in meno tempo, giorni di stock ridotti. Si misura alla fine del pilota, non settimana per settimana, perché l'effetto può richiedere tempo per materializzarsi.
Leggi anche i KPI finanziari che una concessionaria deve misurare.
Quando ampliare e quando fermarsi
La decisione di estendere il pilota al resto dell'attività si prende quando si verificano contemporaneamente tre condizioni: il risultato di business è stabile per almeno due settimane, il team si fida del sistema e lo usa senza attriti, e le eccezioni rilevate durante il pilota sono documentate e coperte.
La decisione di fermarsi si prende quando si verifica una delle seguenti situazioni: non è possibile determinare quale dato abbia originato una specifica risposta del sistema (mancanza di tracciabilità), la quantità di revisione manuale necessaria per correggere gli errori supera il risparmio di tempo generato dal sistema, oppure il team evita sistematicamente di usare il sistema.
Se il team evita il sistema, il problema raramente è tecnologico. Di solito è legato alla fiducia (il sistema sbaglia con una frequenza tale che il team preferisce fare il lavoro manualmente), alla ripartizione del lavoro (il sistema genera lavoro aggiuntivo per il team senza eliminare quello precedente) o al processo (il flusso di lavoro non è sufficientemente definito affinché il sistema possa agire in autonomia).
Vedi anche come organizzare il team commerciale di una concessionaria.
Il documento di scopo di una pagina
Prima di contattare qualsiasi fornitore e prima di configurare qualsiasi strumento, è necessario redigere una scheda di una pagina che definisca lo scopo del pilota. Questa scheda contiene sette campi.
Il problema: la frase specifica che descrive la perdita che il pilota deve risolvere. Gli utenti: chi interagisce con il sistema (acquirenti, venditori, il team acquisti). Gli input: cosa attiva il sistema (un messaggio su WhatsApp, una nuova auto nel DMS, un'auto che supera i 45 giorni). Le azioni consentite: cosa può fare il sistema in autonomia (rispondere sulla disponibilità, creare un appuntamento, generare una descrizione). Le esclusioni esplicite: cosa il sistema non può mai fare senza approvazione umana (negoziare sconti, impegnarsi sui prezzi, rispondere a reclami). Il responsabile: chi esamina i risultati e aggiorna le regole. E la metrica di successo: il numero concreto che definisce se il pilota ha funzionato.
Un esempio completo: "Rispondere ai lead web di veicoli disponibili tra le 20:00 e le 9:00 nei fine settimana, raccogliere il budget e il profilo dell'acquirente e offrire un appuntamento per la settimana successiva. Non negoziare sconti né rispondere a reclami. Responsabile: direzione commerciale. Successo: 15 appuntamenti aggiuntivi al mese attribuibili ai lead fuori orario."
Questa scheda serve a tre scopi: impedisce che il pilota si allarghi in modo incontrollato durante l'implementazione, consente di confrontare le proposte di diversi fornitori sullo stesso obiettivo e fornisce al team un riferimento chiaro su cosa ci si aspetta dal sistema.
La ripartizione delle responsabilità prima di configurare qualsiasi cosa
Ogni pilota di IA necessita di quattro ruoli con responsabilità distinte che devono essere assegnati prima di iniziare la configurazione.
La divisione Business definisce quale risultato si cerca e fornisce gli esempi corretti e scorretti che il sistema deve imparare a gestire. La divisione Operations definisce come il sistema si inserisce nella quotidianità del team, chi riceve i lead che il sistema non può risolvere e come viene gestito il passaggio da sistema a persona. La divisione Tecnologia o il fornitore si occupa del collegamento con il CRM o il DMS, dei log e del supporto tecnico. Il team utente è colui che rileva nel quotidiano cosa funziona e cosa fallisce, e deve disporre di un canale diretto per segnalarlo in modo semplice.
Senza questi quattro ruoli attivi, i problemi del pilota rimarranno senza un responsabile e senza risoluzione.
Il piano di test prima di aprire al pubblico
Prima di attivare il sistema per i clienti reali, è necessario eseguire un piano di test che copra sia i casi standard che i casi limite.
I casi standard sono quelli che il sistema deve risolvere autonomamente: richieste di disponibilità con il modello esatto presente in stock, domande sul prezzo delle auto in stock, richieste di appuntamento negli orari disponibili.
I casi limite sono quelli che il sistema deve rilevare come eccezioni e trasferire a una persona: un'auto venduta durante la conversazione e che il sistema non sa ancora non essere più disponibile, un cliente che ha già una trattativa attiva con un altro venditore, una richiesta di sconto al di fuori della politica definita, un acquirente che cambia lingua a metà conversazione.
Ogni test deve avere un risultato atteso documentato. "La conversazione sembrava buona" non è un criterio valido: occorre verificare che l'appuntamento, la nota o l'attività siano stati creati una sola volta e nel punto corretto del CRM, e che le informazioni dell'acquirente siano corrette e complete.
La prima riunione di revisione
Dopo sette giorni dal lancio del pilota, è necessario tenere la prima riunione di revisione con il proprietario del processo, il responsabile tecnico e almeno un membro del team utente.
Il materiale per la riunione è costituito da venti casi che il sistema ha risolto correttamente e venti casi in cui ha sbagliato o è stato necessario l'intervento umano. I casi problematici vengono raggruppati per tipo di errore: conoscenza (il sistema non aveva il dato corretto), integrazione (il dato esisteva ma il sistema non lo ha consultato bene), istruzione (la regola definita era errata o incompleta), esperienza (il flusso non è stato fluido per l'utente, anche se il risultato era corretto) o processo umano (il sistema ha agito bene ma il processo successivo è fallito).
La correzione va apportata al livello corretto: se l'errore è di istruzione, bisogna modificare le regole del sistema, non gli esempi. Se l'errore è di integrazione, bisogna correggere il collegamento con il CRM, non il prompt. Correggere ogni singola frase problematica in modo isolato senza identificare la causa alla radice genera solo patch temporanee che non risolvono il problema.
Oltre 750 autosaloni usano già Dealcar per gestire la loro operatività quotidiana
Dealcar ha integrato funzionalità di IA per la generazione di descrizioni delle schede dei veicoli e il miglioramento automatico delle foto direttamente dalla scheda dell'auto. Queste funzionalità partono dai dati già esistenti nella piattaforma, senza bisogno di configurazioni aggiuntive. Per i casi d'uso più complessi (gestione dei lead fuori orario, agenti per gli acquisti e marketing), Dealcar è in fase di sviluppo attivo di queste funzionalità.
Se vuoi vedere come funziona ciò che è già disponibile oggi, richiedi una demo su dealcar.io partendo da un'auto reale del tuo stock e da un lead reale del tuo processo attuale o visita la pagina del software di gestione per concessionarie di Dealcar.
Domande frequenti
Quanto tempo occorre per implementare un primo pilota di IA in una concessionaria?
Con il metodo descritto, quattro settimane di preparazione e due settimane di pilota sono sufficienti per avere dati reali sull'effettivo ritorno del caso d'uso scelto. Al di sotto delle sei settimane, i dati sono insufficienti per prendere decisioni di ampliamento con fiducia. Se si superano i tre mesi per il primo pilota, il progetto tende a perdere slancio.
Cosa succede se il team non adotta il sistema?
La resistenza del team raramente è di natura tecnologica. Di solito ha tre cause: il sistema sbaglia con una frequenza tale che il team non si fida, il sistema genera lavoro aggiuntivo senza eliminare quello precedente, oppure il flusso non è abbastanza definito affinché l'IA possa agire in autonomia. Tutte e tre le cause hanno una soluzione, ma nessuna si risolve unicamente con una maggiore formazione.
È necessario un team tecnico interno per implementare l'IA in una piccola concessionaria?
No per i casi d'uso più comuni (gestione dei lead, descrizioni automatiche, miglioramento delle foto). Gli strumenti progettati per il settore, come quelli di Dealcar, includono già le integrazioni necessarie con lo stock e il CRM senza bisogno di sviluppo personalizzato. Per casi d'uso più complessi o integrazioni con sistemi proprietari, potrebbe essere necessario il supporto di un fornitore tecnico.
Indice
Perché la maggior parte delle implementazioni di IA fallisce nelle piccole concessionarie
Settimana 0: scegliere una perdita concreta
Settimana 1: documentare il flusso attuale così come avviene
Settimana 2: preparare dati, permessi e limiti
Settimane 3 e 4: lanciare con un perimetro ridotto
Il cruscotto del pilota: quattro metriche
Quando ampliare e quando fermarsi
Il documento di scopo di una pagina
La ripartizione delle responsabilità prima di configurare qualsiasi cosa
Il piano di test prima di aprire al pubblico
La prima riunione di revisione
Oltre 750 autosaloni usano già Dealcar per la loro operatività quotidiana
Domande frequenti
Perché la maggior parte delle implementazioni di IA fallisce nelle piccole concessionarie
Le implementazioni di IA che non generano un ritorno nei primi 60 giorni hanno solitamente la stessa diagnosi: il progetto è iniziato con un obiettivo vago, senza un flusso di lavoro documentato, senza dati preparati e senza un responsabile che verifichi i risultati settimana dopo settimana.
"Automatizzare le vendite", "usare l'IA per lo stock" o "migliorare il marketing con l'IA" non sono punti di partenza operativi: sono aspirazioni che non dicono nulla su quale processo specifico debba essere modificato, di quali dati il sistema abbia bisogno per funzionare e come sapere se sta funzionando.
Il metodo che funziona per i rivenditori indipendenti è l'opposto: iniziare da una perdita concreta e osservabile, progettare il più piccolo pilota possibile che permetta di misurare tale perdita, lanciarlo con limiti chiari e rivederlo ogni settimana prima di espanderlo. Questo processo richiede quattro settimane di preparazione, non quattro mesi.
Vedi anche quanto costa implementare l'IA in una concessionaria.
Settimana 0: scegliere una perdita concreta
Il punto di partenza è una frase osservabile che descrive qualcosa che sta accadendo nell'attività e che ha un costo reale. Questa frase definisce il problema che il pilota di IA deve risolvere.
Consulta i 25 casi d'uso dell'IA per concessionarie per identificare quale risolve la tua perdita specifica.
Alcuni esempi di punti di partenza validi: "rimangono tra i 30 e i 50 lead senza risposta ogni fine settimana perché nessuno risponde fuori orario", "impieghiamo tra i 2 e i 3 giorni per pubblicare ogni nuova auto perché l'editing delle foto e la descrizione sono manuali", "non rivediamo i prezzi delle auto finché non rimangono invendute per 90 giorni perché nessuno ha il tempo di farlo ogni settimana".
Ognuna di queste frasi porta a un tipo di strumento diverso, a un flusso di lavoro diverso e a una metrica di successo diversa. La prima porta alla gestione automatica dei lead fuori orario. La seconda porta all'editing delle foto con IA e alla generazione di descrizioni. La terza porta ad avvisi sui prezzi e alla rotazione dello stock.
Ciò che va evitato sono gli obiettivi vaghi che non dicono nulla sul processo specifico né su come misurare il risultato:
Pessimo punto di partenza | Buon punto di partenza |
|---|---|
Automatizzare le vendite | Rispondere ai lead web in meno di 2 minuti fuori orario |
Usare l'IA per lo stock | Rivedere ogni lunedì le auto con più di 45 giorni senza lead |
Migliorare il marketing | Pubblicare ogni nuovo inserimento con foto editate e testo il giorno stesso dell'arrivo |
Con il problema specifico definito, il passo successivo è capire esattamente come avviene quel processo oggi.
Settimana 1: documentare il flusso attuale così come avviene
Prima di configurare qualsiasi strumento, è necessario documentare il flusso di lavoro attuale per il processo che si intende automatizzare. Non il flusso ideale, ma quello che avviene realmente.
Il modo più rapido è raccogliere dieci esempi reali del processo: dieci lead arrivati fuori orario, dieci auto inserite nell'ultimo mese, dieci auto in stock da più di 45 giorni. Per ogni esempio, si documenta l'intero percorso: cosa entra (il lead, l'auto, il prezzo), quali dati vengono consultati, quale decisione viene presa e da chi, quale azione ne consegue e quanto tempo ha richiesto.
Questo esercizio rivela tre elementi che altrimenti non sarebbero visibili. Il primo riguarda i dati di cui il processo ha bisogno e dove si trovano: se la gestione dei lead richiede di sapere quali auto sono disponibili, bisogna sapere se questo dato si trova nel CRM, nel DMS o in un foglio Excel. Il secondo sono le eccezioni che non seguono il flusso standard: un lead di un cliente che ha già acquistato in passato, un'auto prenotata che risulta ancora disponibile, un prezzo che è oggetto di trattativa attiva. Il terzo è chi sia il reale proprietario del processo: la persona che prende la decisione finale quando qualcosa non è chiaro.
Senza questa documentazione, il pilota di IA si scontrerà con situazioni impreviste nei primi giorni e non ci sarà modo di risolverle in modo sistematico.
Settimana 2: preparare dati, permessi e limiti
Il secondo errore più comune nelle implementazioni di IA è non definire cosa il sistema può fare prima di lanciarlo. Un sistema senza limiti chiari genera risposte che il team deve correggere, creando diffidenza e abbandono.
La preparazione dei dati e dei permessi richiede cinque decisioni da prendere prima di configurare qualsiasi cosa.
I dati di lettura definiscono cosa il sistema può consultare: lo stock disponibile, la cronologia del cliente, l'agenda degli appuntamenti. Ogni dato che il sistema può leggere deve essere aggiornato e strutturato.
Le azioni di scrittura definiscono cosa il sistema può fare: creare un appuntamento, aggiungere una nota nel CRM, creare un compito per il venditore. Ogni azione di scrittura deve essere definita con precisione: in quale sistema viene creata, con quali campi e a quali condizioni.
I dati vietati sono quelli di cui il sistema non ha bisogno per il caso d'uso e che non dovrebbe consultare: informazioni finanziarie personali, dati sanitari, documentazione legale. Definirli esplicitamente impedisce al sistema di accedere a dati sensibili per errore.
La conservazione definisce per quanto tempo vengono salvate le conversazioni e le registrazioni: 30 giorni, 90 giorni o il tempo minimo richiesto dalla normativa sulla privacy (GDPR) per il tipo di dati in questione.
Il responsabile è la persona che esamina gli errori e aggiorna le regole quando il sistema sbaglia. Senza un responsabile designato, gli errori rimangono irrisolti e il sistema si deteriora.
Il collegamento con il CRM o il DMS non è una questione di sì o no: si tratta di capire quali campi vengono letti, con quale frequenza e in quale direzione. Un sistema che legge lo stock una volta al giorno può funzionare per generare un report mattutino, ma non per rispondere in tempo reale se un'auto è ancora disponibile.
Leggi anche IA integrata nel DMS vs strumenti indipendenti.
Settimane 3 e 4: lanciare con un perimetro ridotto
Il pilota deve essere il più piccolo possibile per consentire di misurare il risultato. Un solo canale, una sola sede o una sola fascia oraria. Non tutta l'attività contemporaneamente.
Per la gestione dei lead fuori orario, il perimetro può essere limitato ai soli lead che arrivano tra le 20:00 e le 9:00 nei fine settimana. Per la pubblicazione automatica delle auto, può riguardare solo le auto di un determinato tipo di carrozzeria o fascia di prezzo. Per gli avvisi sui prezzi, può interessare solo le auto in stock da oltre 45 giorni.
Vedi anche cosa sono gli agenti di IA per le concessionarie e cosa possono fare.
Questo perimetro ridotto offre tre vantaggi. Il primo è che limita l'impatto degli errori: se il sistema sbaglia, interessa solo una parte dell'attività. Il secondo è che genera dati di qualità sufficiente per prendere decisioni in quattro settimane, senza dover attendere mesi. Il terzo è che mantiene il team coinvolto: se il pilota è troppo grande, nessuno riesce a monitorarlo con attenzione.
Durante le prime due settimane del pilota, è fondamentale mantenere una via d'uscita umana visibile e accessibile. L'acquirente che preferisce parlare con una persona deve poterlo fare senza attriti. Il venditore deve poter assumere il controllo del sistema quando rileva una situazione che l'IA non gestisce bene, senza dover aprire un ticket tecnico.
La revisione quotidiana delle prime conversazioni o azioni del sistema è obbligatoria durante le prime due settimane. Non come un audit esaustivo, ma come un controllo rapido di 10 o 15 minuti per rilevare se ci sono pattern di errore da correggere prima che si accumulino.
Il cruscotto del pilota: quattro metriche
Il pilota deve disporre di un cruscotto con quattro metriche definite prima del lancio, non dopo. Queste metriche determinano se il pilota è un successo o un fallimento.
Il tempo per la prima azione misura la velocità reale del sistema. Per un pilota di gestione dei lead, è il tempo che intercorre tra l'arrivo del lead e la risposta del sistema. Viene monitorato quotidianamente durante le prime due settimane.
La percentuale di casi risolti misura quante conversazioni o attività il sistema completa senza intervento umano. Un sistema che risolve il 70% dei casi in modo autonomo e trasferisce il 30% a una persona è un sistema che funziona. Viene verificato settimanalmente.
Le correzioni umane misurano quante volte il team deve intervenire per correggere una risposta o un'azione del sistema. Questa metrica rivela la qualità e i rischi del pilota. Se le correzioni sono costanti nello stesso tipo di situazione, c'è una regola mal definita che va corretta. Viene verificato settimanalmente.
L'impatto sul business è la metrica che giustifica l'investimento: appuntamenti aggiuntivi generati, auto inserite in meno tempo, giorni di stock ridotti. Si misura alla fine del pilota, non settimana per settimana, perché l'effetto può richiedere tempo per materializzarsi.
Leggi anche i KPI finanziari che una concessionaria deve misurare.
Quando ampliare e quando fermarsi
La decisione di estendere il pilota al resto dell'attività si prende quando si verificano contemporaneamente tre condizioni: il risultato di business è stabile per almeno due settimane, il team si fida del sistema e lo usa senza attriti, e le eccezioni rilevate durante il pilota sono documentate e coperte.
La decisione di fermarsi si prende quando si verifica una delle seguenti situazioni: non è possibile determinare quale dato abbia originato una specifica risposta del sistema (mancanza di tracciabilità), la quantità di revisione manuale necessaria per correggere gli errori supera il risparmio di tempo generato dal sistema, oppure il team evita sistematicamente di usare il sistema.
Se il team evita il sistema, il problema raramente è tecnologico. Di solito è legato alla fiducia (il sistema sbaglia con una frequenza tale che il team preferisce fare il lavoro manualmente), alla ripartizione del lavoro (il sistema genera lavoro aggiuntivo per il team senza eliminare quello precedente) o al processo (il flusso di lavoro non è sufficientemente definito affinché il sistema possa agire in autonomia).
Vedi anche come organizzare il team commerciale di una concessionaria.
Il documento di scopo di una pagina
Prima di contattare qualsiasi fornitore e prima di configurare qualsiasi strumento, è necessario redigere una scheda di una pagina che definisca lo scopo del pilota. Questa scheda contiene sette campi.
Il problema: la frase specifica che descrive la perdita che il pilota deve risolvere. Gli utenti: chi interagisce con il sistema (acquirenti, venditori, il team acquisti). Gli input: cosa attiva il sistema (un messaggio su WhatsApp, una nuova auto nel DMS, un'auto che supera i 45 giorni). Le azioni consentite: cosa può fare il sistema in autonomia (rispondere sulla disponibilità, creare un appuntamento, generare una descrizione). Le esclusioni esplicite: cosa il sistema non può mai fare senza approvazione umana (negoziare sconti, impegnarsi sui prezzi, rispondere a reclami). Il responsabile: chi esamina i risultati e aggiorna le regole. E la metrica di successo: il numero concreto che definisce se il pilota ha funzionato.
Un esempio completo: "Rispondere ai lead web di veicoli disponibili tra le 20:00 e le 9:00 nei fine settimana, raccogliere il budget e il profilo dell'acquirente e offrire un appuntamento per la settimana successiva. Non negoziare sconti né rispondere a reclami. Responsabile: direzione commerciale. Successo: 15 appuntamenti aggiuntivi al mese attribuibili ai lead fuori orario."
Questa scheda serve a tre scopi: impedisce che il pilota si allarghi in modo incontrollato durante l'implementazione, consente di confrontare le proposte di diversi fornitori sullo stesso obiettivo e fornisce al team un riferimento chiaro su cosa ci si aspetta dal sistema.
La ripartizione delle responsabilità prima di configurare qualsiasi cosa
Ogni pilota di IA necessita di quattro ruoli con responsabilità distinte che devono essere assegnati prima di iniziare la configurazione.
La divisione Business definisce quale risultato si cerca e fornisce gli esempi corretti e scorretti che il sistema deve imparare a gestire. La divisione Operations definisce come il sistema si inserisce nella quotidianità del team, chi riceve i lead che il sistema non può risolvere e come viene gestito il passaggio da sistema a persona. La divisione Tecnologia o il fornitore si occupa del collegamento con il CRM o il DMS, dei log e del supporto tecnico. Il team utente è colui che rileva nel quotidiano cosa funziona e cosa fallisce, e deve disporre di un canale diretto per segnalarlo in modo semplice.
Senza questi quattro ruoli attivi, i problemi del pilota rimarranno senza un responsabile e senza risoluzione.
Il piano di test prima di aprire al pubblico
Prima di attivare il sistema per i clienti reali, è necessario eseguire un piano di test che copra sia i casi standard che i casi limite.
I casi standard sono quelli che il sistema deve risolvere autonomamente: richieste di disponibilità con il modello esatto presente in stock, domande sul prezzo delle auto in stock, richieste di appuntamento negli orari disponibili.
I casi limite sono quelli che il sistema deve rilevare come eccezioni e trasferire a una persona: un'auto venduta durante la conversazione e che il sistema non sa ancora non essere più disponibile, un cliente che ha già una trattativa attiva con un altro venditore, una richiesta di sconto al di fuori della politica definita, un acquirente che cambia lingua a metà conversazione.
Ogni test deve avere un risultato atteso documentato. "La conversazione sembrava buona" non è un criterio valido: occorre verificare che l'appuntamento, la nota o l'attività siano stati creati una sola volta e nel punto corretto del CRM, e che le informazioni dell'acquirente siano corrette e complete.
La prima riunione di revisione
Dopo sette giorni dal lancio del pilota, è necessario tenere la prima riunione di revisione con il proprietario del processo, il responsabile tecnico e almeno un membro del team utente.
Il materiale per la riunione è costituito da venti casi che il sistema ha risolto correttamente e venti casi in cui ha sbagliato o è stato necessario l'intervento umano. I casi problematici vengono raggruppati per tipo di errore: conoscenza (il sistema non aveva il dato corretto), integrazione (il dato esisteva ma il sistema non lo ha consultato bene), istruzione (la regola definita era errata o incompleta), esperienza (il flusso non è stato fluido per l'utente, anche se il risultato era corretto) o processo umano (il sistema ha agito bene ma il processo successivo è fallito).
La correzione va apportata al livello corretto: se l'errore è di istruzione, bisogna modificare le regole del sistema, non gli esempi. Se l'errore è di integrazione, bisogna correggere il collegamento con il CRM, non il prompt. Correggere ogni singola frase problematica in modo isolato senza identificare la causa alla radice genera solo patch temporanee che non risolvono il problema.
Oltre 750 autosaloni usano già Dealcar per gestire la loro operatività quotidiana
Dealcar ha integrato funzionalità di IA per la generazione di descrizioni delle schede dei veicoli e il miglioramento automatico delle foto direttamente dalla scheda dell'auto. Queste funzionalità partono dai dati già esistenti nella piattaforma, senza bisogno di configurazioni aggiuntive. Per i casi d'uso più complessi (gestione dei lead fuori orario, agenti per gli acquisti e marketing), Dealcar è in fase di sviluppo attivo di queste funzionalità.
Se vuoi vedere come funziona ciò che è già disponibile oggi, richiedi una demo su dealcar.io partendo da un'auto reale del tuo stock e da un lead reale del tuo processo attuale o visita la pagina del software di gestione per concessionarie di Dealcar.
Domande frequenti
Quanto tempo occorre per implementare un primo pilota di IA in una concessionaria?
Con il metodo descritto, quattro settimane di preparazione e due settimane di pilota sono sufficienti per avere dati reali sull'effettivo ritorno del caso d'uso scelto. Al di sotto delle sei settimane, i dati sono insufficienti per prendere decisioni di ampliamento con fiducia. Se si superano i tre mesi per il primo pilota, il progetto tende a perdere slancio.
Cosa succede se il team non adotta il sistema?
La resistenza del team raramente è di natura tecnologica. Di solito ha tre cause: il sistema sbaglia con una frequenza tale che il team non si fida, il sistema genera lavoro aggiuntivo senza eliminare quello precedente, oppure il flusso non è abbastanza definito affinché l'IA possa agire in autonomia. Tutte e tre le cause hanno una soluzione, ma nessuna si risolve unicamente con una maggiore formazione.
È necessario un team tecnico interno per implementare l'IA in una piccola concessionaria?
No per i casi d'uso più comuni (gestione dei lead, descrizioni automatiche, miglioramento delle foto). Gli strumenti progettati per il settore, come quelli di Dealcar, includono già le integrazioni necessarie con lo stock e il CRM senza bisogno di sviluppo personalizzato. Per casi d'uso più complessi o integrazioni con sistemi proprietari, potrebbe essere necessario il supporto di un fornitore tecnico.
