IL PROBLEMA
Quando ogni reparto usa uno strumento diverso, il ristoratore deve ricostruire il quadro: chi arriva, cosa serve, quali scorte mancano e da dove provengono i costi.
ESTRO / OspitaECOSISTEMA AI
4.300Prenotazioni
gestite in 9 mesi
gestite in 9 mesi
0Errori di
sovrapposizione
sovrapposizione
Il sistema operativo
del locale
Prenotazioni, persone, menu, magazzino e amministrazione: il lavoro del ristorante dentro un sistema condiviso.
Una sala piena.Un lavoro che fila.
IDEATO DA ALBERTO COSTA LUNGA01 — 04 / ESTRO TECHNOLOGY
INIZIARE SUBITO
Un unico accesso.
Il tuo ristorante.
Ospita è il sistema integrato per la ristorazione di Estro. Riunisce prenotazioni, sale, clienti, menu, magazzino, personale e raccordi amministrativi in un unico ambiente di lavoro.
CHE COSA ACQUISTI
Un gestionale per il tuo locale, con moduli collegati e viste per ruolo. Sala, cucina, bar e responsabili accedono allo stesso sistema con le informazioni di propria competenza.
DA DOVE PARTIAMO
Mappiamo un servizio reale del ristorante, configuriamo sale, reparti e accessi e definiamo i moduli e i dati da portare nel sistema.
Una tecnologia, un processo, una responsabilità.
Ospita è il gestionale proprietario sviluppato da Estro a partire dalle esigenze di The Family. Nasce dalla sala e si estende al lavoro che la rende possibile: squadre, turni, menu, documenti di acquisto, scorte e raccordi amministrativi. Ogni reparto vede le informazioni e le azioni che gli competono.
COME SI MUOVE IL SISTEMA
La sala cambia.
Il sistema la segue.
Un ristorante è fatto di ambienti che si muovono insieme. Ospita nasce per rendere leggibili i passaggi tra sala, cucina, persone e amministrazione.
SCHEMA ILLUSTRATIVO DEL PROCESSOINGRESSO
Prenotazioni e clienti
Attività dei reparti
Presenze e documenti
OSPITA
DESTINAZIONE
Agenda condivisa
Lavoro coordinato
Raccordi verificabili
01L’idea
Da un’esigenza reale.
«Mi è venuta voglia di costruire un gestionale che riunisse quello che sappiamo fare: processi, dati, interfacce e automazione. Il ristorante è stato il primo punto di incontro. Ospita nasce per dare al ristoratore un unico accesso al lavoro del locale.»
Un ristorante coordina più attività nello stesso momento. La disponibilità di un tavolo non basta a spiegare il servizio; una fattura non è un carico di merce; una presenza lavorata non è un pagamento. Quando questi passaggi vivono in strumenti separati, lo staff ricopia dati e l’amministrazione deve ricostruire la provenienza dei numeri.
Un quadro operativo condiviso, con regole per reparto e una storia verificabile. La proposta è collegare ciò che accade nel locale ai dati necessari per organizzarlo e controllarlo, preservando le differenze fra disponibilità, movimento fisico, costo e pagamento.
02Il prodotto
Che cosa mette in movimento.
Prenotazioni e sala
Agenda, tavoli, fasce e capienze. I controlli vengono applicati dal server e accompagnano creazione, modifica e storico delle prenotazioni.
Persone e turni
Squadre, presenze e accordi economici. Gli extra seguono un’approvazione e il mese conserva la fotografia delle voci confermate.
Menu e magazzini
Bar e cucina hanno viste e responsabilità dedicate. Articoli, documenti e movimenti si collegano al lavoro dei reparti.
Acquisti e controllo
Fatture e note di credito confermate possono alimentare un costo collegato alla fonte. DDT e ordini non diventano una seconda fattura.
Assistente e integrazioni
Il disegno prevede Ettore per informazioni e prenotazioni via conversazione. La beta documentata distingue richiesta e conferma; il collegamento operativo all’agenda è uno sviluppo separato.
A chi serve
- Ristoranti, circoli e locali che coordinano sala, bar e cucina.
- Gestori che vogliono superare fogli separati senza perdere le proprie regole.
- Organizzazioni che cercano un gestionale adattabile, con ruoli e moduli sviluppati per fasi.
UN CICLO CONCRETO
Che cosa succede,
passo dopo passo.
Inizia il servizio
Una prenotazione porta con sé persone, orario e regole della sala. Lo staff deve leggere il lavoro dal proprio ruolo, con le informazioni utili al servizio.
I reparti condividono il quadro
Menu, magazzino e presenze aggiungono il contesto operativo. Il database è comune, mentre accessi e viste rispettano le responsabilità.
L’attività arriva ai conti
Una presenza approvata o una fattura confermata può alimentare il raccordo amministrativo previsto. Fonte, versione e controllo umano rimangono riconoscibili.
03Il metodo
Dal contesto all’azione.
Cinque passaggi. Selezionali per esplorare il processo.
01 / Organizzare
Sale, servizi, tavoli, squadre e permessi.
SCHEMA 02 / IL PUNTO DI CONTROLLO
Un turno previsto
non è una presenza.
Un unico sistema deve collegare le informazioni senza confondere i fatti. Personale e amministrazione rendono evidente questa scelta: pianificare, lavorare e approvare sono momenti diversi.
Il responsabile pubblica il turno
VERIFICA
Il lavoro effettivo viene registrato e verificato
Presenza confermata e approvata
Riepilogo e raccordo nel perimetro previsto
Assenza, variazione o dato da correggere
Eccezione tracciata e verifica del responsabile
Questa separazione permette di confrontare il previsto con ciò che è successo davvero. Una rettifica deve avere un autore e una motivazione, e non riscrivere il turno originale. Per l’imprenditore significa poter leggere un riepilogo conoscendone l’origine, senza scambiare una stima per un pagamento.
04Le evidenze
Il progetto, nei fatti.
Test superati nel rilascio C2
Suite documentata del 24 ottobre 2026, demo Dev 24. Non è un benchmark di carico.
Asserzioni nella stessa suite
Verifiche automatiche applicative, con test su database isolati.
Raccordi amministrativi sviluppati
C1 personale / amministrazione; C2 acquisti / costi. Non equivalgono alla contabilità completa.
DAL CAMPO
Da un bisogno di The Family a una base di prodotto
Il primo nucleo ha affrontato agenda, sale, clienti e accessi. I rilasci successivi hanno esteso il sistema ai reparti e poi ai raccordi economici. In C1, le presenze approvate e gli accordi alimentano compensi verificabili; le annotazioni dei pagamenti restano separate. In C2, la fattura confermata viene collegata a una registrazione amministrativa unica: se cambia la fonte, il sistema segnala la riconciliazione invece di riscrivere silenziosamente il costo. È questa continuità, dall’attività alla sua origine, a trasformare una raccolta di schermate in un prodotto.
01 / IL PROCESSO
Qualità operativa
Coerenza delle disponibilità, accessi corretti, assenza di duplicazioni e riconciliazione delle fonti.
02 / IL RISULTATO
Lettura del servizio
Prenotazioni, presenze e dati economici rimangono grandezze distinte, collegate ai fatti che le hanno generate.
DENTRO IL PROGETTO
Un ristorante non è
una sola agenda.
Ospita nasce guardando il locale come un’organizzazione: nello stesso momento qualcuno accoglie, qualcuno prepara, qualcuno compra e qualcuno deve tenere insieme il quadro.
01Sala e prenotazioni
+
Agenda, vista sala e timeline rispondono a domande diverse: chi arriva, dove può sedersi e come si sovrappongono i servizi.
Il progetto distingue una richiesta da una prenotazione confermata e una prenotazione da una visita completata. Anche la capacità deve rispettare gli intervalli: sommare tutti i tavoli della giornata non racconta quanti posti sono occupati nello stesso momento. Configurazioni, stati e controlli server rendono questi passaggi leggibili.
02Cucina e bar: autonomia e coerenza
+
Due configuratori e due responsabilità, con un menu attivo condiviso da chi serve ai tavoli.
Cataloghi, ingredienti, ricette, formati e prezzi vivono nel reparto pertinente. Le versioni in bozza permettono di lavorare senza cambiare il menu già pubblicato. Costo teorico di una ricetta e vendite effettive restano informazioni diverse: il collegamento alla cassa richiede una fonte e una mappatura esplicite.
03Le persone prima degli account
+
Una persona può lavorare nel locale senza dover diventare un utente amministrativo del software.
Anagrafica, reparti e mansioni descrivono il lavoro; l’account descrive l’accesso. Il calendario collega disponibilità, turni e copertura. Nel percorso sviluppato, pianificato, effettivo e approvato sono stati separati: una presenza non nasce automaticamente perché esiste un turno. Gli accordi economici rimangono riservati.
04Magazzino e acquisti
+
Bar e cucina hanno viste proprie, ma i passaggi di merce e documenti devono poter essere ricostruiti.
L’impostazione collega articoli, unità, fornitori, carichi e verifiche agli originali. Una consegna fisica e una fattura raccontano fatti differenti. Nel raccordo C2 una fattura o nota di credito confermata può generare una sola registrazione di costo collegata: DDT e ordini non diventano una seconda fattura.
05Direzione e amministrazione
+
Il quadro del locale si legge attraverso definizioni condivise, non soltanto attraverso un totale in dashboard.
La dashboard sviluppata distingue coperti prenotati e serviti, prime visite e ritorni. I raccordi del personale e degli acquisti conservano la provenienza dei valori. Se una fonte cambia, il sistema segnala la riconciliazione: una modifica operativa non deve riscrivere silenziosamente la storia economica.
06Un prodotto oltre The Family
+
The Family è il primo cliente: il sistema deve poter seguire le regole di altri ristoranti.
La scelta di Alberto è separare marchio del prodotto, identità del locale, sedi e ruoli. Cambiare ristorante significa configurare processi e accessi, verificare i dati da importare e concordare le integrazioni. Il primo locale fornisce casi reali da cui costruire un nucleo riutilizzabile.
05Sotto la superficie
Come è costruito.
01
Applicazione Laravel con database dedicato, distinta da EstroCore e dagli altri gestionali.
02
Controlli server su appartenenze, organizzazione, sede e ruolo; il menu visibile non è l’unica protezione.
03
Transazioni, revisioni e chiavi di richiesta per controllare concorrenza e doppi invii nei percorsi documentati.
04
Fonti economiche con versione, fotografia e storico; riconciliazione esplicita dopo una modifica.
05
Rilascio per tranche, backup e prove MariaDB su ambiente QA distinto dalla demo condivisa.
SCHEMA 03 / LA CATENA DELLE RESPONSABILITÀ
Lo stesso locale.
Responsabilità diverse.
Sala, cucina e bar lavorano nello stesso servizio ma non hanno le stesse necessità. Ospita mantiene il quadro comune e organizza le viste in funzione del ruolo.
| Ruolo / livello | Riceve | Lavora su | Consegna |
|---|---|---|---|
| 01Sala | Prenotazioni, tavoli e menu attivo | Accogliere e seguire il servizio | Stato della sala riconoscibile |
| 02Cucina e bar | Cataloghi e informazioni del reparto | Organizzare prodotti, scorte e squadra | Un riferimento operativo per il servizio |
| 03Direzione e amministrazione | Presenze approvate e documenti confermati | Verificare raccordi e anomalie | Lettura del locale collegata alle fonti |
La mansione operativa e l’account non coincidono. Un collaboratore può appartenere al personale senza ricevere accesso amministrativo; un responsabile può lavorare sul proprio reparto senza vedere gli accordi economici di tutti. Questa logica rende il gestionale adattabile senza trasformare ogni utente in un amministratore.
06L’evoluzione
Un nucleo reale. Una direzione chiara.
Oggi
- Demo Dev 24 documentata: prenotazioni, moduli di reparto e raccordi C1/C2.
- Permessi distinti per le informazioni economiche e operative.
- Filtri, navigazione e controlli responsive verificati nei collaudi descritti.
Il prossimo passo
- Ricavi giornalieri, scadenze, competenza e liquidità, budget e analisi avanzata.
- Importazione assistita dello storico e riconciliazione dei dati del locale.
- Collegamento di Ettore a disponibilità ed esiti reali di prenotazione.
- Tablet/comande, POS, cassa fiscale e stampanti: cicli futuri, non funzioni incluse nel rilascio descritto.
Come siamo arrivati qui.
Le tappe documentate e la direzione del prossimo sviluppo.
22 OTT 2026
Agenda, sale e ruoli
Il primo nucleo organizza prenotazioni, clienti e accessi del locale. Ettore viene descritto come beta distinta dal gestionale.
24 OTT · C1
Dalle persone all’amministrazione
Presenze approvate e accordi diventano la base di compensi verificabili, separati dalle annotazioni dei pagamenti.
24 OTT · C2
Dagli acquisti ai costi
Il rilascio Dev 24 collega i documenti confermati alle registrazioni amministrative. La suite arriva a 488 test e 5.431 verifiche.
PROSSIMA FASE
Allargare il perimetro del locale
Importazione dello storico, analisi economiche e collegamento di Ettore agli esiti reali, da definire e collaudare.
Edizione del 30 ottobre 2026. Le implementazioni si valutano e si collaudano sul contesto del cliente.
07La potenzialità
Dai un ordine di grandezza al lavoro.
Un simulatore per discutere volumi e priorità con il team. Modifica le ipotesi: i numeri descrivono uno scenario, separato dai risultati del progetto.
Volume × minuti ÷ 60. Carico manuale teorico: non risparmio misurato né capacità garantita.
08La collaborazione
Che cosa portiamo nella tua azienda.
- Analisi del servizio reale e delle regole del tuo locale.
- Configurazione di sale, servizi, squadre e accessi.
- Moduli operativi scelti insieme e percorso di importazione dei dati.
- Controlli e raccordi amministrativi nel perimetro concordato.
- Formazione per staff e responsabili, collaudo e piano di evoluzione.
01 / Analisi02 / Configurazione03 / Collaudo04 / Adozione
COSA CAMBIA NELLA TUA AZIENDA
La tecnologia entra
nel lavoro delle persone.
Per il ristoratore
Un punto di osservazione comune per servizio, persone e dati del locale, con meno ricostruzioni tra fogli e applicazioni.
Per i responsabili
Autonomia sul proprio reparto, disponibilità e turni leggibili, confini di accesso coerenti con il ruolo.
Per chi lavora al servizio
Le informazioni utili nel momento giusto: sala, menu attivo, turni pubblicati e stato delle attività.
UNO SCENARIO DI ADOZIONE
Una serata si prepara prima dell’arrivo degli ospiti: prenotazioni e aperture aiutano a leggere il servizio, i responsabili organizzano la squadra e il menu attivo dà un riferimento alla sala. Dopo il servizio, le presenze vengono verificate e i raccordi amministrativi mantengono la fonte. È uno scenario di adozione da configurare sul locale, non la dichiarazione che tutte le integrazioni esterne siano già attive.
Lavorare con Alberto e il team Estro significa partire dal processo, scegliere il primo perimetro utile, costruirlo e affiancare le persone nell’adozione. Integrazioni, responsabilità e criteri di successo vengono definiti insieme.
SCHEMA 04 / IL CICLO DI ADOZIONE
Dal servizio di oggi
alle scelte di domani.
L’adozione di un gestionale cambia il modo di osservare il locale. Il confronto utile parte da dati definiti allo stesso modo: richieste, prenotati, serviti, turni e presenze.
Preparare
Leggere servizio, prenotazioni e copertura della squadra.
Lavorare
Usare le viste del reparto e registrare gli esiti pertinenti.
Verificare
Confrontare presenza, documenti e riepiloghi con le loro fonti.
Decidere
Rivedere regole e organizzazione sulla base dei riscontri.
È il modello operativo che proponiamo di costruire con il ristoratore. Non implica che cassa, paghe o ogni fonte esterna siano già collegate. Il perimetro viene scelto per rendere utile il primo ciclo e ampliarlo mantenendo definizioni, responsabilità e storico.
RIFLESSIONI DI PROGETTO
Alberto Costa Lunga
Ideazione e direzione
Volevo unire ciò
che stavamo costruendo.
Ospita per me è stato un punto di incontro. Avevamo già iniziato a lavorare su agenti, dati e automazioni; mi è venuta voglia di dare a queste competenze la forma di un gestionale. Un ristorante rende subito visibile il problema: tante persone lavorano insieme, ma ognuna vede un pezzo diverso della giornata.
Le richieste su The Family mi hanno portato a insistere su sala, bar e cucina come ambienti distinti. Un responsabile deve poter organizzare la propria squadra senza perdere il quadro comune. Allo stesso tempo chi lavora durante il servizio deve trovare poche azioni chiare, senza doversi trasformare in un esperto di software.
È il tipo di lavoro che voglio portare ai clienti di Estro: partire dall’organizzazione reale, entrare nelle eccezioni e costruire un sistema che segua le responsabilità. Il software prende valore quando le persone riescono a usarlo per lavorare insieme.
Alberto Costa Lunga
09Le domande
Prima di partire.
È un software di cassa o un motore paghe?+
Il rilascio documentato non include POS o cassa fiscale e non genera cedolini. Presenze, compensi, costi e pagamenti restano fatti distinti; il gestionale affianca il lavoro dell’amministrazione e dei consulenti.
Ettore può già confermare i tavoli?+
La beta descritta è una dimostrazione interna: risponde alle informazioni e raccoglie richieste senza inventare posti liberi. La conferma automatica richiede il collegamento e il collaudo con Ospita.
I test dimostrano che supporta qualunque volume?+
No. Verificano comportamenti applicativi nel perimetro della suite. Per stimare utenti, prenotazioni contemporanee e tempi di risposta servono prove di carico sul contesto reale.
Si può adattare al nostro locale?+
È il modello di servizio proposto: nucleo comune e configurazione dei processi, con sviluppi progressivi. Importazioni, hardware e integrazioni si definiscono dopo l’analisi.
UN UNICO ECOSISTEMA
Il contesto collega ogni prodotto.
Radar Riconoscere i segnali del mercato.Eva Dare continuità alla relazione.Ospita Coordinare il lavoro del locale.EstroCore Rendere consultabile la conoscenza.
È la direzione progettuale di Estro: ricerca, relazione, operatività e conoscenza condividono una logica. I collegamenti tra i prodotti si progettano e si collaudano per ciascuna implementazione; questa mappa non attesta integrazioni già complete.
ESTRO / Ospita
Facciamolo lavorare
nel tuo contesto.
Partiamo da un servizio del tuo locale, dalle sue regole e dai passaggi che oggi fate due volte.
Parla con EstroAlberto Costa LungaIdeazione e direzione · Estro Agency
NOTE DI PROGETTO / EDIZIONE 30.10.2026
- Ospita — prima demo e ruoli/reparti, 22 ottobre 2026.
- The Family — Ettore su Respond.io, beta del 22 ottobre 2026.
- Ospita — C1 personale e amministrazione, Dev 23, 24 ottobre 2026.
- Ospita — C2 acquisti e amministrazione, Dev 24, 24 ottobre 2026.
Le metriche si riferiscono ai collaudi e ai periodi indicati. Il percorso completo dipende dal perimetro concordato.