Sintesi del progetto
Sanremo Tourist Card, presentata nell'applicazione come Sanremo On, collega una card digitale a un insieme di servizi territoriali: attività convenzionate, offerte, eventi, luoghi, informazioni utili e strumenti per gli operatori. Il progetto non consiste soltanto nel mostrare un QR sul telefono. Comprende il percorso che porta alla registrazione del turista, alla disponibilità della card e alla sua verifica presso un esercente.
La piattaforma distingue inoltre chi registra i visitatori, chi gestisce un'attività e chi cura l'amministrazione o i contenuti. Il risultato funzionale documentato è un sistema che mette in relazione questi attori, conservando card, scadenze e utilizzi come elementi separati e collegati. La verifica descritta riguarda l'implementazione, non un nuovo collaudo sul territorio.
Il bisogno: collegare esperienza del turista e lavoro degli operatori
Una card territoriale perde utilità se il turista deve cercare convenzioni in un posto, presentare una tessera in un altro e chiedere ogni volta se il vantaggio è valido. Dal lato dell'esercente, una tessera senza strumenti di verifica lascia aperte domande semplici: è attiva, è scaduta, quale offerta riguarda, come si registra il passaggio?
Questo bisogno è ricostruito a partire dalle funzioni implementate, non da un'intervista inventata. La risposta consiste in un percorso comune, con interfacce differenti per ciascun ruolo. Il turista deve trovare informazioni e presentare la card con pochi passaggi; l'operatore deve poterla riconoscere e gestire senza usare la stessa schermata pensata per il visitatore.
Gli attori e le responsabilità
Nel progetto sono previsti ruoli distinti per esercente, registratore, operatore, amministratore generale ed editor. Le route dell'area operativa applicano accessi differenziati: non tutti i profili vedono gli stessi strumenti. Il sito pubblico mantiene invece la consultazione di attività, offerte, eventi e luoghi.
La separazione riflette una rete territoriale reale come problema organizzativo, senza presumere che tutti i suoi membri abbiano già adottato ogni funzione. Chi accoglie il visitatore può contribuire all'attivazione della card; l'esercente gestisce l'utilizzo collegato alla propria attività; l'editor lavora sui contenuti. È una scelta che rende il prodotto più articolato di una semplice directory e chiarisce dove inizia e termina la responsabilità di ciascuna interfaccia.
Registrazione collegata a un operatore
L'attivazione non viene presentata come un modulo anonimo aperto senza contesto. Il percorso utilizza un link o un riferimento che permette di risalire all'operatore o alla struttura. Quando mancano entrambi, l'interfaccia invita a richiedere il collegamento; il backend verifica a sua volta di poter risolvere un operatore valido.
Il modulo separa l'accettazione richiesta per proseguire dal consenso marketing facoltativo e adatta i testi alla lingua prevista dal flusso. Il sistema controlla inoltre le email appartenenti agli account staff, evitando di trattarle come normali registrazioni turistiche. Sono dettagli che aiutano a mantenere ordinato il modello: un account operativo e una persona che usa la card non hanno lo stesso ruolo, anche quando transitano dalla stessa piattaforma.
Una card con identità, stato e scadenza
La card viene collegata al turista e all'operatore che ne ha consentito la registrazione. Ha un token QR, uno stato di attività e una scadenza. La durata è ricavata dalla configurazione, così non deve essere riscritta in tutte le schermate quando cambia la regola del servizio.
Il recupero di una persona già presente non genera necessariamente una nuova card. Se ne esiste una ancora attiva e valida, il flusso può restituire quella; se è scaduta, viene gestita l'emissione successiva. Questa distinzione è importante per non confondere ogni accesso ripetuto con un nuovo visitatore. La card non è quindi soltanto un'immagine, ma un'entità con un ciclo di vita che l'interfaccia rende riconoscibile.
Consultare il territorio senza uscire dal percorso
Attività, offerte, eventi e punti di interesse costituiscono il lato esplorativo della piattaforma. La mappa utilizza coordinate e popup, adattando l'area visualizzata ai punti disponibili. La scheda di un esercente permette di approfondire un'attività invece di lasciare il visitatore davanti a un pin privo di contesto.
Sono presenti anche percorsi per informazioni pratiche, come numeri utili, farmacie di turno, cinema e teatro. Il valore progettuale è la possibilità di raccordare utilità immediata ed esplorazione della città nello stesso ambiente. La presenza di questi moduli non dimostra però che ogni fonte esterna sia aggiornata in tempo reale: la qualità dell'esperienza dipende anche dalla manutenzione dei contenuti e dalle eventuali procedure di importazione.
La verifica della card al banco
L'interfaccia dell'esercente prevede due modalità complementari: scansione del QR con la fotocamera e ricerca del turista. La seconda è importante quando la fotocamera non è disponibile o il visitatore non riesce a presentare il codice nel modo previsto. Un errore di accesso alla fotocamera viene gestito come tale, senza nasconderlo dietro un generico fallimento della card.
Dopo l'identificazione, la schermata distingue card valida, scaduta o non attiva. Per la card valida può essere registrato un utilizzo associato all'esercente e, quando selezionata, a un'offerta. In questo modo il gesto al banco si traduce in una relazione tra oggetti del sistema, non in un semplice contatore scollegato dalle regole del servizio.
Dall'utilizzo alla lettura operativa
Registrare un utilizzo permette di costruire una base osservabile del funzionamento della card. Il sistema aggiorna le informazioni utilizzate dalle viste operative, così il lavoro non termina al momento della scansione. Il collegamento all'offerta consente inoltre di distinguere un passaggio generico dall'uso di una convenzione specifica.
Questo dato va interpretato correttamente. Un utilizzo registrato non certifica una spesa, un incremento del fatturato o una visita che altrimenti non sarebbe avvenuta. Può invece aiutare a descrivere l'adozione del servizio, purché venga raccolto con procedure coerenti. Nel caso studio non vengono attribuiti numeri di utenti, tassi di ritorno o benefici economici non misurati.
Wallet e integrazioni: disponibilità esplicita
Sono implementati collegamenti per Apple Wallet e Google Wallet. L'interfaccia verifica la disponibilità dei rispettivi servizi prima di proporre le azioni. Questo evita di presentare l'aggiunta al Wallet come un semplice pulsante grafico privo di una funzione associata.
L'integrazione ha però requisiti esterni: configurazioni, certificati, asset e, per il percorso pubblico Google, approvazione della classe prevista. Il codice e la documentazione mostrano questi passaggi, ma la ricognizione non ha verificato oggi il salvataggio su dispositivi reali. La piattaforma dispone inoltre di strumenti per esporre a integrazioni selezionate attività, offerte, eventi e luoghi in forma strutturata. È un'interfaccia ai dati territoriali, non una garanzia che qualunque assistente AI li utilizzi o li citi.
Scelte tecniche e gestione delle eccezioni
React e TypeScript compongono l'interfaccia; Supabase supporta dati, autenticazione e funzioni server. Il progetto separa la card, il profilo del turista, l'operatore, le offerte e gli utilizzi. Questa scelta consente di trattare una scadenza, una nuova emissione o un'offerta selezionata senza riscrivere l'intero percorso.
Le eccezioni contano quanto il percorso ideale: link non valido, operatore non risolto, card esistente, card scaduta, fotocamera negata, Wallet non configurato. Gestirle rende il sistema comprensibile quando le condizioni non sono perfette. Non equivale a un audit completo di sicurezza o conformità: autorizzazioni, conservazione dei dati e comportamento delle integrazioni devono essere verificati anche nell'ambiente operativo.
Stato documentato, privacy e limiti
La ricerca ha verificato il codice dei percorsi descritti e la presenza di test dedicati ad alcune validazioni Wallet. Non ha eseguito nuove registrazioni, scansioni, invii o salvataggi su Wallet. I test presenti non vengono presentati come una suite eseguita durante questa analisi, e le informazioni di configurazione non provano automaticamente l'attivazione di ogni servizio esterno.
Per documentare visivamente il prodotto occorre un ambiente di prova con QR non utilizzabili, dati sintetici e assenza di riferimenti identificativi. Una schermata con nome oscurato ma token attivo visibile non sarebbe una prova pubblicabile adeguata. In questa versione non vengono impiegati mockup come evidenza, né viene attribuita al progetto una certificazione normativa.
Cosa mostra questo lavoro
Sanremo Tourist Card illustra un tipo di sviluppo in cui il centro non è la singola pagina, ma la relazione tra persone e organizzazioni. Registrazione, card, consultazione e verifica al banco devono raccontare lo stesso stato senza costringere tutti a usare la stessa interfaccia.
È un approccio applicabile a reti di esercenti, servizi territoriali e programmi di accesso o convenzione, adattando ruoli e regole al contesto. Se stai progettando un servizio che collega utenti e operatori, parliamone: il primo passo è ricostruire il percorso completo, comprese le situazioni in cui oggi qualcuno deve intervenire manualmente.
