Il sito commerciale FullRestaurant: pagine per bisogno, modulo demo, attribuzione, email separate, calendario e gestione delle opportunità.
FullRestaurant: dal sito alla richiesta di demo
Sintesi del progetto
Il sito vetrina FullRestaurant è il sistema commerciale che presenta la piattaforma per ristoranti e accompagna il visitatore dalla prima domanda alla richiesta di una demo. È un progetto distinto dal gestionale utilizzato durante il servizio: qui il lavoro riguarda comprensione dell'offerta, raccolta del contatto, follow-up, attribuzione e gestione delle opportunità.
La soluzione sviluppata comprende pagine dedicate ai problemi del ristoratore, contenuti editoriali, modulo demo, notifiche separate per potenziale cliente e amministrazione, collegamento al calendario e una console per seguire le richieste. Il risultato funzionale è un percorso collegato: la richiesta non termina con un messaggio di ringraziamento, ma diventa un elemento gestibile con stato, provenienza ed esito degli invii.
Il problema: una richiesta non è ancora un'opportunità seguita
Un visitatore può arrivare cercando prenotazioni, delivery, menu digitale o fidelizzazione. Presentargli l'intero prodotto senza un percorso pertinente rischia di aggiungere complessità proprio nel momento in cui sta cercando una risposta specifica. Anche quando compila un modulo, restano domande operative: chi deve ricontattarlo, quale problema aveva, ha ricevuto informazioni, ha aperto il calendario?
Questo pain è una ricostruzione del bisogno a partire dal progetto e dal flusso implementato, non una citazione attribuita a un cliente. La risposta progettuale è separare l'esplorazione del prodotto dalla gestione della richiesta, mantenendo però un collegamento tra le due. È lo stesso principio che guida molti interventi di automazione aziendale: rendere esplicito ciò che succede dopo un'azione, comprese le eccezioni.
Un'architettura commerciale per bisogni diversi
Il sito non si limita alla home. Sono presenti una pagina generale sul gestionale, landing commerciali dedicate e pagine delle singole funzionalità. I percorsi distinguono, per esempio, prenotazioni, delivery e asporto, CRM e fidelizzazione. Il blog offre un ulteriore livello di approfondimento, con collegamenti verso il prodotto e la demo.
La distinzione ha un significato pratico: chi deve capire una funzione non deve per forza leggere una presentazione completa; chi confronta soluzioni ha invece bisogno di contesto più ampio. Alcune vecchie destinazioni sono ricondotte a pagine pertinenti mediante redirect. Non tutte le pagine devono competere per la stessa domanda: l'architettura cerca di attribuire a ciascuna un ruolo riconoscibile nel percorso commerciale.
Dal modulo a una richiesta identificabile
Il modulo raccoglie nome del ristorante, città, recapiti, fascia preferita e messaggio. Al momento dell'invio viene creato un identificativo della richiesta, associato alla sessione e alla provenienza. Queste informazioni vengono salvate prima di avviare il follow-up email.
Questa sequenza è importante: l'invio di una notifica e l'esistenza della richiesta sono due eventi diversi. Se il provider email ha un problema, il contatto già registrato non dovrebbe essere confuso con un modulo mai ricevuto. Lo stato iniziale dei due invii è indicato come in attesa; il sistema conserva poi gli esiti effettivi restituiti dalla funzione che li gestisce. La richiesta rimane così il punto di raccordo del percorso.
Attribuzione senza perdere il contesto
La componente di attribuzione conserva nella sessione informazioni sulla pagina di ingresso, il riferimento di provenienza e i parametri della campagna quando presenti. Gli eventi successivi possono essere collegati allo stesso identificativo del lead. Il modulo non produce soltanto un nome in una lista: mantiene elementi utili a capire quale percorso abbia preceduto la richiesta.
È una base di misurazione, non una promessa di attribuzione perfetta. Un utente può cambiare dispositivo, cancellare i dati del browser o arrivare senza parametri di campagna. Anche la disponibilità di un evento non misura automaticamente il valore commerciale della visita. Il progetto rende osservabili passaggi specifici; la loro interpretazione richiede dati raccolti in un periodo definito e criteri coerenti.
Due email, due esiti indipendenti
La funzione di follow-up prepara un messaggio per il potenziale cliente e una notifica per il team commerciale. Il primo contiene una presentazione coerente di FullRestaurant e il collegamento al calendario; il secondo porta all'amministrazione il contesto necessario a gestire la richiesta. I dati ricevuti vengono normalizzati e verificati prima dell'elaborazione.
I due invii vengono trattati separatamente. Il codice registra se l'email al cliente è riuscita e se la notifica interna è riuscita, anziché restituire un unico successo generico. Questa scelta permette di distinguere un problema di comunicazione esterna da uno di recapito interno. Il sistema registra inoltre gli eventi corrispondenti, così l'amministrazione può riconoscere le richieste che meritano attenzione senza dedurre tutto dalla sola presenza di un contatto.
Il calendario è un passaggio, non una conversione inventata
Dopo l'invio, la pagina di ringraziamento propone il passo successivo. Il collegamento al calendario mantiene continuità con la richiesta e l'apertura può essere registrata come evento dedicato. L'interfaccia distingue anche l'esito dell'email, evitando di descrivere come completata una comunicazione rimasta in attesa.
Aprire il calendario non equivale però ad aver fissato un appuntamento. Nel modello commerciale esiste uno stato dedicato alla demo fissata, separato dall'evento di clic. Mantenere questa distinzione è essenziale per costruire indicatori credibili: richiesta inviata, calendario aperto, demo concordata e cliente acquisito rappresentano fasi differenti. Il progetto offre gli strumenti per distinguerle; non attribuisce automaticamente un risultato economico a un'azione intermedia.
La console commerciale e il lavoro quotidiano
La console raccoglie le richieste e consente di filtrare gli stati: nuova, contattata, demo fissata, acquisita, persa o di test. L'operatore può aggiornare lo stato e salvare note. Accanto alla richiesta sono disponibili informazioni sulla campagna e sugli esiti delle email.
Un dettaglio significativo è la separazione dei contatti di prova dagli indicatori commerciali. Durante sviluppo e manutenzione è normale verificare il modulo; quei test non devono diventare opportunità reali nei numeri del team. L'accesso all'area è inoltre vincolato al ruolo amministrativo nell'interfaccia. La lettura del codice documenta questa organizzazione, ma non sostituisce un audit completo delle autorizzazioni applicate all'ambiente di produzione.
SEO, contenuti e continuità del prodotto
Le pagine dispongono di canonical, metadati social e supporto ai dati strutturati. L'obiettivo è rendere espliciti identità della pagina e rapporto con gli altri contenuti, mantenendo collegamenti utili tra domanda del visitatore, approfondimento e azione commerciale. Questo lavoro tecnico si affianca alla qualità e alla specificità del testo: non la sostituisce.
Nel progetto esiste anche una pipeline editoriale articolo-video con verifiche dedicate. La sua presenza non significa che sia interamente operativa: la documentazione consultata mantiene la pubblicazione video in pausa, in attesa dei requisiti previsti. Va quindi raccontata come componente predisposta e separata dal percorso demo, senza trasformare la quota progettata di contenuti giornalieri in un risultato già osservato.
Integrazioni e compromessi tecnici
Il frontend utilizza React e TypeScript; Supabase gestisce dati e funzioni server. Il provider email è coinvolto nel follow-up, mentre il calendario offre un servizio esterno per la demo. È presente anche un percorso di sottoscrizione con Stripe, distinto dalla semplice richiesta di informazioni.
La scelta di usare servizi specializzati evita di ricostruire pagamento, consegna email o calendario all'interno del sito, ma introduce dipendenze che vanno sorvegliate. Un account disconnesso, un errore di configurazione o una risposta incompleta possono interrompere un singolo passaggio. Per questo identificativi, stati intermedi e messaggi di errore hanno un valore progettuale concreto: permettono di ragionare sul flusso senza ridurlo a “il modulo funziona”.
Risultato documentato e limiti della verifica
Il risultato verificabile nel progetto è l'implementazione di un percorso commerciale collegato, con acquisizione del contatto, attribuzione, follow-up, calendario e console. Questa ricognizione non ha eseguito invii a persone, pagamenti, sottoscrizioni o una nuova prova end-to-end in produzione. Non vengono quindi dichiarati tassi di conversione, ricavi, consegna garantita delle email o incremento della visibilità sui motori di ricerca.
Per valutare il sistema nel tempo servirebbero misure separate: richieste valide, tempi di gestione, demo effettivamente fissate, errori di invio e opportunità concluse. Sono indicatori possibili, non risultati già attribuiti al lavoro. Anche eventuali schermate promozionali del prodotto non sostituiscono una cattura verificata della console con dati di prova.
Quando un progetto simile ha senso
Questo caso è pertinente per chi vende un servizio o un software che richiede spiegazione e confronto, non soltanto un acquisto immediato. Il punto non è aggiungere più pulsanti, ma progettare il passaggio dal contenuto alla relazione commerciale, rendendo riconoscibili responsabilità ed esiti.
FullRestaurant mostra una parte del lavoro di Fabio che rimane spesso invisibile in un sito vetrina: collegare interfaccia, dati, integrazioni ed eccezioni. Puoi esplorare gli altri casi studio oppure parlare del tuo percorso commerciale, partendo dai passaggi che oggi richiedono controlli manuali.
Schermate del progetto
Cattura del 10 settembre 2026 del sito vetrina FullRestaurant. Documenta il sito pubblico sviluppato, non una sessione del gestionale: l’immagine dei dispositivi è un elemento promozionale della pagina e non una nuova cattura delle dashboard. Le promesse commerciali visibili non sono risultati misurati da questo caso studio.