Un CRM con IA si guadagna il posto in una vendita industriale leggendo bene la richiesta, non mandando più solleciti

In quella frase si nascondono due mestieri diversi. L'acquisto di un impianto è una decisione collegiale su un ciclo di nove-diciotto mesi; la lavorazione su disegno del cliente si decide in pochi giorni su un disegno, e lì il problema è il volume di richieste di offerta (RdO), non la lunghezza del ciclo. Gli argomenti che seguono su RdO, qualificazione e documentazione valgono per entrambi, quelli sul gruppo d'acquisto e sullo scoring solo per la vendita di impianti. In entrambi i casi ciò che l'IA fa bene è poco: rimodella testo che avete già.

Perché l'automazione di un CRM generico non regge su un ciclo di vendita B2B lungo

Il manuale standard presuppone un solo interlocutore, una valutazione breve, un mercato ampio e un numero di trattative sufficiente perché lo scoring significhi qualcosa. Nessuna di queste condizioni regge. Un investimento in impianti passa sotto gli occhi di un tecnologo di produzione che guarda il tempo ciclo, di un responsabile qualità che guarda la capacità di processo, di un capo manutenzione che guarda i ricambi, di un buyer che guarda le condizioni, e di un manager che ha in carico la voce di capex. Arrivano in momenti diversi, quindi una sequenza indirizzata "al lead" non raggiunge nessuno.

Anche il mercato è finito. L'insieme dei clienti raggiungibili è abbastanza piccolo perché gli stessi nomi tornino negli anni e tra aziende diverse, man mano che i tecnici cambiano stabilimento, ed è abbastanza piccolo perché nessun modello comportamentale abbia un set di addestramento degno di questo nome. Qui un messaggio automatico fastidioso non è un errore di arrotondamento. Viene ricordato, con nome e cognome.

Le trattative si perdono raramente per la mancanza dell'ennesimo messaggio che chiede se avete avuto modo di vedere l'offerta. Si perdono perché non c'eravate, con qualcosa di utile, quando è stato scritto il piano investimenti dell'anno successivo, perché la risposta tecnica è arrivata troppo tardi, o perché il requisito non è mai stato messo per iscritto in una forma su cui qualcuno potesse lavorare. Nessuno di questi è un problema di cadenza.

Leggere una RdO e far emergere il requisito

Le richieste di offerta arrivano nella forma che al cliente è venuta comoda: un PDF, un foglio di calcolo, una serie di disegni, tre paragrafi in una mail, un modulo d'acquisto di cui contano sei campi. Un modello estrae in modo affidabile ciò che è presente come testo — quantità e cadenza delle chiamate, date e condizioni di consegna, l'elenco delle certificazioni, le condizioni commerciali, i codici articolo citati nel corpo del messaggio — nel tempo che serve ad aprire il file.

Ciò che nasce sul disegno è una classe di dati diversa. Tolleranze geometriche, simboli di saldatura, sistema dei riferimenti, finitura superficiale, caratteristiche marcate come critiche: questi vengono letti in modo inaffidabile, e qualunque dato riportato da un disegno arriva marcato come proposta non verificata per un tecnico, mai come valore su cui fare un'offerta. Trattare le due classi allo stesso modo è la via più rapida per passare da un'estrazione utile a un errore in offerta.

Risolvete prima la questione della proprietà. I disegni del cliente sono sua proprietà intellettuale, di solito coperti da un NDA firmato molto prima che arrivasse la richiesta, e nell'aerospazio, nella difesa e in parte dell'automotive possono essere soggetti a controllo delle esportazioni sotto ITAR, EAR o il regolamento UE sul dual use. Verificate che cosa l'NDA consente in materia di trattamento e di subfornitori prima che un disegno raggiunga un modello, tenete il lavoro soggetto a controllo on-premise o su un'installazione senza conservazione e senza addestramento, e predisponete un percorso di esclusione perché clienti e famiglie di codici marcati non entrino mai nel flusso.

La metà più preziosa dell'output è ciò che manca. Le domande che rimandate indietro nella prima ora sono il segnale di competenza più forte che manderete mai, e impediscono a un tecnico di quotare su un'ipotesi che nessuno ha verificato.

Due regole separano un'estrazione utile da una che un tecnico rifà a mano. Ogni voce cita la propria fonte: foglio e cella se la fonte è un foglio di calcolo, pagina e area della pagina se è una scansione. E il modello lascia il campo vuoto invece di indovinare, che è un tasso da misurare campo per campo sul vostro insieme di prova, non un comportamento che si ottiene istruendolo ad astenersi. L'astensione fallisce dove esiste un valore di default plausibile, su una tolleranza o su una finitura standard, quindi un campo con bassa astensione ed errore alto è un campo che lasciate a una persona.

Scrivere la prima risposta tecnica senza impegnare l'azienda

La prima risposta decide se siete nella valutazione. Una buona risposta nomina l'applicazione invece di ringraziare il cliente per l'interesse, riformula il requisito così come lo avete capito, pone le due o tre domande che cambiano la risposta, e si impegna su un passo successivo con una data.

Un modello fornisce quella struttura in un minuto e una persona corregge e invia. L'invio automatico è un sistema diverso, non una diversa impostazione dello stesso, e nessuna bozza dichiara una specifica: qualsiasi numero che possa finire in un'offerta viene da qualcuno che ha l'autorità per impegnarlo.

Riassumere lo storico del cliente e tenere aggiornato il record CRM

Un'opportunità che va avanti da quattordici mesi è sparsa su un centinaio di mail, tre visite, due campionature e una prova andata male. Lo storico esiste e nessuno lo legge, quindi quando l'account manager se ne va il suo valore pratico è zero. Un modello che legge il thread e fa il briefing alla persona successiva è genuinamente utile.

È anche un riassunto con perdita, e ciò che cade è in modo sproporzionato l'impegno su una riga sepolto a metà: la tolleranza concessa, il prezzo tenuto fermo per un periodo dichiarato, la deroga concordata in una telefonata. Un briefing quasi giusto che omette in silenzio la concessione è peggio di nessun briefing. Quindi trattatelo come una porta d'ingresso al thread, collegate ogni affermazione al messaggio da cui viene, ed estraete gli impegni in un elenco separato con le citazioni.

La stessa capacità affronta il problema più vecchio dei CRM. I venditori non aggiornano i record perché aggiornarli è data entry che non restituisce nulla, e la risposta è la stessa che vale in reparto: proporre, non imporre. Dopo una telefonata l'assistente scrive la nota e propone il cambio di fase e l'azione successiva. Restano proposte, perché un assistente che modifica in silenzio valori o date di chiusura distrugge l'unica cosa che un CRM deve essere, un archivio a cui le persone credono.

Un CRM con IA sostituisce il sistema che già usate o ci sta sopra

Per lo più ci sta sopra. L'anagrafica del cliente, l'opportunità e l'ordine restano dove sono, che sia Salesforce, Dynamics, HubSpot, Odoo o il modulo CRM del vostro ERP. L'assistente legge da quel sistema, dalla casella di posta, dallo storico delle offerte e dall'archivio documentale, e ci riscrive tre cose: una nota, una proposta di modifica di un campo e un'attività con un responsabile e una data, tutte attribuibili e reversibili.

Quindi il progetto è l'integrazione, non il modello, e ciò che di solito si rompe è l'identificativo che deve sopravvivere al viaggio tra CRM, ERP e sistema documentale, perché la chiave anagrafica e il codice cliente non sono mai stati riconciliati. Se non avete un CRM, viene prima il CRM: un assistente non può tenere aggiornato un record che non esiste.

In che cosa l'IA non è brava, e dove vi costerà

Non conosce le vostre capacità: che quella tolleranza è ottenibile ma solo alla seconda operazione, che una lega grippa nel vostro processo, che il volume annuo dichiarato è parecchie volte quello che quel segmento ordina davvero. Non ha alcun senso della conseguenza commerciale, e scriverà una frase sicura sul lead time con la stessa facilità con cui ne scrive una prudente, perché entrambe sono frasi in italiano corretto. E non sa che cosa è cambiato dopo che le avete consegnato i documenti, il che rende l'aggiornamento della documentazione una responsabilità operativa e non un'attività di setup.

Qualificare i contatti rispettando un interlocutore tecnico: perché lo scoring non è qualificazione

Lo scoring assegna un numero a partire dal comportamento: pagine visitate, mail aperte, documenti scaricati. In un mercato con così pochi compratori reali questo misura soprattutto la curiosità, e il profilo che premia in modo più affidabile è il tecnico di un concorrente che legge la vostra documentazione.

La qualificazione risponde ad altre domande. Esiste un'applicazione a cui il nostro impianto si adatta, descritta in modo abbastanza concreto da poter essere verificata. C'è un budget, e in quale esercizio. Chi decide, e chi può porre il veto. E che cosa succede se non fanno nulla.

Un assistente aiuta solo se pone domande a cui un interlocutore tecnico ha voglia di rispondere. Un tecnico vi dà volentieri il particolare, il materiale, il volume e il tempo ciclo, e abbandona un modulo che pretende la fascia di fatturato e la fascia di budget. L'output più sottovalutato è il no rapido: la maggior parte del costo di una richiesta sbagliata è il lavoro di ufficio tecnico che una richiesta del genere assorbe prima che qualcuno stabilisca che non era mai adatta.

Un chatbot che risponde dalla vostra documentazione invece di inventare

Ponete a un modello linguistico una domanda su un prodotto e vi risponde a partire dal suo addestramento, in una prosa che somiglia esattamente alla vostra documentazione, senza alcun rapporto tra quanto suona sicuro e quanto è vero. In una vendita tecnica è il peggiore dei modi possibili di sbagliare, perché una risposta sbagliata viene fotografata, inoltrata e riletta ad alta voce in riunione.

È l'ancoraggio ai documenti a renderlo sopportabile. La domanda recupera passaggi dai vostri documenti, il modello risponde solo a partire da quelli e li cita, il che trasforma l'errore tipico in un "questo non l'ho trovato nella documentazione". La maggior parte del lavoro sta dal lato dei documenti: quali sono autorevoli, quali sono superati e vanno tolti dall'indice — conservati nel sistema documentale come richiede la vostra procedura qualità, ma irraggiungibili dall'assistente — e quali sono riservati.

Non elimina l'errore. Il recupero restituisce la revisione superata perché quella revisione è la corrispondenza testuale migliore; restituisce il documento giusto e il modello legge male una tabella al suo interno; non trova nulla di pertinente e risponde comunque dall'addestramento. La citazione peggiora ciascuno di questi casi, perché a una risposta sbagliata con il nome di un documento allegato si crede di più.

Quindi imponete i vincoli nel sistema e non in un documento di policy: rispondere solo da materiale pubblicato, indicare documento e revisione usati, rifiutare invece di dedurre sulle domande di specifica, non dare mai un prezzo né un lead time. E registrate ogni domanda a cui non ha saputo rispondere, perché quel registro è l'elenco, scritto dai vostri clienti, di ciò che non avevate pubblicato.

I dati che avete già, e che cosa serve per renderli utilizzabili

Più di quanto pensiate, e in condizioni peggiori di quanto pensiate. La casella di posta contiene anni di richieste di offerta e di scambi tecnici, lo storico delle offerte contiene che cosa avete proposto e a che prezzo, e le causali di perdita contengono il dataset più prezioso dell'azienda, se qualcuno le ha compilate onestamente. L'ERP contiene i vostri lead time e le date di consegna, che conviene verificare prima di fidarsene: pianificato contro consuntivo, e se la data promessa sia stata riscritta ogni volta che slittava.

Poi c'è lo stato dei dati. Lo stesso cliente esiste tre volte con grafie diverse, e la filiale tedesca è un'anagrafica separata senza alcun legame con la capogruppo, quindi nessuno vede che il gruppo ha già comprato due linee. E la causale di perdita è "prezzo" sulla maggior parte dei record, che è ciò che si seleziona quando il motivo vero era una risposta lenta.

Il lavoro è ingrato ed è la maggior parte del progetto: deduplicare le anagrafiche, modellare le strutture di gruppo, concordare un'unica posizione autorevole per la documentazione con un campo revisione esplicito, sostituire la causale di perdita a testo libero con un elenco breve che un venditore possa scegliere dicendo la verità. Un modello costruito su questi dati eredita ogni errore e lo consegna con sicurezza.

Il passaggio a una persona, e perché un passaggio fatto male distrugge il valore

Il momento in cui l'assistente si ferma e comincia una persona è dove il cliente giudica l'intero sistema. Un cliente spiega la sua applicazione nel dettaglio, un venditore chiama due giorni dopo e rifà le stesse domande dall'inizio, e tutto quello che l'automazione aveva guadagnato si brucia in quel minuto.

Un passaggio che funziona porta con sé la conversazione agganciata all'opportunità, la domanda che ha causato l'escalation, un responsabile con nome e cognome invece di una casella condivisa, e un tempo di risposta di cui qualcuno risponde. Siate onesti su che cosa sia l'assistente, perché un interlocutore tecnico lo capisce in pochi scambi, e fate scattare l'escalation automaticamente su qualsiasi impegno di specifica, qualsiasi prezzo, qualsiasi reclamo, e ogni volta che un cliente chiede due volte.

Misurarlo onestamente: tempo di risposta e pipeline qualificata, non messaggi inviati

Quasi tutta la reportistica su questi sistemi misura la loro stessa attività: messaggi inviati, conversazioni gestite, ore risparmiate con un moltiplicatore fornito dal venditore. Tutti questi numeri salgono che sia migliorato qualcosa o no. Partite invece dal tempo che passa dalla richiesta alla prima risposta tecnica di sostanza, dove di sostanza significa che entra nel merito dell'applicazione invece di limitarsi a confermare la ricezione. Poi il tempo dalla RdO all'offerta sulle richieste che avete accettato come in perimetro, e la quota di queste che è arrivata a offerta, che fa emergere quelle che muoiono nella coda di un tecnico.

Misurate le richieste rifiutate su un asse separato, quanti giorni ci sono voluti per rifiutarle, perché è quello il numero che il no rapido esiste per abbassare. Un unico tasso di offerta calcolato sui due denominatori insieme dice all'organizzazione di quotare proprio le richieste che le avete appena detto di rifiutare. Poi la pipeline qualificata contro una definizione di qualificato scritta prima del progetto, e il conteggio delle domande a cui l'assistente non ha saputo rispondere, che deve scendere man mano che pubblicate ciò che mancava.

Il GDPR e che cosa si aspetta un cliente industriale europeo

La base giuridica per il contatto commerciale B2B non è uniforme in Europa. Le attuazioni nazionali delle regole ePrivacy differiscono, e in alcuni Stati membri la mail commerciale non richiesta verso un contatto aziendale è trattata molto più severamente di quanto lasci intendere il solito riassunto sul "legittimo interesse". Decidetelo con un legale, mercato per mercato, e costruite il sistema in modo che le regole possano differire per Paese senza riscriverlo.

Il resto sono decisioni tecniche con conseguenze in fase di qualifica fornitore. Il questionario di un cliente chiederà dove viene trattato il testo della sua richiesta, se esce dall'UE, se addestra il modello di qualcuno e per quanto tempo viene conservato. Quattro risposte brevi vi fanno superare quel primo filtro: trattamento nell'UE, nessun addestramento sui contenuti dei clienti, un periodo di conservazione definito, accessi tracciati. Dietro il filtro ci sono un DPA firmato, l'elenco dei sub-responsabili, le vostre misure tecniche e organizzative e di solito un certificato ISO 27001 o SOC 2. Preparateli prima che arrivi la richiesta.

Tenete una persona nel percorso di qualsiasi decisione che rifiuti una richiesta, che è insieme il progetto giusto e la fine della discussione sul processo decisionale automatizzato. Al di là della legge, un cliente industriale europeo si aspetta di essere trattato da professionista, e un "ricollegandomi alla nostra conversazione" inventato fa più danni, in un mercato tecnico piccolo, che non scrivere nulla.

Da dove partire: il primo progetto di IA nelle vendite

Un solo flusso, otto-dodici settimane, un responsabile con nome e cognome nelle vendite e uno in ufficio tecnico, e una definizione scritta di successo prima di costruire qualsiasi cosa. Partite dal percorso delle RdO in ingresso: lì il valore è concentrato, e il modo in cui fallisce è visibile prima di tutto alle vostre persone.

Passate le prime due settimane a raccogliere cinquanta RdO reali degli ultimi due anni, con che cosa è stato offerto e come è andata a finire. Quell'insieme è il banco di prova, e senza di esso state valutando su dimostrazioni scelte da chi le ha costruite. Poi costruite l'estrazione e l'elenco delle informazioni mancanti, verificati dall'ufficio tecnico rispetto a quello che il requisito si è poi rivelato essere. L'assistente rivolto al cliente viene per ultimo, perché è l'unico che parla con i clienti senza supervisione.

Scrivete i criteri di uscita prima di iniziare: tempo di prima risposta su un segmento definito, ore di ufficio tecnico per RdO, ed estrazione valutata su quell'insieme di riferimento, precision per campo e soprattutto recall sui campi che portano rischio di offerta. Il tasso di accettazione è un segnale di adozione, non un criterio di uscita: appena i tecnici capiscono che è quello il punteggio, le correzioni marginali smettono, e gli errori che contano sono omissioni che un revisore, scorrendo un elenco ordinato, non coglie. Decidete in anticipo che cosa rifiuterete: l'outbound a volume, qualunque cosa invii senza revisione, farlo girare dove la base giuridica o la posizione dell'NDA sono aperte.

Dove si colloca Meta Smart Factory

META CRM Bot di MSF è il prodotto sul lato vendite di questa piattaforma; gli altri moduli presenti su questo sito — MES, APS, MRP, qualità, manutenzione, magazzino — fanno girare la fabbrica. Costruiamo entrambe le metà, ed è il motivo per cui il discorso qui sopra parla di sequenza e di qualità dei dati invece che di funzionalità.

Una cosa va detta invece che glissata: quel prodotto è presentato qui come messaggistica multilingua attiva 24 ore su 24, e in una vendita tecnica non è la parte da accendere per prima. I limiti indicati qui sopra sono configurazione, non marketing — bozza scritta dal modello e invio fatto da una persona, escalation su qualsiasi impegno di specifica, prezzo o consegna, niente outbound a volume in un mercato dove gli stessi nomi tornano. Chiedeteli in una prova.

La parte su cui vale la pena ragionare è la giunzione. Due domande dominano una richiesta industriale, riuscite a tenere questa caratteristica a questo ritmo e ci sarà in settimana 34, e nessuna delle due è una domanda a cui debba rispondere un assistente. La prima è capacità di processo su una caratteristica, una macchina e un'attrezzatura specifiche, con uno studio R&R che non si mangi metà della banda di tolleranza, e su un particolare nuovo non c'è storico da cui rispondere. La seconda è una domanda sulla capacità produttiva futura, rispetto a un portafoglio ordini che cambia ogni giorno. La puntualità di consegna storica non è capacità, e la capacità di oggi non è la capacità della settimana 34.

Quello che un assistente può fare è andare a prendere le evidenze e metterle davanti alla persona che risponde. Tempi ciclo misurati e scarti sul particolare comparabile più vicino dicono al vostro tecnico se la richiesta giustifica uno studio di capacità; il portafoglio ordini dell'APS dice al vostro pianificatore se la settimana 34 è plausibile. La data continua a venire dal pianificatore. Se il dato di produzione non è affidabile, uno strato di IA sulle vendite costruito sopra di esso quoterà comunque a partire da quello.

Quindi la prima conversazione più utile non è una dimostrazione. È una revisione delle vostre RdO recenti e di che cosa è successo a ciascuna, perché in un pomeriggio quello mostra dove la vendita sta perdendo tempo — e a volte la risposta è che non è la parte che il software può sistemare.