Dal form al CRM senza toccare niente

Il problema che non si vede

C'e' un'operazione che quasi tutte le aziende di servizi fanno ogni giorno, di solito senza nominarla: prendono le informazioni che un cliente ha scritto in un modulo di contatto, le leggono, e le ricopiano da qualche parte. Nel CRM, in un foglio Excel, in un'email al tecnico. Mani umane che spostano dati da un posto all'altro.

Non e' un problema enorme. Ma si accumula. E ogni volta che un dato passa per mani umane, c'e' un margine di errore, un ritardo, un passaggio che dipende da qualcuno che sia libero, sveglio e concentrato in quel momento.

L'idea di fondo

Ho lavorato all'implementazione di un sistema di gestione richieste assistenza tecnica per un'azienda con due sedi operative sul territorio italiano. Il punto di partenza era semplice: i clienti compilano un modulo sul sito, l'azienda riceve la richiesta, qualcuno la prende in carico e apre un ticket.

Il punto di arrivo che volevamo era diverso: il modulo viene compilato, e il ticket si apre da solo nel CRM, con tutti i dati gia' dentro, inclusa la zona geografica dell'impianto e la sede di riferimento piu' vicina.

Nessun passaggio manuale nel mezzo.

Come funziona mentre il cliente scrive

La parte che trovo piu' interessante di questa implementazione e' quella che avviene prima ancora che il modulo venga inviato. Nel momento in cui il cliente digita il nome del suo comune, il sistema fa una chiamata all'API di OpenStreetMap, ottiene le coordinate geografiche di quel luogo, e calcola la distanza in linea d'aria da entrambe le sedi aziendali.

Sceglie quella piu' vicina. Assegna una zona tariffaria — A se l'impianto e' entro 30 km, B fino a 60 km, C oltre — e mostra all'utente un badge arancione che gli dice dove si trova rispetto alla rete di assistenza. Nel frattempo, tre campi nascosti del modulo si compilano automaticamente con zona, sede e distanza in km.

Il cliente non vede quasi niente di tutto questo. Vede solo la sua fascia geografica evidenziata nella tabella dei costi, e un messaggio che gli dice qual e' la sede piu' vicina. Ma sotto c'e' gia' tutta l'informazione che serve all'azienda.

Il viaggio dei dati dopo il click su Invia

Quando il modulo viene inviato, Contact Form 7 passa tutti i campi — inclusi quelli calcolati automaticamente — a uno scenario Make. Make li riceve, li legge, e li usa per creare un Case in EspoCRM: il sistema CRM su cui lavora il team tecnico.

Il Case viene aperto con il nome del cliente, l'indirizzo dell'impianto, il tipo di problema segnalato, la descrizione, e — nella sezione note — la zona di intervento con la sede assegnata e la distanza calcolata. Parallelamente, Make manda un'email di conferma al cliente e una notifica interna al team.

Dall'invio del modulo all'apertura del ticket: pochi secondi. Zero operazioni manuali.

Lo stack tecnico, in parole semplici

Il sito gira su WordPress con WooCommerce. Il modulo di contatto e' Contact Form 7. La logica di zona e' uno script JavaScript vanilla — niente librerie esterne, niente dipendenze — che viene caricato tramite un plugin per snippets di codice. Make gestisce l'automazione. EspoCRM e' il CRM su cui lavora il team.

Nessuno di questi strumenti e' costoso o esoterico. Tutti hanno API e webhook standard. Il lavoro e' stato connettere i pezzi nel modo giusto.

Cosa cambia davvero

La risposta ovvia e': si risparmia tempo. Ed e' vero. Ma non e' la cosa piu' importante.

La cosa piu' importante e' che il processo non dipende piu' dalla disponibilita' di una persona specifica. Se la richiesta arriva alle 22 di domenica, il ticket viene aperto lo stesso. Se chi normalmente gestisce l'email e' in ferie, il ticket viene aperto lo stesso. Il cliente riceve la conferma immediata, il team ha il dato quando ne ha bisogno.

L'altro cambiamento che non e' immediatamente visibile: i dati arrivano nel CRM in formato strutturato e uniforme. Non “Brescia, credo zona B” scritto a mano da chi ha letto l'email, ma “Zona B — Sede di Galliera (BO) — 47 km” calcolato automaticamente e sempre nel formato corretto.

Questo conta, perche' i dati strutturati si possono filtrare, aggregare, analizzare. Dati scritti a mano in modo eterogeneo, no.

Una nota a margine sul cambio di paradigma

Il modulo di contatto, in questo progetto, non e' uno strumento di comunicazione. E' il primo step di un processo operativo. Il momento in cui il cliente lo compila e' anche il momento in cui l'azienda riceve tutte le informazioni che le servono, gia' elaborate e pronte da usare.

Questo cambia il modo di pensare alla UX del modulo, al tipo di dati che ha senso raccogliere, a cosa vale la pena calcolare automaticamente e cosa lasciare all'operatore.

Non e' una questione di tecnologia. E' una questione di dove metti il confine tra quello che fa il sistema e quello che fa la persona.

Quante ore alla settimana stai usando per spostare dati da un posto all'altro? Quella e' la domanda giusta da cui partire.