Perché sto costruendo un CRM interno invece di continuare con Forms, Sheets e Calendar

Come funziona oggi il processo

Photonica riceve richieste di servizio da decine di agenzie immobiliari.

La richiesta arriva da un modulo, finisce in un foglio di calcolo, e da lì qualcuno la legge, decide quando farla, la scrive sul calendario e assegna un fotografo. Intorno girano le comunicazioni con il cliente e il lavoro di back office che tiene insieme i pezzi.

Funziona. È importante dirlo, perché il resto dell'articolo non è un processo a Google.

Perché Form, Sheet e Calendar funzionano all'inizio

Funzionano perché sono immediati e perché non impongono un modello.

Quando l'azienda è piccola questo è un vantaggio enorme: il processo sta ancora cambiando ogni due settimane, e uno strumento che si adatta a qualsiasi forma vale più di uno strumento che ne pretende una. Aggiungere una colonna costa cinque secondi. Cambiare un flusso in un gestionale costa una giornata.

Chiunque ti dica che partire da un foglio di calcolo è un errore, probabilmente non ha mai dovuto far partire qualcosa.

Dove iniziano i problemi

Il difetto non è che siano strumenti primitivi. È che nessuno dei quattro rappresenta lo stato reale dell'incarico.

Il modulo sa cosa è stato chiesto. Il foglio sa cosa è stato trascritto. Il calendario sa quando qualcuno andrà. La chat sa cosa è stato promesso al cliente. Per sapere davvero a che punto è un lavoro devi mettere insieme tutti e quattro, e quel montaggio lo fa una persona, ogni volta, a memoria.

C'è poi un secondo problema, più silenzioso: un foglio di calcolo non ha opinioni. Se una riga arriva con l'indirizzo scritto male, la accetta. Se due agenzie si chiamano quasi uguale, non se ne accorge. Se una riga viene sovrascritta, non lo dice a nessuno.

Il costo non è l'errore in sé. È che il lavoro di accorgersene ricade sulle persone, ogni giorno, e cresce insieme al volume.

Perché non ho scelto un CRM generico

L'ho valutato, ed è la strada che consiglierei a molti.

Quelli che abbiamo guardato erano però modellati su un altro mestiere: un funnel commerciale con contatti, opportunità e trattative. Nessuno sapeva cosa fosse uno spostamento fisico fra due immobili, una coda di post-produzione o un listino diverso per ogni agenzia. Avremmo dovuto piegare il nostro lavoro alla forma dello strumento, e la mia esperienza è che quando lo fai il processo vero non scompare: si sposta fuori dallo strumento, dentro una chat parallela dove succedono le cose che il gestionale non prevede.

A quel punto hai due sistemi invece di uno. Ho preferito costruire una cosa modellata sul processo che già avevamo.

Non è una scelta che si giustifica sempre. Si giustifica quando il processo operativo è il mestiere, e nel nostro caso lo è.

Il principio: zero perdite silenziose

Sopra tutto il resto c'è una regola sola.

Un dato può essere sbagliato, incompleto o incomprensibile. Non può sparire senza che qualcuno lo sappia.

Sembra ovvia. Non lo è: la maggior parte dei sistemi di importazione fa il contrario. Trovano una riga che non rispetta il formato e la scartano, magari scrivendo una riga di log che nessuno leggerà mai. Il risultato è un sistema che sembra pulito e intanto sta perdendo lavoro — e il modo in cui te ne accorgi è un cliente che chiama per chiedere di un servizio che per te non esiste.

Le conseguenze pratiche:

• Un ordine senza indirizzo non viene rifiutato: entra marcato come da completare, con la nota di cosa manca, e finisce in cima alla lista di chi deve sistemarlo.
• Un'agenzia il cui nome non corrisponde a nessuna anagrafica non fa scartare la riga: la riga entra e l'agenzia finisce in una coda di assegnazione rapida, dove una persona decide in due secondi.
• Ogni tentativo di importazione lascia una traccia con un esito esplicito. Non esiste lo stato "non è successo niente".

Il costo di questa scelta è che il sistema mostra il disordine invece di nasconderlo. Il primo mese è scomodo. Poi diventa l'unica ragione per cui ti puoi fidare dei numeri.

Come verrà gestito un ordine

Ordine          la richiesta entra da un unico punto
   ↓
Validazione     i dati mancanti diventano visibili, non spariscono
   ↓
Back office     chi gestisce vede cosa manca e cosa va deciso
   ↓
Chiamata        il contatto con il cliente per chiudere i dettagli
   ↓
Appuntamento    data, luogo e fotografo compatibile
   ↓
Stato incarico  dov'è il lavoro, in ogni momento
   ↓
Consegna        materiali pronti e incarico chiuso

Il punto della sequenza non è la sequenza: è che esiste un posto solo dove guardarla.

Cosa vedranno i clienti: niente

PhotoCRM è uno strumento interno e resterà tale. Gli agenti immobiliari non ci entreranno mai.

È una decisione presa presto e che rifarei. Un gestionale interno e un portale cliente hanno utenti diversi, frequenze d'uso diverse e tolleranze diverse alla complessità: farne uno strumento solo con due livelli di permessi significa scontentare entrambi. La faccia rivolta ai clienti sarà Photonica App, sopra lo stesso flusso di dati.

Uno strumento per chi ordina, uno per chi esegue, un solo stato condiviso.

Stato reale del progetto

PhotoCRM è in fase finale di sviluppo. Non è ancora il sistema operativo principale di Photonica: il lavoro quotidiano gira ancora in buona parte sulla catena di prima, e il passaggio sarà progressivo.

Il database contiene già dati storici importati. Vale la pena essere espliciti su cosa questo significa: quei numeri non sono incarichi gestiti dal gestionale, sono anni di lavoro precedente portati dentro. È esattamente il tipo di dato che è facile far passare per qualcos'altro, e non ho intenzione di usarlo come prova d'uso finché non c'è un uso vero da misurare.

Non metto una data di rilascio finché non ne ho una di cui fidarmi.

Cosa ho imparato costruendo software su un processo vero

Togliere è una funzionalità. A un certo punto ho rimosso un intero modulo e nascosto sei pagine poco usate. Il codice è rimasto nel repository, la navigazione è diventata più corta. Un gestionale che fa cinque cose che servono batte un gestionale che ne fa quindici di cui tre servono.

Le automazioni devono girare dove è noioso. Le sincronizzazioni a orario non girano sulla piattaforma che ospita l'applicazione ma su un servizio separato: costa zero, è più prevedibile, e se si rompe non porta giù il resto.

Un sistema interno è un prodotto. Ha utenti, ha un ciclo di rilascio, ha regressioni e ha persone che si arrabbiano se lo cambi male. Trattarlo come uno script è il modo più veloce per farlo morire.