Una società che fissa appuntamenti commerciali per altre aziende lavorava su un gestionale precedente. Ci ha chiesto una riscrittura indipendente, fedele alle sue regole, un modulo alla volta. Progetto in corso.
Il cliente è una società che fissa appuntamenti commerciali per conto di altre aziende: un team di commerciali chiama al telefono liste di aziende e persone, e ogni appuntamento preso diventa un’opportunità per il cliente finale. Il lavoro girava su un gestionale precedente, costruito su un’altra tecnologia, che conteneva regole precise su cosa succede dopo ogni telefonata.
Ci ha chiesto una riscrittura indipendente: un sistema nuovo, su basi tecniche diverse, fedele a quelle regole e pronto a crescere. Il flusso da coprire va dall’anagrafica condivisa di aziende e persone ai progetti per ciascun cliente, dalle liste da chiamare agli esiti, fino agli appuntamenti e alla pipeline.
Una giornata tipo. Il commerciale apre la sua lista, cinquanta contatti per pagina, con i contatori in alto: da chiamare, senza risposta, da richiamare, appuntamenti presi, dati errati. Chiama e registra l’esito. Se prende l’appuntamento, il contatto entra in pipeline con lui come titolare. Se la persona chiede di essere richiamata, il sistema pretende data e ora, così il richiamo compare nel giorno giusto. Se si oppone, numero e partita IVA finiscono in una lista di esclusione. Se il dato è sbagliato, il contatto passa in un cestino da verificare.
Tutto questo lo fa un’unica funzione nel database, che applica le conseguenze di ogni esito in un solo passaggio: o riesce tutto, o resta tutto com’era. L’esito registrato su un’azienda si riflette sulle persone della stessa lista, e viceversa. Cestini e liste di esclusione si formano da soli a partire dagli esiti, senza interventi a mano.
Ogni ruolo ha la sua vista. Amministratore e team leader governano utenti, anagrafica e progetti. Il commerciale lavora le sue liste, e accede all’anagrafica generale solo se è un profilo autonomo. Il cliente finale vede in sola lettura la pipeline e gli appuntamenti del proprio progetto, e dopo ogni incontro ne registra l’esito: interessante, in trattativa, concluso, chiuso senza seguito, da riprogrammare. I permessi sono scritti nel database e partono chiusi: ogni accesso va concesso esplicitamente.
Un modulo alla volta, nell’ordine del flusso: accessi e utenti, anagrafica con importazione e deduplica, progetti e liste, lavorazione degli esiti, pipeline, agenda, email, dashboard per ruolo. Un modulo è finito quando passa build, controllo dei tipi, test automatici e test che usano l’applicazione come un utente vero.
Prima di importare i dati del sistema precedente li abbiamo analizzati: aziende, persone e utenti si portano, le password restano indietro, perché sono cifrate in un formato diverso, e ogni utente riceve un invito a sceglierne una nuova. Le segnalazioni del cliente arrivano da un pulsante presente in ogni pagina, e passano da una fase di smistamento e poi da un collaudo dedicato. Per chi riprenderà il codice c’è una consegna tecnica scritta, funzione per funzione.
Il nucleo è completo: dall’anagrafica alla dashboard, passando per esiti, pipeline, agenda ed email.I prossimi moduli sono offerte e preventivi, le notifiche dentro l’applicazione e un’area cliente più ampia.
Con permessi scritti nel database, chiusi in partenza
Su 266 file, dalle regole di business ai permessi
Percorsi provati come li fa un utente vero
Con vista in sola lettura per il cliente finale
Un’agenzia assicurativa sostituisce due sistemi separati con una piattaforma database-first.
Candidature in italiano e in inglese per il premio internazionale di una fondazione. Progetto in corso.
Turni, incassi, spese e stipendi soci in un unico sistema, in continua evoluzione.
Raccontateci come lavorate oggi. Si comincia dall’analisi, compresa nel prezzo del progetto.