Perché un gestionale pensato per un solo settore batte il generico

Perché i software generici si rompono davanti ai vincoli fisici

Un gestionale generico tratta ogni risorsa prenotabile come una riga in un calendario. Una sala riunioni, un tavolo, un operatore: cambia l'etichetta, non la struttura. Finché l'attività vive dentro un foglio orari, il modello regge. Quando entra in gioco lo spazio fisico, si rompe.

Prendiamo una spiaggia. L'ombrellone numero 34 ha una collocazione precisa: sta in seconda fila, a sinistra dell'ingresso, ha due lettini e costa meno di quello in prima fila davanti al mare. Il cliente chiede quel numero, perché sa già dove si trova e quanto gli costa. Un software generico può solo elencare voci identiche e sperare che il bagnino ricordi la disposizione. La piantina resta appesa in cabina, su carta, e continua a essere la vera fonte di verità. Il gestionale la insegue.

Un salone ha un vincolo diverso, ma della stessa natura. Gli orari disponibili non stanno su una griglia fissa da trenta minuti. Dipendono dal turno dell'operatore scelto, dalle chiusure, dalla durata effettiva del servizio: un taglio e una colorazione occupano spazi diversi. Un calendario generico propone le nove e mezza a chiunque, poi qualcuno deve telefonare per spostare.

Il sintomo è sempre lo stesso. Il campo note diventa il database reale. Lì finiscono la fila, il numero della postazione, il fatto che quel cliente accetta solo un certo operatore il sabato. Informazione che nessuna query legge, che nessuna statistica conta e che sparisce quando cambia la persona in cassa.

Il modello dei dati decide tutto il resto

La parte più difficile di un SaaS verticale sta nello stabilire che cosa esiste nel sistema e come le entità si legano fra loro. Quella scelta si fa nelle prime settimane e si paga per anni, perché è l'unica che non si cambia con un aggiornamento.

Un esempio concreto di bivio: gli slot di un appuntamento si salvano o si calcolano? Salvarli è semplice e veloce da leggere, ma quando cambia un turno bisogna rigenerare tutto, e il passato resta incoerente. Calcolarli a partire dalle regole, cioè turni, chiusure e durata del singolo servizio, richiede più lavoro all'inizio e regge molto meglio le eccezioni. In BarbierItalia abbiamo scelto la seconda strada: la disponibilità è una conseguenza delle regole, calcolata a ogni richiesta.

Sull'altro prodotto il ragionamento parte dallo spazio. In Beachfy la mappa è l'entità primaria: le postazioni hanno coordinate reali sulla spiaggia, appartengono a un settore, e dal settore discendono il listino e i prezzi feriale, weekend e alta stagione. Disponibilità, registro prenotazioni e statistiche di occupazione derivano tutti da lì. Se avessimo modellato le postazioni come semplice elenco numerato, l'editor drag and drop non avrebbe avuto nulla su cui poggiare.

Due accorgimenti che raccomandiamo sempre. Il primo: congelare sulla prenotazione il prezzo applicato, invece di leggerlo dal listino corrente. Un aumento di tariffa non deve riscrivere lo storico. Il secondo: modellare prima le eccezioni e poi il caso ideale. La chiusura improvvisa, l'operatore assente, il cliente che non si presenta, la correzione fatta il giorno dopo. Un modello costruito solo sul percorso perfetto va rifatto al primo mese di uso reale.

C'è poi una regola pratica sulle identificazioni. Ogni oggetto che il cliente finale deve leggere, dire al telefono o mostrare allo staff ha bisogno di un codice leggibile. In Beachfy la prenotazione produce un codice nel formato BCH e un biglietto digitale con QR code: lo stesso codice serve poi per ordinare al bar e ricevere alla postazione. Un identificatore tecnico interno non avrebbe potuto svolgere quel ruolo.

Multi-tenant: un solo prodotto per molti clienti

Un software su misura per un singolo committente è un progetto. Un prodotto verticale serve decine di attività con la stessa base di codice. La differenza tecnica ha un nome: multi-tenant. Ogni cliente è un inquilino, i dati sono suoi e devono restare invisibili agli altri.

L'isolamento va progettato dal primo giorno. Ogni documento porta l'identificativo del tenant e le regole di sicurezza vengono scritte in modo che una lettura senza quel riferimento non restituisca nulla. È la parte meno visibile del lavoro e la più costosa da aggiungere dopo, perché richiede di ripassare ogni query già scritta. Entrambi i prodotti separano anche il percorso di accesso: Beachfy assegna un sottodominio per gestore, BarbierItalia dà a ogni salone abbonato un sito su nomeSalone.barbieritalia.it.

La personalizzazione va tenuta al livello della configurazione, con una sola base di codice per tutti. Appena si crea un ramo dedicato per accontentare un cliente, il prodotto si trasforma in tanti progetti da manutenere in parallelo. In BarbierItalia il salone modifica dal pannello colori, carattere, raggio degli angoli e ordine delle sezioni, e sceglie fra quattro preset già impostati: Classico, Elegante, Moderno, Deciso. Il risultato appare diverso per ogni salone, ma è sempre lo stesso applicativo.

Gli aggiornamenti hanno il pregio e il difetto di arrivare a tutti insieme. Una correzione raggiunge ogni cliente senza interventi, e questo abbatte il costo di manutenzione rispetto a installazioni separate. Vale anche al contrario: un errore in produzione è un errore per tutti, contemporaneamente. Da qui discendono scelte poco appariscenti ma necessarie, come poter disattivare una funzione senza rilasciare una nuova versione, e come avere una procedura di migrazione dei dati che venga eseguita per ogni tenant e sia ripetibile senza danni.

Ultimo punto, spesso trascurato: l'assistenza. Con dati isolati non puoi riprodurre il problema di un cliente guardando i tuoi. Servono registri degli eventi e la possibilità, tracciata, di vedere il contesto di quell'attività. Chi progetta un prodotto verticale deve mettere in conto anche questo lavoro.

Due verticalizzazioni reali su settori diversi

Beachfy e BarbierItalia sono nati dallo stesso metodo e hanno prodotto due applicativi che si somigliano poco. È esattamente il punto della verticalizzazione.

Il problema di uno stabilimento balneare è spaziale e stagionale. La domanda si concentra in pochi mesi, il prezzo cambia fra feriale, weekend e alta stagione, e il cliente vuole vedere dove si siederà. Per questo il cuore di Beachfy è Map Studio, un editor drag and drop che ricostruisce la mappa reale della spiaggia su una cattura satellitare o su una foto caricata, con orientamento del mare, aggancio alla griglia, annulla e ripristina e salvataggio automatico. Da quella mappa discende tutto il resto, compresi gli ordini al bar consegnati alla postazione tramite il codice della prenotazione. Il prodotto è già sviluppato ma non ancora aperto al pubblico: la home è una pagina di attesa con countdown e l'apertura è dichiarata per l'estate 2027.

Il problema di un salone è temporale e relazionale. Contano la persona scelta e la durata dell'appuntamento, prima ancora del posto in cui si siede. Gli slot si calcolano sui turni dell'operatore scelto, sulle chiusure e sulla durata del servizio. Il valore aggiunto sta nel doppio versante: una directory pubblica dove il cliente cerca per città o vicinanza e prenota, e un pannello dove il salone gestisce agenda multi-operatore, listino, turni, anagrafica con storico visite e mancate presenze, oltre alla panoramica giornaliera con incasso previsto. Il gestionale genera anche il sito del salone, sul sottodominio, con il pulsante di prenotazione già integrato.

Stesse tecnologie di base, in gran parte, e due modelli dei dati incompatibili fra loro. Nessun software generico avrebbe potuto servire entrambi senza costringere uno dei due a snaturarsi. Il prodotto dichiara anche i propri limiti, e questa è una scelta di progetto: BarbierItalia oggi non offre dominio proprio, manda promemoria solo via email, esporta l'anagrafica clienti su richiesta, non incassa al posto del salone e non è un registratore di cassa.

Canone o commissioni: il modello economico cambia il rapporto

La scelta fra canone fisso e commissione sulle transazioni arriva spesso al momento del listino, quando il prodotto sembra già deciso. In realtà appartiene alle decisioni di prodotto, perché stabilisce che cosa il software cercherà di ottimizzare.

Con la commissione, chi fornisce il software guadagna quando il cliente lavora di più. Sulla carta è allineamento di interessi. Nella pratica introduce un attrito: l'esercente inizia a chiedersi quali prenotazioni far passare dalla piattaforma e quali no, e il cliente abituale viene spinto verso il canale diretto. La piattaforma reagisce rendendo difficile aggirarla. Da lì il rapporto cambia tono.

Con il canone fisso il costo è noto in anticipo e non cresce nei mesi buoni. Chi produce il software deve dimostrare valore ogni rinnovo, perché non incassa una quota del successo altrui. È il modello di BarbierItalia: 29 euro al mese oppure 249 euro all'anno, zero commissioni sulle prenotazioni, trenta giorni di prova senza carta, abbonamento gestito tramite Stripe con portale di fatturazione. L'incasso della prestazione resta al salone. IVA non applicata per regime forfettario.

C'è una conseguenza tecnica che pesa quanto quella commerciale. Non incassare per conto del cliente significa non diventare intermediario dei pagamenti, con tutto ciò che comporta in termini di obblighi, riconciliazioni e contestazioni. Beachfy spinge la stessa logica ancora più avanti: il pagamento avviene in spiaggia e la piattaforma non tratta dati di carta, mentre l'attivazione per i gestori è gratuita. Meno superficie normativa da presidiare e un ostacolo in meno all'adozione da parte di attività che non hanno un ufficio amministrativo.

Il consiglio che diamo a chi valuta se costruire un prodotto proprio è di decidere il modello economico già prima dell'architettura. Un prodotto a commissione e uno a canone hanno bisogno di funzioni diverse, di garanzie diverse e di un rapporto diverso con chi lo usa tutti i giorni.