Portali e aree riservate

Ruoli e permessi decisi prima

Un accesso, molti servizi

Progettato per chi lo usa ogni giorno

Dati sensibili

Integrazione con i gestionali

Continuità

01A chi serve un portale riservato

• A chi gestisce pratiche e documenti scambiandoli via email.
• A chi ha clienti o fornitori che chiedono continuamente lo stato di un lavoro.
• A chi vuole offrire un servizio digitale senza costruire un’app da zero.

Un portale serve quando le informazioni circolano tra persone che non lavorano nella stessa stanza. Pratiche, documenti, ordini, richieste di assistenza: se tutto passa dalla posta, ogni scambio crea una copia, un dubbio e una versione diversa dello stesso file.

Serve anche quando l’azienda vuole distinguersi offrendo un servizio più ordinato: il cliente entra, vede lo stato, scarica ciò che gli serve. Non è un requisito di tutte le imprese. Se i volumi sono bassi e le persone sono poche, una cartella condivisa ben organizzata può bastare.

02Le ricerche di chi cerca un portale

Le ricerche tipiche sono «area riservata clienti», «portale clienti personalizzato», «area riservata WordPress», «portale per pratiche», «gestionale online per clienti». Chi cerca ha spesso un’esigenza concreta e un’idea già formata: ha visto un portale altrui e vorrebbe qualcosa di simile.

La pagina spiega che cosa si può costruire, quali sono le decisioni da prendere e quando un portale non è la risposta giusta. Un portale mal progettato costa più di un’area condivisa ben gestita, perché aggiunge manutenzione e responsabilità senza risolvere il problema.

Il lavoro parte dai ruoli e dai casi d’uso, poi passa all’interfaccia, ai dati e alle integrazioni. Ogni ambito ha un risultato verificabile.

Analisi dei ruoli e dei casi d’uso

Chi entra, per fare cosa e con quale frequenza. Da qui nascono le schermate e i permessi.

Mappa delle persone

Clienti, fornitori, dipendenti, amministratori e ospiti, con bisogni diversi.

Casi d’uso principali

Le azioni che devono essere possibili e quelle che devono essere impedite.

Frequenza e contesto d’uso

Chi entra ogni giorno e chi una volta al mese, da computer o da telefono.

Criteri di successo

Cosa deve essere più semplice o più veloce rispetto a oggi.

Progettazione dell’esperienza

Struttura delle schermate, percorsi principali e testi, con attenzione all’uso da telefono.

Architettura dell’informazione

Sezioni, voci di menu e gerarchia, costruite sui compiti reali.

Schermate principali

Elenco, dettaglio, caricamento documenti, richieste e impostazioni.

Stati vuoti ed errori

Messaggi che spiegano cosa manca e come risolvere, senza gergo tecnico.

Verifica con utenti reali

Prova dei percorsi con alcune persone prima di sviluppare tutto.

Autenticazione e accesso

Registrazione, accesso, recupero password e verifica in due passaggi, con regole comprensibili.

Inviti e registrazione

Creazione degli account da parte dell’azienda o autonomia controllata.

Recupero delle credenziali

Procedura chiara che non rivela se un indirizzo è registrato.

Verifica in due passaggi

Protezione aggiuntiva per gli accessi più delicati.

Sessioni e uscita

Scadenza, disconnessione e comportamento su dispositivi condivisi.

Ruoli, permessi e visibilità

Ogni persona vede solo ciò che le spetta, con regole verificabili e un registro delle modifiche.

Definizione dei ruoli

Ruoli semplici, descritti con esempi, evitando combinazioni infinite.

Permessi per documento e pratica

Visibilità legata alla relazione con il cliente o all’assegnazione.

Verifica degli accessi

Prove con utenti finti per controllare che i confini tengano.

Registro delle consultazioni

Traccia di chi ha aperto o scaricato i documenti più delicati.

Documenti e file

Caricamento, versioni, scadenze e download, con limiti e controlli sui formati.

Caricamento guidato

Formati ammessi, dimensioni e istruzioni prima che l’utente scelga il file.

Versioni e sostituzioni

Storia dei documenti e indicazione dell’ultima versione valida.

Scadenze e promemoria

Avvisi per documenti in scadenza o mancanti.

Conservazione

Regole su cosa resta disponibile e per quanto tempo.

Pratiche, ordini e richieste

Stati chiari e passaggi tracciati, con la possibilità di sapere sempre a che punto si è.

Modello degli stati

Passaggi semplici, con nomi comprensibili al cliente.

Cronologia degli eventi

Data, autore e descrizione di ogni cambiamento.

Richieste e messaggi

Comunicazioni legate alla pratica, senza disperderle nella posta.

Notifiche

Avvisi solo quando servono, con preferenze controllabili.

Integrazione con i sistemi interni

Dati da gestionali, fatturazione e magazzino, senza doppio inserimento.

Mappa delle fonti

Quale sistema è autorevole per ogni dato mostrato nel portale.

Sincronizzazione

Aggiornamento periodico o su evento, con gestione dei conflitti.

Errori e code

Recupero dei dati non sincronizzati e avvisi agli amministratori.

Verifica dei conteggi

Confronto tra portale e gestionale sui numeri principali.

Sicurezza dei dati

Protezione di documenti e informazioni personali, con accessi limitati e tracciamento.

Cifratura del traffico

HTTPS su tutte le pagine e protezione dei file serviti.

Minimo privilegio

Ogni account ha solo i permessi necessari.

Protezione dai tentativi automatici

Limiti di accesso e controlli sulle richieste anomale.

Backup e ripristino

Copie separate e prova di ripristino del portale e dei documenti.

Manutenzione ed evoluzione

Aggiornamenti, monitoraggio e piccoli miglioramenti programmati dopo il lancio.

Controlli periodici

Accessi, backup, spazio, errori e funzioni critiche.

Assistenza agli utenti

Un canale chiaro per problemi e richieste di modifica.

Rilascio di miglioramenti

Modifiche piccole e frequenti, con note di versione.

Revisione dei permessi

Controllo periodico di chi ha accesso e perché.

Formazione e documentazione

Istruzioni per utenti e amministratori, con esempi e responsabilità dichiarate.

Guida per gli utenti

Poche pagine con le operazioni principali e le domande frequenti.

Manuale per gli amministratori

Gestione di account, ruoli, documenti e notifiche.

Sessione di formazione

Prova guidata sui casi reali, con spazio alle domande.

Referenti

Una persona per gli utenti e una per la parte tecnica.

03Portale, intranet o semplice area condivisa

Le parole si somigliano ma indicano cose diverse. Un’area riservata per i clienti mostra pratiche e documenti. Una intranet serve ai dipendenti e contiene procedure, comunicazioni interne e strumenti di lavoro. Una semplice area condivisa, come una cartella con permessi, risolve pochi bisogni con poco costo.

La scelta dipende da chi deve entrare e da quanto controllo serve. Se l’unico bisogno è scambiare file con tre clienti, una cartella condivisa è più ragionevole. Se i clienti sono cinquanta e ognuno deve vedere solo i propri documenti, il portale comincia ad avere senso.

• Area condivisa: pochi utenti, bisogni semplici, nessuna personalizzazione.
• Portale clienti: pratiche, documenti e stati per persone esterne.
• Intranet: procedure e comunicazioni per i dipendenti.
• Estensione di un gestionale: quando lo strumento interno ha già le funzioni necessarie.
• Applicazione su misura: quando il portale è parte del servizio venduto.

Il progetto comincia con una mappa delle persone e dei compiti. Da lì costruiamo un prototipo navigabile delle schermate principali, che viene provato con alcune persone reali. Solo dopo si scrive il codice. Questo passaggio evita di scoprire a sviluppo avanzato che il percorso non funziona.

Lo sviluppo procede per rilasci: prima l’accesso e i documenti, poi le pratiche e le notifiche, infine le integrazioni. Ogni rilascio viene provato con dati realistici e con utenti di prova. Il portale va online quando i casi principali funzionano, non quando ogni dettaglio è perfetto.

• Mappa di ruoli e compiti.
• Prototipo delle schermate principali.
• Prova con utenti reali.
• Sviluppo per rilasci successivi.
• Collaudo con dati realistici e messa online graduale.

Misuriamo il tempo che serve a completare i compiti principali: trovare un documento, caricare un file, capire lo stato di una pratica. Misuriamo anche quante richieste di assistenza arrivano per le stesse difficoltà: se aumentano, l’interfaccia non sta funzionando.

Sul piano tecnico guardiamo errori di accesso, tempi di risposta, fallimenti delle integrazioni e spazio dei documenti. Un portale lento o che perde file viene abbandonato, anche se ha tutte le funzioni.

• Tempo per completare i compiti principali.
• Richieste di assistenza ripetute.
• Errori di accesso e recuperi password.
• Fallimenti di sincronizzazione.
• Documenti mancanti o scaduti.
• Utilizzo reale per ruolo.

L’errore più grave è partire dalle schermate senza aver deciso i permessi: si finisce con regole aggiunte a posteriori e falle difficili da chiudere. Il secondo è costruire troppe funzioni per pochi utenti, rendendo il portale un progetto infinito.

Un altro errore è non prevedere il recupero password e l’assistenza: metà delle chiamate riguarda l’accesso. Infine, trascurare la migrazione dei documenti esistenti: un portale vuoto non convince nessuno a cambiare abitudini.

• Permessi decisi dopo le schermate.
• Funzioni in eccesso rispetto ai casi d’uso.
• Assistenza e recupero password trascurati.
• Migrazione dei file rimandata.
• Nessuna formazione per gli utenti.
• Integrazioni non monitorate.

04Domande da fare a un fornitore

Chiedi come vengono gestiti i permessi e chi può modificarli. Chiedi cosa succede quando un utente cambia ruolo o lascia l’azienda. Chiedi dove sono conservati i documenti e chi può scaricarli.

Chiedi anche come si esportano i dati e cosa rimane al cliente alla fine del contratto. Un portale contiene il lavoro quotidiano di un’azienda: la libertà di portarlo altrove è parte della qualità del servizio.

• Come sono definiti e verificati i permessi?
• Chi può creare o disattivare un account?
• Dove sono conservati i documenti?
• Come si esportano dati e file?
• Cosa succede alla fine del contratto?

Servono le persone giuste nelle riunioni: chi conosce i processi, chi gestisce i clienti e chi risponderà dell’assistenza. Servono esempi reali di pratiche e documenti, con le parti riservate oscurate. Servono decisioni sui ruoli e sulla conservazione.

Serve anche la disponibilità a ripensare qualche abitudine. Un portale cambia il modo in cui si comunica con i clienti: se il team continua a mandare tutto via email, il portale diventa un doppione.

• Referente interno e persone chiave.
• Esempi reali di pratiche e documenti.
• Decisioni su ruoli e visibilità.
• Regole di conservazione.
• Disponibilità a cambiare le abitudini di scambio file.

Un portale non sostituisce un gestionale, un CRM o un sistema di fatturazione. Se il bisogno principale è gestire ordini e magazzino, serve un ERP. Se il bisogno è tracciare opportunità commerciali, serve un CRM. Il portale è la facciata per l’utente, non il motore.

In alcuni casi serve prima un lavoro sui processi interni: se nessuno sa chi deve caricare un documento, il portale renderà visibile il disordine. Meglio affrontarlo prima.

Quando il portale deve diventare parte di un sistema più ampio, con regole specifiche. Vedi sviluppo software

CRM e automazioni

Contatti e attività collegate al portale, senza doppio inserimento. Vedi CRM e automazioni

Un portale usato ogni giorno deve essere leggibile e navigabile da tutti. Vedi accessibilità web

05Glossario di portali e aree riservate

I termini che compaiono nei progetti, spiegati senza gergo.

06Checklist prima di sviluppare

Prima di scrivere una riga di codice, questi punti devono essere chiari. Se mancano, il progetto si blocca.

• Elenco dei ruoli e di cosa può fare ciascuno.
• Casi d’uso principali e frequenza.
• Documenti e dati da migrare.
• Regole di conservazione e cancellazione.
• Integrazioni necessarie e sistemi di origine.
• Requisiti di accessibilità.
• Referente interno e canale di assistenza.
• Piano di rilascio e criterio di riuscita.

07Come riconoscere un portale fatto bene

Un portale fatto bene si usa senza manuale per le operazioni quotidiane. Le persone trovano ciò che cercano, i documenti sono al posto giusto e nessuno chiede «dove lo carico?». Le regole di accesso sono comprensibili e vengono verificate.

Si riconosce anche dalla manutenzione: c’è un referente, un canale di assistenza e un registro delle modifiche. Il portale non è un progetto che finisce al lancio, ma un servizio che continua.

• I compiti principali richiedono pochi passaggi.
• Nessun utente vede dati che non gli spettano.
• Esiste un modo semplice per recuperare l’accesso.
• Le integrazioni avvisano quando falliscono.
• I documenti hanno versioni e scadenze chiare.

Un’area riservata semplice, con accesso e documenti, richiede da quattro a otto settimane. Un portale con pratiche, notifiche e integrazione a un gestionale richiede da tre a sei mesi. La variabile principale non è la grafica: sono le decisioni sui ruoli e la qualità dei dati da migrare.

Conviene dividere il lavoro in rilasci. Il primo mette online ciò che serve davvero, gli altri aggiungono funzioni. Un progetto unico e lungo rischia di arrivare tardi e di non corrispondere più ai bisogni iniziali.

Il costo dipende dal numero di ruoli, dal numero di flussi, dalle integrazioni e dai requisiti di sicurezza. Un portale per due tipi di utenti con documenti e stati costa meno di un sistema con sei ruoli, pagamenti e sincronizzazione bidirezionale.

La manutenzione è una voce separata e va prevista dal primo giorno. Un portale che tratta dati personali richiede aggiornamenti, backup e controlli periodici. Chiedere un preventivo senza includere questa parte significa rimandare il problema.

• Numero di ruoli e di flussi.
• Documenti da migrare.
• Integrazioni con sistemi esistenti.
• Requisiti di sicurezza e tracciamento.
• Formazione, assistenza e manutenzione.

08Accessibilità in un’area riservata

Un portale usato per lavoro deve essere accessibile: contrasti leggibili, navigazione da tastiera, moduli comprensibili, messaggi di errore chiari. Non è solo una questione normativa: chi usa il portale ogni giorno beneficia di ogni semplificazione.

L’accessibilità va progettata insieme alle schermate, non aggiunta alla fine. Etichette corrette, ordine dei contenuti e stati dei campi sono decisioni che costano poco se prese subito e molto se prese dopo.

09I dati personali in un portale

Un portale conserva documenti, comunicazioni e stati che riguardano persone. Servono una base giuridica chiara, un’informativa comprensibile e regole su chi può accedere. I log delle consultazioni aiutano a ricostruire cosa è successo.

La conservazione non può essere infinita per comodità. Ogni categoria di documento dovrebbe avere una durata e una procedura di cancellazione. Queste decisioni spettano al titolare del trattamento; noi le rendiamo tecnicamente possibili e verificabili.

10Migrare da un portale esistente

Quando esiste già un portale, la migrazione riguarda utenti, documenti, pratiche e cronologie. Bisogna capire quali dati sono ancora necessari e quali possono essere archiviati, chi deve mantenere l’accesso e come comunicare il passaggio.

La migrazione si prova su una copia. Si verificano conteggi, collegamenti ai file e permessi. Il vecchio portale resta raggiungibile in sola lettura per un periodo concordato, così nessuno perde l’accesso a un documento mentre impara il nuovo.

11Autenticazione senza attriti

La sicurezza di un portale non si ottiene rendendo l’accesso impossibile. Se recuperare la password richiede tre passaggi e una telefonata, le persone condivideranno le credenziali. Un buon accesso è semplice per chi ha diritto e difficile per chi non ce l’ha.

La verifica in due passaggi va usata dove serve, non su ogni operazione. Un codice via email al primo accesso da un dispositivo nuovo è spesso sufficiente. Le sessioni lunghe sono comode sui dispositivi personali, ma vanno limitate su quelli condivisi.

Le regole devono essere spiegate prima: come si recupera l’accesso, cosa fare se il telefono è cambiato, chi contattare. La maggior parte delle richieste di assistenza riguarda proprio questi casi, non le funzioni del portale.

12Un portale per i fornitori

I fornitori hanno bisogni diversi dai clienti: caricare documenti, confermare disponibilità, vedere ordini e scadenze. Spesso sono trattati come utenti di seconda categoria, con email e fogli condivisi, mentre il portale clienti è curato.

Un’area fornitori ben fatta riduce gli errori di ordine e le telefonate. Richiede però regole chiare su chi vede cosa: un fornitore non deve vedere i prezzi di un altro, né le richieste dei concorrenti. La separazione dei dati va progettata come per i clienti.

Prima di aprire un’area fornitori conviene misurare il volume di scambi e capire se il problema è la comunicazione o il processo. A volte basta un modulo ben fatto e una cartella condivisa con permessi corretti.

13Documentare le regole di accesso

Le regole di accesso vivono spesso nella testa di chi ha costruito il portale. Quando quella persona non c’è, nessuno sa perché un utente vede una certa pagina. La documentazione deve elencare ruoli, permessi e casi particolari, con esempi.

Il documento va aggiornato quando cambia qualcosa, non riscritto ogni volta. Una tabella con ruolo, cosa può vedere e cosa può fare è sufficiente per la maggior parte dei progetti. Le eccezioni vanno annotate con il motivo e la data.

Documentare serve anche a verificare: se una regola non è scritta, non è verificabile. E una regola non verificabile è una regola che prima o poi si rompe.

Portali e aree riservate servono studi professionali, strutture sanitarie, aziende di servizi e pubbliche amministrazioni. Questi sono alcuni dei settori in cui lavoriamo.

• Strutture governative e pubblica amministrazione
• Immobiliare

Un portale si costruisce insieme ai sistemi che gestiscono i dati e ai servizi che ne curano l’esperienza.

14Domande frequenti sui portali