In sintesi: quale problema affronta 2Gem App?
2Gem App è un CRM operativo su misura per gestire una rete di farmacie e schermi Ledwall. Il progetto collega anagrafiche, contratti, referenti, programmazione dei contenuti, campagne pubblicitarie, segnalazioni e interventi tecnici. Sei profili operativi accedono a percorsi differenziati: amministrazione, consulenti, farmacie, tecnici, commerciali e agenti.
Il lavoro di sviluppo ha riguardato anche il passaggio dalla precedente soluzione Glide a una base applicativa web e mobile, la conservazione delle relazioni tra dati, le autorizzazioni, le notifiche e la distribuzione degli aggiornamenti. Il risultato descritto qui è un insieme di funzioni e flussi riscontrabili nel progetto: non una stima di fatturato o di ore risparmiate.
Per chi sta valutando un CRM e automazioni su misura, il punto interessante è proprio questo: la scheda cliente è soltanto l’inizio. Il sistema deve accompagnare quello che succede dopo la vendita, quando più persone devono mantenere un servizio nel tempo.
Il problema di fondo: vendere un servizio significa poi mantenerlo
Uno schermo installato in farmacia non conclude il lavoro. Occorre sapere quale contratto lo riguarda, chi segue la relazione, quali caratteristiche tecniche ha, quali contenuti devono essere preparati e se esiste una richiesta ancora aperta. Se gli schermi sono più di uno, le stesse domande devono avere una risposta distinta per ciascuno.
È qui che un’anagrafica isolata non basta. Un consulente deve sapere chi contattare; la farmacia deve riconoscere lo schermo su cui chiede una modifica; chi prepara i contenuti deve distinguere il lavoro pronto da quello in attesa; l’amministrazione deve collegare il servizio alla relazione contrattuale; il tecnico deve capire a quale installazione si riferisce un problema.
Il bisogno affrontato da 2Gem non era quindi aggiungere un’altra lista di contatti. Era rappresentare in un unico ambiente relazioni e responsabilità che appartengono allo stesso servizio, ma vengono gestite da persone diverse. Questa ricostruzione deriva dai requisiti e dai flussi del progetto, non da una testimonianza attribuita al cliente.
Da Glide a un’applicazione con una propria struttura
La documentazione di sviluppo identifica il passaggio dalla precedente soluzione Glide come uno degli obiettivi centrali. Migrare un gestionale esistente significa portare con sé più delle righe di una tabella: bisogna preservare i collegamenti che permettono alle persone di lavorare.
Una farmacia può essere collegata a un referente, a uno o più schermi, a contratti e a uno storico di palinsesti. Se la migrazione conserva le singole schede ma perde una relazione, l’interfaccia può sembrare completa mentre il percorso operativo si interrompe. L’utente vede il cliente, ma non trova lo schermo o la richiesta giusta.
Il progetto comprende per questo strumenti amministrativi di importazione e sincronizzazione, funzioni server dedicate e migrazioni del database. Le importazioni sono organizzate per tabelle e processi tracciabili. Lo storico legacy viene distinto dalle attività correnti, con interventi documentati sulla gestione dei duplicati.
Il vantaggio architetturale è poter affrontare il passaggio per parti verificabili: dati, relazioni, autorizzazioni e percorsi utente. Non equivale a dichiarare che qualsiasi archivio esterno possa essere migrato automaticamente o senza controlli.
Il modello dati segue il servizio, non soltanto il cliente
Nel progetto, anagrafica commerciale, referente che accede, farmacia, schermo, contratto e palinsesto sono concetti collegati ma non intercambiabili. È una distinzione decisiva quando una stessa relazione commerciale comprende più installazioni o più persone.
La farmacia rappresenta il contesto del servizio. Lo schermo ha caratteristiche proprie e una propria programmazione. Il referente identifica la persona autorizzata a consultare quel contesto. Il contratto conserva la relazione amministrativa. Le richieste e le attività tecniche devono tornare a questi riferimenti senza affidarsi soltanto a descrizioni testuali.
Un esempio di progettazione concreta riguarda le email. Un indirizzo usato come contatto commerciale non viene trattato automaticamente come identità di accesso. Il progetto distingue l’account del referente dalle informazioni di contatto e include una vista amministrativa per verificare gli accessi delle farmacie. Per l’assistenza questo significa poter rispondere alla domanda «con quale account si accede?» senza confonderla con «a chi scriviamo?».
Sei profili: perché una dashboard uguale per tutti non basta
Amministrazione, consulenti, farmacie, tecnici, commerciali e agenti partecipano allo stesso sistema con responsabilità differenti. Il progetto prevede percorsi e controlli di ruolo, non soltanto etichette accanto al nome dell’utente.
Per l’amministrazione servono viste trasversali, anagrafiche, contratti e strumenti di gestione. Per il consulente conta il lavoro sulla rete di competenza. La farmacia deve orientarsi tra i propri schermi, i palinsesti e le comunicazioni. Il tecnico deve accedere alle attività pertinenti. Commerciali e agenti hanno esigenze collegate alla relazione commerciale e alle funzioni autorizzate.
Queste differenze riguardano anche ciò che non deve essere mostrato. Gli aspetti economici delle campagne, per esempio, richiedono un perimetro amministrativo; una schermata destinata alla farmacia non deve diventare una finestra sull’intera organizzazione.
Il frontend usa menu e route coerenti con il ruolo. Il backend utilizza autenticazione, controlli server e regole di accesso alle righe del database. Nascondere un pulsante rende più ordinata l’interfaccia; verificare il permesso sul dato è un compito distinto. Nel caso 2Gem sono presenti entrambi i livelli.
Più schermi nella stessa farmacia: un dettaglio che cambia l’esperienza
Dire «il palinsesto della farmacia» può essere ambiguo quando la farmacia ha più Ledwall. Uno schermo può avere orientamento o risoluzione diversi da un altro. Anche la programmazione e le richieste devono rimanere associate al dispositivo corretto.
La navigazione sviluppata per il profilo farmacia include un selettore degli schermi, l’evidenza dello schermo corrente e informazioni su tipo, orientamento e risoluzione. La versione mobile organizza l’accesso attraverso voci come Schermi, Panoramica, Cambia e Storico.
Il percorso mantiene il contesto anche entrando nel dettaglio di un palinsesto. Non è un intervento puramente estetico: quando si passa da una lista a un dettaglio e poi si torna indietro, perdere la selezione può portare a leggere o modificare l’elemento sbagliato. Conservare quel riferimento è parte del funzionamento del gestionale.
Sono documentati inoltre adattamenti alle aree sicure dell’iPhone. In un’app operativa usata da telefono, una barra coperta dall’interfaccia del dispositivo può rendere difficile proprio l’azione più frequente.
Il ciclo dei palinsesti: rendere visibile la prossima azione
Il palinsesto non è trattato soltanto come un file da caricare. È un’attività che attraversa contatto, raccolta delle richieste, lavorazione, caricamento e gestione delle anomalie. Il sistema comprende viste per il lavoro da caricare, i casi problematici, lo storico e il controllo delle scadenze.
Il bisogno operativo è distinguere situazioni che, in una lista generica, rischiano di apparire uguali. Un contenuto può essere in attesa delle indicazioni della farmacia, pronto per il caricamento o bloccato da un problema. Il responsabile deve capire la prossima azione senza ricostruire ogni volta l’intera conversazione.
Le richieste di modifica possono includere allegati e restano collegate al palinsesto. Il progetto comprende anche meccanismi di blocco e ripresa delle richieste. Una pausa operativa non deve obbligare a perdere il contesto o a ricreare il lavoro da zero.
La schermata d’archivio riportata più avanti mostra una parte di questa logica: date e stati sono leggibili direttamente nella lista. Non dimostra da sola tutte le automazioni del sistema; rende però visibile il modo in cui l’interfaccia espone lo stato del lavoro.
Le catture del gestionale online del 10 settembre 2026 mostrano inoltre la panoramica aggregata e i controlli attuali dei palinsesti: ricerca, anno, grafico e intervallo di date. Gli elenchi nominativi sono esclusi direttamente dalle immagini. I contatori documentano ciò che l’interfaccia mostrava in quel momento, non risultati economici né una verifica indipendente dei dati.
Un esempio completo: dalla richiesta della farmacia alla presa in carico
Consideriamo un esempio illustrativo, senza riferimenti a clienti reali: una farmacia con due schermi deve aggiornare i contenuti di uno solo dei dispositivi. Il percorso riunisce funzioni documentate nel progetto; non è il resoconto di una transazione osservata durante questa revisione.
- La farmacia accede al proprio ambiente e seleziona lo schermo interessato.
- Consulta il palinsesto e apre una richiesta di modifica, con gli allegati necessari.
- Il personale autorizzato ritrova la richiesta nel contesto della farmacia e del palinsesto.
- Il lavoro viene seguito attraverso le viste operative, distinguendo richieste e anomalie.
- Al completamento, il caricamento viene registrato attraverso il flusso dedicato.
- La notifica al consulente ha un esito separato, visibile e gestibile.
Il valore del collegamento è evitare che il passaggio di mano diventi un nuovo inserimento scollegato. Il riferimento allo schermo e al palinsesto accompagna la richiesta, invece di essere affidato alla memoria di chi ha letto il primo messaggio.
Salvare il lavoro e inviare un’email sono due risultati diversi
Una delle scelte più concrete emerge dal flusso che segna un palinsesto come caricato. Il codice distingue il completamento dell’operazione dall’esito della notifica. La risposta può indicare notifica inviata, già inviata, saltata oppure fallita.
Questa separazione evita un messaggio ambiguo. Se il caricamento è stato registrato ma manca un destinatario valido, l’interfaccia non deve dire semplicemente che tutto è fallito. Deve chiarire che il palinsesto è caricato e che la notifica non è partita. Allo stesso modo, una notifica già inviata non richiede di presentare l’operazione come un nuovo invio.
Per chi lavora significa sapere che cosa controllare e che cosa eventualmente riprovare. Per chi sviluppa significa progettare stati distinti, risposte server e messaggi coerenti, non collegare alla stessa icona verde eventi che possono avere esiti differenti.
La logica è importante nei gestionali con integrazioni: il servizio email può avere un problema mentre il database ha già registrato correttamente l’azione. Nel caso 2Gem questa distinzione è riscontrabile nel codice del flusso, non soltanto descritta come principio generale.
Campagne, segnalazioni e interventi: il lavoro oltre il palinsesto
La piattaforma comprende anche campagne pubblicitarie con farmacie coinvolte e informazioni amministrative collegate. Richieste di fattura, pagamenti e compensi appartengono a un ambito diverso dalla semplice consultazione del contenuto sullo schermo e vengono trattati con autorizzazioni dedicate.
Segnalazioni e interventi coprono invece il lato tecnico del servizio. Il sistema offre pagine di lista e dettaglio e riferimenti alla farmacia, ai responsabili, al tipo di attività e allo stato. Il problema segnalato non rimane un messaggio privo di collegamenti: può essere consultato nel contesto operativo pertinente.
Chat, notifiche e indicatori di messaggi non letti completano il passaggio di informazioni tra profili autorizzati. La comunicazione non sostituisce i dati strutturati dell’attività: li affianca. Avere il testo di una conversazione è utile; sapere a quale richiesta e a quale farmacia si riferisce è ciò che lo rende utilizzabile nel lavoro quotidiano.
Assistenza amministrativa senza agire al posto della farmacia
Nel progetto è presente un’anteprima diagnostica che permette all’amministratore di vedere il contesto del profilo farmacia. La sessione resta quella amministrativa; il sistema applica il riferimento della farmacia selezionata e limita l’anteprima alla consultazione.
La necessità è semplice: per aiutare un utente occorre capire che cosa vede. La soluzione non deve però trasformare l’assistenza in un accesso che invia messaggi o richieste a suo nome. In questa modalità invii e modifiche sono disabilitati e sono previsti eventi di audit dell’anteprima.
È un esempio del lavoro meno visibile in una presentazione commerciale, ma importante in un prodotto mantenuto nel tempo. La progettazione riguarda anche diagnosi, responsabilità e uscita ordinata dalla modalità di supporto.
L’architettura: interfaccia, dati, funzioni server e app mobile
Il frontend è sviluppato con React e TypeScript, usa Vite, React Router, TanStack Query e componenti Tailwind/shadcn. Le pagine rappresentano i diversi contesti di lavoro; i dati e le operazioni condivise non vengono trattati come semplici elementi grafici.
Il backend si basa su Supabase con PostgreSQL, autenticazione, storage, migrazioni SQL e funzioni server. Qui trovano posto controlli autorizzativi, importazioni e flussi che non devono dipendere unicamente dal browser dell’utente.
La base web è integrata con Capacitor per Android e iOS. Il progetto comprende anche un meccanismo di aggiornamento delle risorse web tramite Capgo, con gestione delle versioni e rollback. Le funzioni native, incluse le notifiche push, restano separate da questo meccanismo.
La distinzione conta nella manutenzione: aggiornare le risorse web non equivale ad aggiungere qualsiasi capacità nativa senza una nuova build. Il caso documenta questa architettura, non certifica la disponibilità attuale di ogni versione sugli store né sostituisce un collaudo dei dispositivi.
Che cosa è stato realizzato, e come misurarne il valore
Le evidenze raccolte consentono di descrivere risultati funzionali: un ambiente multi-ruolo, relazioni tra contratti e servizio, gestione multi-schermo, ciclo dei palinsesti, richieste con allegati, campagne, assistenza tecnica, strumenti di migrazione e percorsi web/mobile.
Il beneficio operativo perseguito è rendere riconoscibili contesto, responsabilità e stato del lavoro. È diverso da sostenere che siano già stati misurati un risparmio percentuale o un incremento di fatturato. Per questo il caso non attribuisce a 2Gem indicatori economici non documentati.
Una valutazione quantitativa successiva potrebbe confrontare, su periodi omogenei, tempo tra richiesta e presa in carico, palinsesti in attesa, richieste riaperte, notifiche non consegnate e durata degli interventi. Sono criteri di misurazione proposti, non numeri rilevati né dashboard che si dichiarano già presenti.
La profondità del progetto emerge già dalla relazione tra i moduli: non nove funzioni indipendenti, ma un servizio che attraversa dati commerciali, attività operative, comunicazioni e assistenza.
A chi serve un progetto di questo tipo?
Il caso 2Gem è pertinente per aziende che gestiscono reti di clienti, installazioni distribuite e attività ricorrenti dopo la vendita. Il settore specifico è quello dei Ledwall nelle farmacie; il problema organizzativo è collegare persone, contratti, dispositivi e manutenzione del servizio.
Non tutte le aziende hanno bisogno di un CRM personalizzato. Quando il processo è standard, un prodotto esistente può essere sufficiente. Quando invece il lavoro dipende da relazioni specifiche, diversi livelli di accesso, storico da migrare e passaggi operativi non rappresentati bene dagli strumenti disponibili, questi aspetti diventano il centro dell’analisi.
Il mio contributo come sviluppatore è tradurre quel processo in un sistema utilizzabile e mantenibile: modello dati, interfacce, autorizzazioni, integrazioni e gestione delle eccezioni. È questo il livello di lavoro che una semplice immagine della dashboard non può raccontare da sola.
Per approfondire il problema generale consulta la guida ai CRM per farmacie e Ledwall. Per un progetto con esigenze analoghe puoi partire dai servizi di sviluppo software su misura e app aziendali personalizzate.
Metodo e limiti di questa ricostruzione
Approfondimento curato da Fabio Leanzi e revisionato l’8 settembre 2026 usando documentazione operativa, struttura applicativa e codice del progetto 2Gem. Tra le evidenze: gestione dei ruoli e dell’anteprima amministrativa, filtro della dashboard per referente, flusso di caricamento dei palinsesti e relativi esiti di notifica.
Non sono stati interrogati database di produzione per scrivere questo caso. Non vengono pubblicati dati di clienti, contratti, credenziali, importi o conversazioni. La cattura conservata nel repository è distinta dalle funzioni verificate nel codice e non viene presentata come collaudo live di settembre 2026. Gli esempi dichiarati illustrativi non rappresentano clienti o transazioni reali.
