PhotoCRM — il gestionale che non perde niente
Il sistema operativo interno di Photonica, costruito attorno a una regola: un dato può arrivare sbagliato, ma non può sparire.
RuoloIdeazione, progettazione e sviluppo
Nato dentroPhotonica
Com'era prima
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, le comunicazioni e il lavoro di back office.
Funziona. Ma il lavoro vive spezzato su quattro strumenti che non si parlano.
Il problema
Il difetto di questa catena non è che sia primitiva. È che nessun punto della catena 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.
E 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.
La decisione
La scelta era comprare un gestionale o costruirlo. Quelli che abbiamo guardato erano modellati su un altro mestiere: nessuno sapeva cosa fosse uno spostamento tra due immobili o una coda di post-produzione, e avremmo dovuto piegare il lavoro alla forma dello strumento.
Ho preferito costruire una cosa modellata sul processo che già avevamo.
La regola: zero perdite silenziose
Sopra tutto il resto ho messo 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.
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.
Dove siamo
PhotoCRM è nella 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, quindi i numeri che si vedono dentro non sono incarichi gestiti dal gestionale: sono anni di lavoro precedente portati dentro. È una distinzione che tengo a fare, perché è esattamente il tipo di numero che è facile far passare per qualcos'altro.
Non metto una data di rilascio finché non ne ho una di cui fidarmi.
Come si incastra con l'app
PhotoCRM è solo interno. Gli agenti immobiliari non ci entreranno mai: la loro faccia del sistema è Photonica App, che sta sullo stesso flusso di dati dal lato opposto.
Uno strumento per chi ordina, uno per chi esegue, un solo stato condiviso.
Cosa ho imparato
Togliere è una funzionalità. A un certo punto ho rimosso un intero modulo di post-produzione 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.
Il percorso di un incarico dentro il sistema
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.
Segreti
Tutti i segreti- 31 luglio 2026
Automatizzare un'azienda di servizi: cosa stiamo cambiando dentro Photonica
Cinque interventi su un'azienda vera, in ordine di quanto sono già reali. Due sono servizi che si comprano, uno è una capacità nuova, due sono ancora in costruzione.
- 31 luglio 2026
Perché sto costruendo un CRM interno invece di continuare con Forms, Sheets e Calendar
Non perché quegli strumenti siano scadenti. Perché nessuno dei quattro sa dire a che punto è un incarico, e quel montaggio lo sta facendo una persona a memoria.
- 31 luglio 2026
Perché stiamo costruendo un'app per gestire il rapporto tra Photonica e le agenzie immobiliari
Il problema non è il tempo che perdiamo noi. È che un agente immobiliare non ha nessun posto dove guardare per sapere a che punto è il suo lavoro.
Collegati