RivieraOS nasce da una domanda concreta: come trasformare la ricerca dispersa di servizi locali in un percorso semplice, prenotabile e misurabile? Il progetto non parte dalla volontà di creare “un altro portale”, ma dalla necessità di collegare turista, fornitore e distribuzione territoriale dentro un solo flusso operativo.
ReggianiService ha lavorato sul progetto come caso di product design e architettura di servizio: Riccione come prima destinazione, smartphone come contesto principale e una regola che protegge ogni decisione successiva — trovare, scegliere, prenotare. La V0 rende il sistema navigabile e verificabile; non viene presentata come una piattaforma con transazioni o risultati commerciali già attivi.
Un territorio solo per validare il modello prima dell’espansione.
Trovare, scegliere e prenotare senza dover comprendere la complessità sottostante.
Prenotazione istantanea e richiesta da confermare.
Interfaccia funzionale e architettura predisposta; nessun pagamento live dichiarato.
01 · Il contesto
Il problema non era mostrare più attività. Era chiudere il percorso.
Un turista può trovare idee su Google, nei contenuti editoriali, in reception o sui social. Il punto debole arriva dopo: disponibilità non chiara, telefonate, passaggi su canali diversi e nessun collegamento stabile tra origine della visita, prenotazione e servizio erogato.
Anche il fornitore locale paga questa frammentazione. Riceve richieste incomplete, aggiorna disponibilità in modo manuale e spesso non sa quale canale abbia generato una vendita. L’hotel, infine, può consigliare un’esperienza ma non dispone necessariamente di un sistema leggero per attribuire quel valore senza gestire denaro o riconciliazioni.
Una directory locale
- Elenca attività ma interrompe il percorso.
- Rimanda la disponibilità a telefonate e messaggi.
- Non collega consiglio, prenotazione e transazione.
Un layer di prenotazione
- Presenta servizi selezionati e prenotabili.
- Registra booking, fonte e partner commerciale.
- Predispone commissioni e stato economico per singola prenotazione.
02 · Il flusso principale
La semplicità visibile è una scelta architetturale.
Per il turista RivieraOS deve sembrare quasi ovvio. Dietro quella semplicità, però, ogni passaggio produce uno stato leggibile. Il prodotto è stato ristretto a un servizio per prenotazione: niente carrello multi-provider, niente decine di categorie e nessuna funzione aggiunta soltanto perché tecnicamente possibile.
- Il fornitore propone un servizio.
L’attività e la scheda passano da controllo e approvazione, così il catalogo resta curato.
- Il turista sceglie senza creare obbligatoriamente un account.
Nome, contatto e dati necessari bastano per avviare la prenotazione e ricevere un link sicuro.
- Il booking segue la modalità corretta.
Instant quando la disponibilità è definita; Request quando il provider deve prima confermare.
- Il servizio viene erogato e completato.
Lo stato operativo precede qualsiasi disponibilità economica verso i beneficiari.
- I dati alimentano la decisione successiva.
Categoria, fonte, campagna e partner mostrano dove il modello genera domanda realmente completata.
03 · Gli utenti
Tre fronti diversi, una sola prenotazione da mantenere coerente.
Il prodotto non può offrire la stessa interfaccia a tutti. Il turista cerca velocità, il fornitore deve gestire operatività e disponibilità, mentre hotel e partner devono poter distribuire il servizio senza diventare venditori o cassieri. RivieraOS Control mantiene approvazioni, eccezioni e visibilità complessiva.
Esperienza mobile-first, guest checkout e gestione tramite link sicuro.
Servizi, disponibilità, richieste, calendario e quota economica espressa in modo semplice.
Link o QR tracciabile, senza incasso manuale né calcolo delle commissioni.
La regola di interfaccia è una schermata, un obiettivo principale. L’admin controlla e approva; il fornitore gestisce il servizio; il turista conclude la scelta; il partner osserva ciò che ha generato. Le complessità che non servono alla decisione restano fuori dalla vista.
04 · Il modello economico
Lo split nasce con il booking, non da una riconciliazione successiva.
La specifica V0 prevede che il fornitore mantenga la stessa quota sia in una prenotazione diretta sia quando interviene un hotel. Il partner viene remunerato dalla quota della piattaforma: il modello non trasferisce sul provider il costo della distribuzione.
Provider €83 · RivieraOS €17
- Nessun referral commerciale.
- La fonte marketing resta comunque misurabile.
- Nessun pagamento manuale della commissione.
Provider €83 · Hotel €5 · RivieraOS €12
- La quota provider non cambia.
- Il partner è collegato alla singola prenotazione.
- Il payout può seguire un calendario separato.
Un’altra decisione importante è distinguere earning, transfer e payout. Quanto spetta economicamente a un partner, il movimento verso il suo account e l’accredito bancario non sono la stessa cosa. Tenerli separati rende rimborsi, audit e riconciliazioni più leggibili.
MaisonEmy, Google, social e newsletter restano invece fonti marketing: possono spiegare l’origine della domanda, ma non modificano lo split. Solo un referral commerciale valido, come l’hotel, interviene sulla distribuzione economica.
05 · L’architettura
L’interfaccia rappresenta l’esperienza. Il Core rappresenta la verità.
La decisione tecnica più importante non riguarda un framework. Riguarda l’autorità dei dati. La UI deve poter cambiare senza diventare il luogo in cui si decide prezzo, commissione, pagamento riuscito o saldo dovuto.
Il browser non conferma un pagamento. Dopo il ritorno dal checkout può soltanto mostrare “stiamo verificando”. La conferma autorevole arriva dal Core dopo un webhook verificato e idempotente. In quel momento il sistema può segnare pagamento e booking, congelare lo split, registrare il ledger e aggiornare gli eventi.
- Nessuna chiave segreta nel frontend: Sites riceve dal Core soltanto ciò che serve all’esperienza.
- Gateway sostituibili: dati e pagamenti hanno adapter distinti per Demo, Test e Live.
- Idempotenza: un retry non deve duplicare checkout, transfer, refund o movimenti di ledger.
- Fallback onesto: se il Core non risponde, la UI non finge una conferma e chiarisce che la carta non è stata addebitata.
06 · La V0
Abbastanza completa per verificare il modello. Abbastanza piccola per imparare.
La prima versione si concentra su Riccione e su quattro categorie: bike e rental, transfer, esperienze e wellness. Il prototipo porta il concept fino a un’interfaccia navigabile con catalogo, schede servizio e flussi di prenotazione dimostrativi, mantenendo i dati transazionali in modalità demo.
Il nucleo da provare
- Catalogo e dettaglio del servizio.
- Instant booking e booking su richiesta.
- Guest checkout e verifica dello stato.
- Flussi provider e controllo amministrativo.
- Struttura per hotel, referral e attribution.
La complessità rimandata
- App native, loyalty, wallet e social layer.
- Carrello multi-provider e dynamic pricing.
- Venti città e decine di categorie.
- PMS, channel manager o CRM alberghiero.
- Pagamenti live senza Core e verifiche operative.
07 · La misurazione
Il valore del sistema emerge quando contenuto, partner e transazione restano distinguibili.
RivieraOS è stato pensato per sapere non soltanto quante prenotazioni iniziano, ma quali arrivano davvero all’erogazione. Per questo la metrica guida è il Completed GMV: il valore dei servizi completati, non il semplice volume di checkout o richieste aperte.
Visita, service view, avvio booking, pagamento e completamento.
Fonte, campagna, contenuto MaisonEmy, hotel e referral commerciale.
Valore concluso, refund rate, categoria, provider e destinazione.
La separazione tra marketing attribution e commercial referral evita una confusione comune: un contenuto può generare attenzione senza avere diritto a una quota economica; un hotel può attribuire una prenotazione e modificare lo split. Entrambi creano valore, ma in modi diversi e quindi devono essere misurati diversamente.
08 · Le lezioni trasferibili
Che cosa RivieraOS dimostra del metodo ReggianiService.
- Prima il confine, poi la scala.
Una destinazione e quattro categorie producono domande più utili di una piattaforma già estesa ma impossibile da leggere.
- Il modello economico deve entrare nell’architettura.
Referral, split, ledger e rimborsi non possono essere aggiunti alla fine come semplice reportistica.
- Ogni utente vede il proprio prossimo passo.
La complessità centrale non deve diventare complessità dell’interfaccia.
- La demo deve dichiarare i propri limiti.
Simulare un flusso è utile; presentare come reale un pagamento o un risultato non verificato distrugge fiducia.
- I dati servono a decidere dove crescere.
Categoria, fonte e Completed GMV indicano se ampliare il catalogo, coinvolgere hotel o investire nella distribuzione editoriale.
RivieraOS mostra il tipo di lavoro che ReggianiService intende portare nei progetti digitali: definire il compito del prodotto, ridurre il primo perimetro, separare le responsabilità tecniche e costruire una base che possa essere misurata prima di essere ampliata.
Materiali analizzati
Il caso studio è costruito sui documenti interni RivieraOS del progetto del 11 agosto 2026: contesto master, addendum dell’architettura pagamenti e brand specification “Clean Coastal Tech”. Le affermazioni sullo stato sono limitate alla V0 e alle funzioni documentate.
