Vai al contenuto
← Tutti i progetti
Sistema2026In sviluppo

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

  1. Ordine

    La richiesta entra da un unico punto.

  2. Validazione

    I dati mancanti diventano visibili, non spariscono.

  3. Back office

    Chi gestisce vede cosa manca e cosa va deciso.

  4. Chiamata

    Il contatto con il cliente per chiudere i dettagli.

  5. Appuntamento

    Data, luogo e fotografo compatibile.

  6. Stato incarico

    Dov'è il lavoro, in ogni momento.

  7. Consegna

    Materiali pronti e incarico chiuso.

Collegati