Dopo aver rimesso in ordine l'infrastruttura di un contact center multi-committente, il passo più delicato: sostituire il gestionale dei ticket. Un programma nato nel 2008, cresciuto per aggiunte, con oltre tre milioni di ticket e una configurazione ormai impossibile da governare senza il fornitore. L'abbiamo rifatto su Odoo Community — ma guardando prima cosa si usa davvero.
01Prima di progettare: guardare cosa si usa davvero
Il primo documento non era un progetto: era un'analisi dell'uso reale, interrogando il database. I numeri hanno cambiato le priorità: il 93% dei ticket non lo apre una persona ma il centralino, all'arrivo della chiamata — l'integrazione telefonica è il cuore, non un accessorio. Dei seimila motivi configurati, nell'ultimo anno ne sono stati usati poche centinaia. Quasi un ticket su tre non era attribuito a nessun committente. Cinque stati non erano mai stati usati. Da qui il principio: riprodurre il nucleo che si usa, bene, e lasciare indietro il resto.
02Le scelte di fondo
Tutto open source e senza licenze: Odoo Community con i moduli helpdesk della comunità OCA, su un server in sede — nessun canone, nessun dato fuori dall'azienda. Accesso con l'utenza di dominio. Separazione rigorosa per committente: ogni azienda cliente vede solo i propri ticket e clienti. Configurabile da chi lo usa: stati, motivi, testi e wiki li gestiscono le responsabili — più il sistema si adatta da solo, meno sviluppi servono.
03Cosa abbiamo costruito
Una scheda ticket pensata per il telefono: segue la sequenza della telefonata, i motivi più usati compaiono per primi, le frasi ripetute sono diventate testi rapidi da un clic. La storia delle modifiche con valore legale: ogni campo entra nello storico con valore precedente, autore e ora; ticket e note non si cancellano, si correggono aggiungendo. I connettori diretti ai database dei committenti: si cerca il cliente per codice, nome o fornitura e l'anagrafica entra nel ticket, senza passare da un servizio esterno.
04API REST e wiki dentro il ticket
Il nuovo sistema espone una API REST documentata (OpenAPI) con chiavi separate per ogni sistema esterno, permessi per committente, webhook firmati. E la base di conoscenza — oltre tremila articoli — è stata rimessa in ordine e portata dentro la scheda del ticket: mostra gli articoli del committente e del motivo in lavorazione, si cerca con una parola, si apre lì. L'obiettivo era uno solo: che le operatrici non debbano aprire dieci finestre per rispondere a un cliente.
05I dati: popolare prima di validare
Un sistema nuovo si valida con dati veri. Abbiamo importato l'intero anno in corso — circa 175.000 ticket e quasi 80.000 anagrafiche — con date originali, motivi multipli e riferimenti. L'importazione completa richiede un quarto d'ora ed è ripetibile: aggiunge solo ciò che manca. Serve anche a far emergere i campi che ci eravamo persi.
06Cosa abbiamo imparato
1. I dati d'uso valgono più di qualunque requisito scritto. 2. Rifare il nucleo, non tutto. 3. La configurabilità è un investimento: ogni scelta lasciata a chi usa il sistema è uno sviluppo in meno. 4. Tenere tutto dentro il ticket: un'informazione a un clic è un'informazione che viene usata.