Il caso Farmacia Sambuy: sito e app, richieste di appuntamento, invio documenti, chat con lo staff e offerte, con stati e accessi distinti.
Farmacia Sambuy: richieste, appuntamenti e dialogo con lo staff
Sintesi del progetto
Farmacia Sambuy App collega il sito informativo della farmacia a un'area applicativa per servizi, richieste di prenotazione, invio di ricette, messaggi e offerte. Il progetto parte da un'esperienza visuale approvata e la traduce in percorsi collegati a dati e strumenti operativi per lo staff.
La parte pubblica presenta attività e informazioni della farmacia; l'area personale permette di inviare richieste e seguirne lo stato; la console interna riunisce prenotazioni, ricette, conversazioni e promozioni. Il caso documenta questi flussi implementati, senza confondere il software con un sistema di diagnosi, una prescrizione digitale validata o una garanzia di disponibilità dei servizi. È un progetto distinto da una semplice app di promemoria per l'assunzione di farmaci.
Il bisogno: una richiesta deve essere visibile da entrambe le parti
Una farmacia riceve domande, documenti e richieste di appuntamento attraverso canali differenti. Il cliente vuole sapere se il messaggio è arrivato e quale sia il passo successivo; lo staff deve poter vedere cosa è in attesa, cosa è stato gestito e quali informazioni mancano. Senza un percorso condiviso, il contatto successivo spesso serve soltanto a ricostruire quello precedente.
Questo pain è una ricostruzione progettuale basata sulle funzioni sviluppate, non una testimonianza inventata della farmacia. La risposta è rendere ogni richiesta riconoscibile e collegarla a uno stato. Il sistema non cerca di eliminare il rapporto con il personale: offre un punto comune in cui cliente e staff possano orientarsi prima e dopo quel rapporto.
Sito pubblico e area personale hanno compiti diversi
Il sito istituzionale presenta servizi, informazioni, offerte e contenuti dedicati. L'app utilizza un ambiente più operativo, con navigazione pensata per accedere alle funzioni personali. I dati di servizi, orari e promozioni sono letti dalle strutture del progetto, così non devono essere ricostruiti come elementi grafici indipendenti in ogni pagina.
L'autenticazione viene richiesta per i percorsi personali. Lo staff dispone di un accesso distinto, verificato attraverso i ruoli previsti. Separare questi ambienti permette di mantenere semplice la consultazione pubblica senza rendere pubbliche anche conversazioni e richieste. È una differenza funzionale, non soltanto visuale: un'informazione generale e un documento inviato da un cliente non devono seguire lo stesso regime di accesso.
Dalla scelta del servizio alla richiesta di appuntamento
Il percorso dei servizi permette di scegliere una data e uno slot. La disponibilità mostrata tiene conto delle prenotazioni dello stesso servizio e giorno, escludendo quelle cancellate. Prima dell'invio, l'interfaccia verifica che l'orario selezionato non risulti già occupato fra i dati disponibili.
La richiesta viene poi registrata con servizio, data e ora, e vengono avviate le comunicazioni previste per cliente e farmacia. Il modello distingue stato in attesa, confermato, completato o cancellato. È importante non accorciare il significato del processo: salvare una richiesta non equivale necessariamente alla conferma da parte dello staff. La terminologia del caso mantiene questa distinzione anche quando l'interfaccia usa un messaggio sintetico di completamento.
La gestione delle prenotazioni per lo staff
La console interna raccoglie le prenotazioni e permette di aggiornarne lo stato. Il personale può quindi usare la stessa informazione che alimenta il percorso personale, invece di trattare la richiesta come un messaggio isolato. La vista operativa mantiene separata questa attività dalla gestione delle ricette e dalle conversazioni.
Il controllo degli slot è un elemento utile, ma non viene descritto come una garanzia assoluta contro ogni sovrapposizione. Per affermare un blocco transazionale delle prenotazioni concorrenti servirebbe verificare l'intero percorso di scrittura e i relativi vincoli. In questo caso sono accertati lettura degli slot occupati e controllo nel flusso; non una prova di concorrenza eseguita con più utenti contemporaneamente.
Inviare una ricetta senza perderne il contesto
L'area ricette permette di inviare una richiesta con allegato immagine o PDF e di ritrovare gli elementi già trasmessi. Il flusso applica un limite alla dimensione del file, trasferisce il materiale e collega il riferimento alla richiesta dell'utente. La schermata distingue elementi in corso da quelli consegnati.
Il significato è documentale e organizzativo: il cliente trasmette il materiale alla farmacia, che lo prende in carico secondo le proprie procedure. Il caricamento non produce una nuova prescrizione e non rappresenta una validazione automatica del documento. Questa distinzione rende il prodotto più comprensibile e impedisce di attribuire all'interfaccia un ruolo sanitario che il codice esaminato non documenta.
Stati leggibili invece di una casella indistinta
Le richieste relative alle ricette hanno stati distinti: ricevuta, in preparazione, pronta, consegnata o cancellata. L'interfaccia può così mostrare una progressione comprensibile, mentre lo staff aggiorna la lavorazione dalla propria console. Il modello evita di trattare qualsiasi documento caricato come un'attività già conclusa.
Un passaggio di stato è un'informazione operativa, non una promessa autonoma di disponibilità. Per questo il percorso prevede il coinvolgimento della farmacia e comunicazioni dedicate. La qualità dell'esperienza dipende anche dall'uso coerente di questi stati da parte del personale: la tecnologia fornisce la struttura, ma non può conoscere un avanzamento reale se nessuno lo registra o lo conferma attraverso una procedura prevista.
Chat con la farmacia, non consulenza AI
L'app dispone di conversazioni collegate all'utente. Il cliente invia un messaggio, lo staff seleziona la conversazione e risponde con un'identità di farmacia distinta da quella del mittente. I messaggi vengono conservati e riletti attraverso query dedicate, mantenendo il filo del dialogo.
Il percorso verificato è una chat tra persone. Non viene descritto come un assistente che interpreta sintomi, prescrive o fornisce risposte terapeutiche automatiche. Il valore operativo è la continuità: una richiesta e la risposta rimangono nello stesso contesto. Anche la presenza della chat non implica tempi di risposta garantiti o sorveglianza continua; queste aspettative devono essere definite dalla farmacia e comunicate chiaramente nel servizio.
Offerte e contenuti senza separare sito e app
Lo staff può creare e modificare promozioni, gestendo titolo, descrizione sintetica, immagine, collegamento, ordine e attivazione. La parte pubblica legge le offerte previste dal modello. Questo raccordo evita di considerare l'app e il sito come due vetrine da aggiornare sempre con procedure indipendenti.
La gestione editoriale resta importante: un'offerta attiva nel database deve essere corretta per periodo, condizioni e disponibilità. Il software non ricava automaticamente queste informazioni dal magazzino se non esiste un'integrazione specifica verificata. Il caso mostra quindi strumenti di pubblicazione e organizzazione, non una promessa di sincronizzazione universale con tutte le operazioni della farmacia o con sistemi esterni non esaminati.
Documenti e autorizzazioni sono parte del progetto
Il caricamento degli allegati utilizza percorsi collegati all'identificativo dell'utente, con controlli sul formato del percorso e sull'estensione. Per la consultazione sono previste URL firmate a tempo. Le migrazioni del database distinguono i permessi del proprietario della richiesta e quelli dello staff, includendo regole per messaggi, prenotazioni e ricette.
Sono scelte tecniche che mostrano attenzione alla separazione dei dati, ma non costituiscono una certificazione normativa o un audit della configurazione oggi applicata. Per documentare pubblicamente questa parte serve un ambiente isolato con file sintetici: un allegato sanitario reale non diventa pubblicabile soltanto perché la schermata non mostra il nome del cliente. In questa ricerca non sono stati aperti documenti o conversazioni personali.
Stato della verifica e limiti da comunicare
La ricognizione ha verificato implementazione dei percorsi e regole presenti nei sorgenti, senza creare prenotazioni, inviare ricette o mandare email. Una funzione che richiede un invio non dimostra la consegna effettiva della notifica; la presenza di una migrazione non prova da sola che ogni ambiente utilizzi esattamente quella configurazione. Non vengono dichiarati numeri di utenti o riduzioni delle telefonate.
Un limite specifico riguarda i turni: la tabella esaminata copre settembre 2026 e non rappresenta un aggiornamento perpetuo in tempo reale. Il componente deve quindi essere considerato insieme a una procedura di manutenzione e alla gestione dei giorni non coperti. Il caso non presenta quei dati come fonte sempre aggiornata per urgenze né come sostituto delle verifiche necessarie sul servizio territoriale.
Cosa mostra questo lavoro di sviluppo
Farmacia Sambuy App mostra il passaggio da una grafica approvata a un sistema con utenti, ruoli, richieste, allegati, stati e strumenti interni. L'aspetto visivo rimane importante, ma la qualità del lavoro emerge soprattutto nei collegamenti: la richiesta del cliente deve diventare un'attività leggibile per lo staff e ritornare al cliente come informazione comprensibile.
Se il tuo servizio riceve appuntamenti, documenti e messaggi in canali frammentati, parliamone. Uno sviluppo software su misura può partire da quei passaggi, mantenendo chiari i limiti dell'automazione e il ruolo delle persone che prendono le decisioni operative.
Schermate del progetto
Cattura del 10 settembre 2026 dalla sezione pubblica offerte del progetto Farmacia Sambuy. Mostra la pubblicazione delle promozioni, non ricette, pazienti o messaggi riservati. Nome della titolare e telefono sono contatti professionali già pubblici. Prezzi e promozioni appartengono alla data della cattura.