SNAP è una catena di self-photo studio in sei città indonesiane. Il vecchio sito era una brochure statica — le prenotazioni arrivavano via DM su WhatsApp, ogni sede gestiva il proprio quaderno, e circa una sessione su dodici finiva con uno scontro alla porta. Abbiamo ricostruito il flusso cliente come PWA e consegnato un unico pannello di controllo che vede tutte e sei le sedi in un colpo solo.
Una PWA mobile-first lato cliente, una SPA desktop lato admin, un'unica API e un unico database sotto. Sei moduli reggono l'intera catena — dalla schermata città che il cliente vede su Instagram al riepilogo giornaliero che il responsabile di sede conferma a fine turno.
Sei città, dodici sedi, due archetipi di studio fisico. Il flusso cliente salta automaticamente la scelta della sede nelle città con un solo studio e instrada il modello di capienza corretto in base alla location.
Gli studio box utilizzano una matrice fondale×orario — ogni stanza si prenota in modo indipendente. Gli studio a rullo hanno un unico calendario condiviso con scelta del fondale puramente estetica. Stessa struttura UI, due regole di capienza diverse sotto.
Il cliente scansiona un codice QRIS dinamico, il callback del merchant libera lo slot, il cliente vede la spunta. Nessuno staff che controlla il m-banking. Nessun messaggio manuale "ha pagato?".
Un solo dashboard per il fondatore. Prenotazioni odierne su tutte e sei le sedi, vendite rispetto a ieri, spese per categoria, occupazione per stanza. Da qualsiasi riquadro si scende fino alle righe grezze.
I responsabili di sede vedono solo la propria sede — calendario odierno, attivazione slot walk-in, registro spese, conteggio cassa a fine giornata. Basato sui ruoli, bloccato per impostazione predefinita.
Prenotazione confermata → parte un messaggio WhatsApp precompilato con lo slot, l'indirizzo della sede e un link al calendario. Reminder due ore prima. Il thread DM non è più dove vivono le prenotazioni, ma è ancora dove i clienti si aspettano una risposta.
Ogni sede aveva il proprio numero admin. I clienti scrivevano "domani alle 15 a Kemang?" e qualcuno rispondeva se era sveglio. Due addetti a volte confermavano lo stesso slot a due clienti diversi, perché l'inbox era l'unica fonte di verità.
Nei fine settimana di punta circa una sessione su dodici finiva con uno scontro alla porta — una parte veniva rimbalzata, rimborsata e diventava rumorosa su Instagram.
Il cliente sceglie una città, una sede, una data, un orario e un fondale — ogni passaggio scrive un blocco su una riga reale. Due telefoni che premono lo stesso slot nello stesso secondo: uno vince, l'altro vede "appena occupato" e si vede proporre il prossimo blocco libero da 30 minuti.
La conferma arriva poi via WhatsApp, così i clienti ricevono risposta dove si aspettano. Il DM è ora la ricevuta — non la prenotazione.
Metà delle sedi sono studio box — ogni fondale occupa una stanza propria, quindi due fondali equivalgono a due sessioni parallele. L'altra metà sono studio a rullo — più fondali appesi in un'unica stanza, ma una sola sessione per volta.
Il vecchio sito li trattava in modo identico. I clienti prenotavano quattro fondali contemporaneamente in una sede a rullo e arrivavano scoprendo che non potevano tenersi tutti.
Ogni sede è contrassegnata multi o single nel database. Gli studio box ottengono una griglia fondale×orario — scegliere una cella significa scegliere una stanza e un orario in un solo gesto. Gli studio a rullo ottengono un unico calendario condiviso e una scelta separata del fondale, puramente estetica.
Stessa struttura React, stessi componenti, forma dei dati diversa da un unico endpoint. Il cliente non deve mai sapere la differenza.
○ libero × occupato ● selezionato
Il cliente fa il bonifico, cattura lo schermo come prova, la invia su WhatsApp. L'admin della sede apre l'app di m-banking, cerca l'importo corrispondente, risponde «ok confermato» e segna lo slot nel quaderno. Cinque minuti per prenotazione nelle giornate tranquille, molto di più il sabato.
Se l'admin era a pranzo, il cliente aspettava. Se aspettava troppo, annullava.
Conferma automatica.
Nessuno screenshot necessario.
Per un admin di sede il sabato tra l'apertura e mezzogiorno — la fascia più intensa. Stessa persona, stesso lavoro, prima e dopo il rifacimento.
Un sabato intero ciascuno con due admin di sede. Abbiamo osservato il quaderno che si riempiva, le chat che si accavallavano, il m-banking che veniva aggiornato di continuo. Ogni passaggio annotato. Tutto ciò che non serviva se esistesse un database, eliminato.
PWA React + Vite, Express + MySQL sul backend. Due modelli di prenotazione dietro un'unica forma di endpoint così la UI non si sdoppia. Integrazione merchant QRIS con fallback webhook affinché una rete instabile non lasci mai un cliente a metà del pagamento.
SPA admin: panoramica, calendario prenotazioni, spese, vendite, report, impostazioni. Prima attivazione su una sola sede (Kemang), monitorata per una settimana, poi le altre due alla volta. I quaderni ritirati sede per sede.
I numeri qui sotto provengono dal database live della sede pilota (Kemang) più le due sedi andate online in seguito. I dati sull'intera catena verranno pubblicati solo quando ci saranno abbastanza mesi di dati reali alle spalle.
Sei sedi in sei città, un fondatore che deve poter leggere il dashboard dal telefono in fila al bar. Ogni decisione ha risposto a: cosa succede se il wi-fi di una sede cade nel pieno del sabato?
Installabile dalla schermata Home. Transizioni di pagina via Framer Motion. CSS Modules e palette strettamente bianco-nero — le foto portano il colore, il chrome se ne sta fuori dai piedi.
Un unico database, sedi come righe, modello di capienza come enum. Le scritture degli slot passano per un unico endpoint che blocca la riga per impedire a due prenotazioni simultanee di vincere la stessa cella.
Codice QRIS dinamico per prenotazione con TTL di 15 minuti. Il webhook di liquidazione libera lo slot; se il webhook fallisce, un poller riconcilia entro un minuto. In entrambi i casi il cliente vede la stessa spunta.
Nessuna codebase admin separata. Il login del fondatore porta al layout desktop con sidebar; il login di sede porta a una vista a sede singola. RBAC all'API, non all'UI — navigare nell'interfaccia non potrà mai darti qualcosa che il server non ha già approvato.
Una chiamata esplorativa gratuita. Le diremo la cosa più semplice che risolve il problema.
Sistemi come questo girano su Core Platform + moduli personalizzati — la maggior parte dei sistemi di prenotazione si colloca tra $2.500 e $4.500. Prezzi completi →