Un’area clienti, un portale ordini B2B o un’app interna nascono spesso da un elenco di funzioni. Per preparare il progetto di un portale aziendale conviene partire da un’altra parte: chi entra, cosa vede, cosa può fare. Qui trovi come trasformare le risposte in requisiti, un esempio illustrativo e una checklist per il preventivo.

Non ti serve un linguaggio tecnico: ti serve conoscere il lavoro che il portale dovrà sostenere.

Perché partire da ruoli e azioni, e non dalle schermate?

Una richiesta come «un’area riservata con catalogo e ordini» sembra chiara. In realtà lascia aperte molte domande. Chi vede quali prezzi? Chi approva un ordine? Cosa succede se un articolo manca?

Ogni risposta porta a un portale diverso. Prima di stimare, chi sviluppa deve ricostruire chi usa il sistema e cosa ci fa. Se arrivi con questo lavoro impostato, puoi confrontare proposte che descrivono lo stesso perimetro.

Un ruolo è un gruppo di persone con gli stessi permessi. Un’azione è un verbo: consultare, ordinare, approvare, caricare, esportare. Incrociando ruoli e azioni ottieni lo scheletro dei requisiti.

Quali domande trasformano ruoli e azioni in requisiti?

Affronta queste domande in ordine e rispondi per iscritto, anche con frasi semplici. Dove non hai una risposta, scrivilo.

Chi entra?

Elenca tutti i tipi di utenti: clienti, rivenditori, agenti, fornitori, colleghi di altri reparti, amministratori. Per ognuno chiarisci come ottiene l’accesso. Si registra da solo, lo abiliti tu o arriva già dal gestionale?

Pensa anche a chi esce. Un agente che cambia zona o un cliente che chiude il rapporto deve perdere l’accesso, in tutto o in parte. Anche questo è un requisito.

Cosa vede?

Per ogni ruolo indica i dati visibili: ordini, listini, documenti, scadenze, stato delle pratiche. Poi fissa il perimetro. Un cliente vede solo i propri ordini? Un agente vede tutti i clienti della sua zona?

Segna anche da dove arriva ogni dato. Un listino che vive nel gestionale non va ricopiato a mano nel portale: va letto dalla fonte.

Cosa può fare?

Qui servono i verbi: ordinare, modificare un indirizzo, caricare un documento, annullare. Per ogni azione chiediti chi la esegue, chi la approva e chi riceve un avviso.

Descrivi anche le eccezioni che capitano davvero: un ordine sotto il minimo, un articolo fuori catalogo, un documento scaduto. Le regole normali si spiegano in poche righe. Sono le eccezioni a dare forma al lavoro.

Con cosa deve integrarsi?

Elenca i sistemi con cui il portale deve dialogare: gestionale o ERP, CRM, magazzino, eCommerce, posta, archivio documenti. Per ognuno annota quali dati passano, in quale direzione e quale sistema resta la fonte ufficiale.

Chiedi al fornitore del gestionale se esistono API o esportazioni, e chi può abilitarle. La risposta può cambiare molto il progetto. Se non la conosci ancora, segnalalo: si verifica durante l’analisi.

Cosa succede oggi, senza portale?

Descrivi il processo attuale, passo per passo. Chi riceve la richiesta, dove la registra, chi la controlla, come risponde. Email, telefonate, fogli di calcolo e passaggi a voce vanno tutti nell’elenco.

Questa descrizione mostra dove si perdono tempo e informazioni. Diventa anche il punto di confronto quando il portale sarà in uso. Se un passaggio oggi funziona bene, dillo: non tutto va rifatto.

Come si scrivono i requisiti in una pagina?

Le risposte si possono raccogliere in una pagina. Quella pagina non sostituisce l’analisi, ma dà a chi deve stimare un perimetro preciso. Ecco come potrebbe apparire per un portale ordini.

Esempio illustrativo

Progetto. Un’azienda ipotetica che distribuisce ricambi vuole un portale ordini per i suoi rivenditori, che oggi ordinano via email e telefono.

Ruoli

Rivenditore: titolare o addetto di un negozio cliente.
Agente: segue i rivenditori di una zona.
Ufficio commerciale: gestisce condizioni ed eccezioni.
Amministratore: crea gli account e assegna i permessi.

Azioni per ruolo

Ruolo	Vede	Può fare
Rivenditore	Catalogo, il proprio listino, i propri ordini e documenti	Ordinare, ripetere un ordine, scaricare fatture e documenti di trasporto
Agente	Rivenditori e ordini della propria zona	Ordinare per conto di un rivenditore, proporre uno sconto
Ufficio commerciale	Tutti gli ordini e le eccezioni aperte	Approvare sconti e ordini fuori regola, sospendere un account
Amministratore	Utenti e permessi	Creare, modificare e disattivare gli account

Dati

Anagrafiche, articoli, listini e disponibilità: arrivano dal gestionale.
Ordini: nascono nel portale e passano al gestionale.
Fatture e documenti di trasporto: prodotti dal gestionale, consultabili nel portale.

Integrazioni

Gestionale: lettura di anagrafiche, listini e disponibilità, scrittura degli ordini. Da verificare se offre API o esportazioni.
Posta: conferma d’ordine al rivenditore, avviso all’ufficio commerciale per ogni eccezione.

Fuori dalla prima versione

Pagamenti online.
App da installare sul telefono.
Versioni in altre lingue.
Gestione di resi e reclami.

Guarda l’ultima sezione dell’esempio. Scrivere cosa resta fuori conta quanto scrivere cosa entra, e prepara la scelta successiva.

Meglio partire da una prima versione o dal progetto completo?

Una prima versione essenziale (in inglese MVP) copre il flusso principale, dall’inizio alla fine, e lo mette nelle mani di utenti veri. Il progetto completo include da subito tutto ciò che hai individuato. Nessuna delle due strade va bene per tutti.

Prima versione essenziale (MVP)

Pro

L’impegno iniziale è più limitato, perché il perimetro è più piccolo.
Verifichi le ipotesi con chi userà davvero il portale, prima di investire nel resto.
Le priorità successive nascono dall’uso, non dalle supposizioni.

Contro

Per un periodo alcune attività restano nel vecchio processo.
Se l’architettura non prevede le fasi successive, una parte del lavoro andrà rifatta.
Un portale troppo scarno rischia di non essere usato.

Progetto completo

Pro

Hai una visione d’insieme, e l’architettura nasce pensata per tutte le funzioni.
Gli utenti cambiano abitudini una volta sola.
Pianificazione e budget si discutono su un perimetro definito.

Contro

Passa più tempo prima che qualcuno usi il portale.
Le ipotesi restano tali fino al rilascio: se una è sbagliata, lo scopri tardi.
Durante lo sviluppo le esigenze possono cambiare, e il documento iniziale invecchia.

Come scegliere? Se il processo è nuovo o poco definito, una prima versione ti permette di verificare presto la direzione. Se è stabile, documentato e va sostituito in blocco, il progetto completo può avere più senso. Spesso la strada sta nel mezzo: un progetto pensato per intero e rilasciato per fasi.

Quando scegliere WordPress e quando uno sviluppo su misura?

Nessuna delle due è sempre la scelta migliore. WordPress offre molte estensioni già pronte. Uno sviluppo su misura parte dalle tue regole, non da un prodotto esistente. Decide il progetto, non l’abitudine di chi sviluppa.

Se stai ancora valutando se una piattaforma su misura fa al caso tuo, leggi anche Software aziendale su misura: quando una piattaforma diventa un vantaggio competitivo.

Criterio	Fa pendere verso WordPress	Fa pendere verso lo sviluppo su misura
Contenuti	Il portale convive con un sito ricco di contenuti	Il cuore è un’applicazione, con pochi contenuti editoriali
Regole	Regole semplici, già coperte da estensioni affidabili	Regole specifiche della tua azienda, che cambiano spesso
Ruoli e permessi	Pochi ruoli, con permessi lineari	Permessi che dipendono da zone, clienti o stato delle pratiche
Integrazioni	Scambi di dati semplici e occasionali	Scambi continui con più sistemi, con controlli e gestione degli errori
Interfaccia	Pagine e moduli sono sufficienti	Serve uno strumento operativo, per chi ci lavora ogni giorno
Gestione nel tempo	Il tuo team usa già WordPress e aggiorna i contenuti in autonomia	Preferisci meno dipendenze da componenti di terze parti

Ogni strada ha un lavoro che non si vede subito. Con WordPress, le estensioni vanno aggiornate e controllate nel tempo. Con lo sviluppo su misura, ogni funzione va scritta, provata e mantenuta. In entrambi i casi chiedi chi segue aggiornamenti, sicurezza e backup dopo il rilascio.

Esistono anche soluzioni miste: il sito resta su WordPress e il portale è un’applicazione separata, collegata dove serve. Se il progetto ha regole tutte sue, leggi come lavoriamo su configuratori, preventivatori e piattaforme su misura.

Sei pronto a chiedere un preventivo?

Prima di contattare chi dovrà sviluppare il portale, controlla questi punti.

Checklist da copiare

Ho elencato i ruoli: chi entra nel portale e come ottiene l’accesso.
Per ogni ruolo ho scritto cosa vede e cosa non deve vedere.
Per ogni ruolo ho scritto le azioni, chi le approva e chi riceve gli avvisi.
Ho descritto le eccezioni che capitano davvero.
Ho elencato i sistemi da collegare e, per ogni dato, la fonte ufficiale.
So se il gestionale offre API o esportazioni, oppure l’ho segnato come dubbio.
Ho descritto come si lavora oggi, passo per passo.
Ho deciso cosa resta fuori dalla prima versione.
So se preferisco partire da una prima versione essenziale o dal progetto completo, e perché.
Ho indicato chi, in azienda, segue il progetto e prende le decisioni.
Ho chiarito i vincoli su privacy, accessi e dati da non esporre.

Se qualche punto è ancora aperto, va bene lo stesso: il primo confronto serve anche a chiuderlo. Per farti un’idea del nostro metodo, guarda i progetti che abbiamo realizzato. Se il portale è parte di un intervento più ampio, dai un’occhiata a tutti i servizi.

Il percorso guidato ti chiede, un passo alla volta, chi userà il portale, cosa deve fare, come si lavora oggi e con quali sistemi deve dialogare. Rispondi con quello che sai già. Descrivi il tuo portale con il percorso guidato.

Domande frequenti

Cosa deve contenere il documento dei requisiti di un portale?

Ruoli, azioni per ruolo, dati con la loro fonte, integrazioni, processo attuale e ciò che resta fuori dalla prima versione. I dettagli tecnici si definiscono dopo, nell’analisi.

Posso chiedere un preventivo se non ho tutte le risposte?

Sì. Indica cosa sai e cosa non sai ancora. Un dubbio dichiarato è più utile di una risposta inventata, e si chiarisce nelle prime fasi del progetto.

Il portale può usare i dati del gestionale che abbiamo già?

Dipende da come il gestionale rende disponibili i dati: API, esportazioni o altri accessi controllati. Va verificato caso per caso, prima di stimare le integrazioni.

Chi deve seguire il progetto in azienda?

Una persona che conosce il processo e può prendere decisioni. Non deve essere un tecnico, ma deve avere il tempo di rispondere alle domande e di provare le prime versioni.