L’agenda degli appuntamenti con possibilità per l’utente di consultare le disponibilità e prenotarsi è uno strumento che serve a tutte le amministrazioni e, bene o male, è facimente standardizzabile visto che le amministrazioni non dovrebbero avere grandi esigenze di “personalizzare” questo servizio.
L’app IO potrebbe essere, con i dovuti sviluppi, un canale di accesso alla prenotazione di appuntamenti.
Cosa serve a mio avviso.
Una applicazione web (con sottostante DB) con front end web per il back office dell’ente e per il cittadino.
Il back office consente all’ente di impostare le caratteristiche degli appuntamenti (durata, orari, giorni disponibili, numero di operatori ecc.) di gestire gli operatori (verosimilmente ogni dipendente che riceve appuntamenti avra’ accesso alla sua area), di gestire figure con profili di autorizzazione intermedie (capoufficio e segreterie che segnano i giorni di indisponibilità di operatori ecc.), di configurare la presentazione delle disponibilità (mostro solo il servizio prenotabili o anche il nome dell’operatore?)
Un set completo di API per interagire col DB e presentare i dati anche da/su frontend diversi.
Una volta che si sono individuate la soluzione applicativa locale e le relative API, si può usare IO (dopo qualche sviluppo) come frontend e interfacciarsi con le agende e i servizi degli enti aderenti, aggiungere l’appuntamento all’agenda del proprio device, magari (anche in seguito) ricevere lla notifica da IO ecc.
Oltre a un buon servizio per il cittadino (punto 3), fornire una applicazione web (punto 1) gratuita a tutte le amministrazioni realizzerebbe un bel risparmio.
Fra l’altro essitono gia’ soluzioni per gestire appuntamenti open source di dimensione internazionale, un adattamento per la p.a. italiana non dovrebbe davvero essere complicato o costoso.
Grazie per i cuoricini… pero’, passando al lato operativo: non c’è nessuno che sa programmare?
Io ho provato la demo online di easyappointments.org che sembra la soluzione che va per la maggior nel mondo.
Ha l’indubbio pro della facilità di installazione, un’interfaccia snella ecc.
Io ho riscontrato dei limiti funzionali che, secondo me, non lo rendono immediatamente utilizzabile in un contesto di p.a. italiana.
Registrazione degli utenti. Non è prevista. Cosa che andrebbe anche bene, ma se si intende aggiungere la registrazione occorre passare da SPID (fondamentale comunque per la successiva integrazione in IO).
1bis. Mi sembra che l’anagrafica degli utenti sia gestita in base all’email. Spiego meglio. Fisso un appuntamento e lascio nome cognome e email. Se fisso un secondo appuntamento con stessa email ma variando nome e cognome, questi ultimi si propagano anche al primo appuntamento.
Esposizione all’utente del nome del “provider” (“fornitore”, employee, impiegato…) del “service” (“servizio”… diciamo tipo di appuntamento). La documentazione invita a usare il nome dell’organizzazione e associarlo a tutti i tipi di appuntamento se si vuole nascondere il nome dell’impiegato (e a mio modo di vedere NON va esposto).
L’uso del nome dell’organizzazione per tutti gli appuntamenti però fa perdere flessibilità nella configurazione.
Le finestre di disponibilità sono associate solo all’impiegato e non anche al servizio. Cioe’, la configuazione prevede:
per il servizio: nome, categoria, durata, persone per volta;
per l’impiegato: quali servizi eroga e l’orario di lavoro.
Non sembra quindi possibile dire che l’impiegato A si occupa al mattino del servizo 1 e al pomeriggio del servizio 2. O dire che in un dato giorno il servizio 2 non si eroga.
Algoritmo di scelta dell’impiegato. Se non si seleziona l’impiegato lo assegna il sistema. Tuttavia sembra che scelga il primo disponibile. Così se l’impiegato A si occupa dei servizi 1 e 2 e l’impiegato B si occupa del servizio 1, se un “cliente” prenota il servizio 1 senza specificare l’impiegato scelto il sistema gli assegna l’impiegato A. Un cliente che volesse prenotare un appuntamento per il servizio 2 non trova posto.
Interessante poi il ruolo di utente “segretaria” che è in grado di vedere le agende di piu’ impiegati, modificare gli appuntamenti e anche memorizzare i periodi di assenza degl impiegati controllati.
Secondo me se si modificasse in questo modo:
2. non mostrare la lista degli impiegati
3. inserire un calendario di erogazione per il servizio (le disponibilità sono quindi date dall’intersezione di orario di erogazione e disponibilità di impiegati)
4. migliorare l’algoritmo di scelta dell’impiegato (ci sono varie opzioni da valutare)
Ciao @frantheman, esiste una’applicazione web sviluppata da IsWeb per le amministrazioni pubbliche, presentata proprio in questi giorni, che ha le caratteristiche che descrivi.
Attualmente è allo studio l’integrazione con IO, è pensata per avere un elevato grado di interoperabilità e sviluppata sulla base del Kit per i comuni di AGID .
L’applicazione gira su cloud e non necessita di installazione, ti giro il link della demo:
Ciao @frantheman, qualche settimana fa anche @Luca_Bonuccelli1 parlava di un progetto similare e anche in altro thread si parlava di sportelli e appuntamenti. Per ora non ho visto nascere convergenze, fare le cose a più mani è più difficile di quel che sembra
Nel primo di quei thread ho messo un po’ di link sulla funzionalità di prenotazione appuntamenti che abbiamo rilasciato su developers italia, ti rimando a questo post nel caso ti possa interessare:
Anche noi abbiamo disaccoppiato il calendario dal servizio per cui si chiede un appuntamento. Ci siamo fatti guidare dalla linea guida sul design dei servizi web che mette al centro il cittadino, siamo partiti dal servizio a cui il cittadino deve accedere e solo successivamente come canale per accedere al servizio abbiamo inserito il calendario.
In questo modo abbiamo diversi servizi che insistono sullo stesso calendario perché è lo stesso ufficio che li eroga, ma che hanno diverse descrizioni, messaggi via email diversi, reminder personalizzati (Si ricordi di portare il documento X, portare marca da bollo Y, etc…).
Devo candidamente confessare che inizialmente è stata una scelta un po’ di comodo: la stanza del cittadino era fatta così, c’è un catalogo di servizi e poi si accede ai singoli servizi che possono essere implementati in vari modi (un modulo, un pagamento, un’iscrizione), ce lo stavano chiedendo in tanti e la cosa più semplice era aggiungere un Calendario e così abbiamo fatto.
Ma già il secondo Ente che ha iniziato ad usarlo aveva esattemente l’esigenza di differenziare lo User Journey a seconda del motivo per cui il cittadino si presenta allo sportello e a quel punto ci siamo trovati con tutte le feature al posto giusto
Ti confermo la grande utilità dell’utente di tipo segreteria, che mette mano molto liberamente al calendario. Nel nostro caso il calendario è usato anche da politici per il proprio ricevimento, quindi capita più di frequente l’esigenza di spostare un appuntamento: in quel caso il cittadino viene informato del nuovo orario e può eventualmente cancellare l’appuntamento se non gli va bene.
Non abbiamo invece alcuna associazione tra appuntamenti e impiegati (nel senso di appartenenti al gruppo che gestisce il calendario), non abbiamo ancora avuto l’esigenza di inserirla. Mi è molto chiaro che serva quando si fanno i totem per gli sportelli fisici, perché a un certo punto devi guidare il biglietto A allo sportello N, mentre per un appuntamento con un ufficio mi sembra meno utile, ti va di spiegarmi meglio?
Grazie!
Intanto complimenti sinceri per “la stanza del cittadino”, speri di poterci dare un’occhiata piu’ approfondita perche’ mi sembra una soluzione interessante.
Ti spiego meglio. Lo scenario che ho in mente (che, ragionevolmente, è quello della mia realtà) prevede appunto che il cittadino si presenti allo sportello / in ufficio su appuntamento. Si tratta di una esigenza pre-covid, fondamentale allora per certe tipologie di appuntamenti (es.: parlare di una pratica edilziia con l’ufficio tecnico), che con l’emergenza covid diventa una necessità anche per altri appuntamenti (che non si riescono a fare direttamente a distanza).
Ci sono quindi degli impiegati a disposizione in certi orari.
L’ideale sarebbe dire al sistema quando questi impiegati possono ricevere appuntamenti e per quale “servizio” (CIE, tessera elettorale…), segnalare loro giorni di assenza (ferie, malattia?, assemblee sindacali ecc.).
Al momento della prenotazione da parte del cittadino si incrociano questi dati per mostrare le disponibilità e il sistema stessa, almeno come proposta, assegna l’appuntamento a un impiegato che si vede la lista degli appuntamenti su una pagina web (o direttamente sull’agenda della posta elettronica aziendale).
Poi il “segretario” o il “coordinatore”/“responsable” di una categoria di appuntamenti/servizi puo’ fare aggiustamenti.
Ho dato un’occhiata ai thread che segnali, quello di Luca Bonuccelli in effetti ricordo di averlo letto a suo tempo: rispetto alla sua pregevole idea, quello che propongo io è qualcosa di molto basico, solo prenotare un appuntamento, come se si telefonasse alla segreteria del dottore. Aggiungere funzionalità di videochiamata, di firma avanzata, di compilazione assistita di moduli è senz’altro interessante ma rende il software troppo articolato per potersi adattare a tutte le realta’.: il modulo si porta dietro i template, la firma già una chimera di per se’ si porta dietro le questioni di registrazione del documento a protocollo ecc.
Una semplice agenda di appuntamenti slegata da altre procedure software (ma collegabile - ammesso che serva - ad altre procedure software tramite API/WS) potrebbe essere un progetto che coinvolge davvero tutti.
Secondo me si dovrebbe partire dal modello ‘complesso’ e fare in modo che sia ‘semplificabile’ a seconda della conformazione e delle esigenze dell’ente. Es. Sono in un ente che ha un ufficio edilizia con 20 impiegati e so da quale devo andare? Mettendo il protocollo della mia pratica il sistema mi deve permettere di fissare l’appuntamento proprio con colui che la sta seguendo. Sono un ente con un minuscolo ufficio che ha solo un addetto per tutto l’ufficio tecnico-edilizia-strade ecc? Quando scelgo la materia, il sistema mi ‘punta’ direttamente al suo calendario e salta tutti gli altri passaggi pensati per l’ente complesso. Dovrebbe esserci una parte di ‘profilazione’ dell’ente e poi a seconda di cosa ho inserito, il sistema presenta all’utente una cosa o l’altra. In questo modo avrei un programma prenotazioni solo e non due, e se un domani il piccolo comune si fonde con altri e si trova uffici grossi, deve cambiare solo la profilazione degli uffici e il sistema continuerà il suo lavoro senza intoppi.
Potenzialmente fatto così sarebbe una soluzione universale.
Ciao @Elena_S, ti invito a dare un’occhiata alle demo di ISWEB citata poco sopra. Sono settati alcuni servizi di esempio che rispecchiano entrambe le configurazioni che descrivi:
In front-end l’informazione al cittadino può fare riferimento sia all’ufficio sia al responsabile di servizio, il tutto sviluppato sulla base del kit dei comuni di AGID.
L’applicativo lascia all’utente amministratore piena libertà di scegliere in back-end se attribuire il servizio prenotabile all’ufficio intero o al singolo utente operatore.
Come auspicato da @frantheman esiste la possibilità di settare un utente con competenze trasversali con funzione di “segretario” o di “responsabile” -si pensi ad uffici strutturati con più operatori gestiti da un responsabile- che da un’unica interfaccia a calendario sia in grado di operare sulle agende di molteplici utenti operatori.
La configurazione dell’applicativo è molto semplice, ma allo stesso tempo offre un elevato grado di flessibilità.
Attualmente stiamo andando online con enti estremamente eterogenei per caratteristiche organizzative ed esigenze funzionali. Sarebbe interessante avere un feedback!
Bè è una demo molto “demo”, non si vede nulla a parte un calendario e delle descrizioni da riempire.
Prevede la possibilità di agganciare appuntamenti multipli? Penso agli utenti tipo gli studi di architetti che magari hanno più cose aperte e quando vanno in un ufficio vorrebbero evadere più pratiche assieme senza dover aspettare un’ora di buco tra due appuntamenti ad es. Per l’utenza professionale servirebbe la possibilità di avere appuntamenti concatenati senza dover fare prenotazioni multiple.
Grazie mille per le considerazioni @Elena_S. In front-end la demo è molto “demo” perché sono stati configurati pochissimi servizi di esempio, e perché in realtà uno dei punti di forza di eAgenda è la semplicità di navigazione. Sarebbe interessante che tu vedessi il back-end, ed esplorare le innumerevoli possibilità di configurazione. La filosofia è: semplice per il cittadino, potente per l’amministratore.
Attualmente non è possibile “concatenare” appuntamenti multipli per come li descrivi, ma credo che il problema sia a monte dell’agenda e riguardi l’assetto organizzativo del gruppo di servizi prenotabili. In un contesto dove ogni servizio è prenotabile singolarmente, l’applicativo dovrebbe essere programmato per cercare uno slot temporale dove i servizi di interesse del prenotante sono tutti contemporaneamente liberi: non difficile da progettare, ma statisticamente molto difficile da verificarsi per uffici molto trafficati e per “concatenamenti” complessi. L’amministratore però potrebbe prevedere la possibilità a prenotarsi per “servizi/procedure” complesse da gestire sulla base dell’organizzazione delle risorse interne. Lo spunto è molto interessante: ti ringrazio davvero.
