Capitolato eCommerce: come scrivere un brief o una RFP utilizzabile

TL;DR — Un capitolato eCommerce descrive obiettivi, processi, requisiti e criteri con cui accettare il lavoro. Per confrontare le offerte deve distinguere obblighi, opzioni e punti ancora da analizzare, evitando di imporre una soluzione tecnica prima di aver chiarito il problema.

Vuoi valutare il tuo progetto? Richiedi un audit eCommerce oppure contatta Armah indicando obiettivo, piattaforma e sistemi coinvolti. Non inviare credenziali o dati personali dei clienti.

Indice

1. 1. Chiarire scopo, destinatari e documenti da preparare
2. 2. Modello di sezioni del capitolato eCommerce
3. 3. Scrivere requisiti osservabili e criteri di accettazione
4. 4. Documentare catalogo, sistemi e migrazione
5. 5. Inserire sicurezza, accessibilità e gestione operativa
6. 6. Impostare la risposta dei fornitori e il confronto
7. Come lavora Armah
8. FAQ
9. Guide correlate

1. Chiarire scopo, destinatari e documenti da preparare

In sintesi 1. Brief, capitolato e RFP sono documenti collegati, ma non identici.

Brief, capitolato e RFP sono documenti collegati, ma non identici. Il brief inquadra obiettivi e contesto; il capitolato precisa requisiti e condizioni; la richiesta di proposta, o RFP, spiega come il fornitore deve rispondere e come verrà valutato. Possono convivere nello stesso fascicolo purché siano leggibili.

Inizia con una sintesi destinata anche a chi non conosce l’azienda. Indica cosa vendi, a chi, con quali canali e perché il progetto è necessario. Se esiste già un negozio, descrivi problemi osservati e limiti noti senza confondere diagnosi e preferenze personali.

Assegna un referente per domande commerciali e uno per i temi tecnici. Coinvolgi chi dovrà approvare catalogo, logistica e amministrazione: un capitolato scritto soltanto dall’IT rischia di lasciare fuori condizioni decisive per la vendita.

Dichiara inoltre cosa è fuori perimetro e quali decisioni sono aperte. Se la piattaforma non è scelta, chiedi alternative motivate. Se è vincolata, spiega la ragione e consenti al fornitore di segnalare incompatibilità. La guida alla realizzazione offre il quadro delle fasi da coprire.

2. Modello di sezioni del capitolato eCommerce

In sintesi 2. Il seguente schema è una base da adattare, non un contratto pronto da firmare.

Il seguente schema è una base da adattare, non un contratto pronto da firmare. Le condizioni legali, privacy e di responsabilità richiedono revisione dei referenti competenti. Usa allegati per dati campione e documentazione tecnica, mantenendo leggibile il documento principale.

Sezione	Contenuto da inserire	Allegato utile
Contesto e obiettivi	Canali, clienti e problemi	Mappa dei processi
Perimetro	Mercati, lingue e funzioni	Elenco inclusioni/esclusioni
Catalogo	Tipi di prodotto e attributi	Campione anonimizzato
Percorsi di vendita	Ricerca, acquisto e assistenza	Scenari d’uso
Sistemi e integrazioni	Fonti, flussi e responsabilità	Documentazione API
Dati e migrazione	Elementi da trasferire e validare	Inventario delle fonti
Requisiti trasversali	Sicurezza, accessibilità e prestazioni	Criteri verificabili
Collaudo e lancio	Prove, approvazioni e recupero	Matrice dei test
Gestione successiva	Assistenza, aggiornamenti e accessi	Ruoli operativi
Risposta economica	Voci, ricorrenze ed esclusioni	Modello di offerta

Aggiungi versione, data, responsabile e registro delle modifiche. Se il documento cambia durante la selezione, distribuisci lo stesso aggiornamento a tutti i partecipanti. Le risposte a una domanda che modifica il perimetro non dovrebbero restare in una conversazione privata con un solo fornitore.

3. Scrivere requisiti osservabili e criteri di accettazione

In sintesi 3. Un requisito utile descrive chi deve fare cosa, in quale condizione e con quale esito.

Un requisito utile descrive chi deve fare cosa, in quale condizione e con quale esito. “Ricerca evoluta” non è verificabile; “il cliente trova il prodotto anche usando un codice alternativo presente nel catalogo” permette di costruire un test.

Assegna un identificativo a ogni requisito e classificalo come obbligatorio, desiderabile oppure opzionale. Chiedi ai fornitori di rispondere usando gli stessi identificativi: la corrispondenza rende leggibili copertura, eccezioni e costi aggiuntivi.

Per ogni voce indica:

• Utente o reparto interessato.
• Condizione iniziale e dati di esempio.
• Comportamento atteso.
• Eccezioni da gestire.
• Evidenza richiesta per accettare il lavoro.

Esempio B2B: un buyer visualizza soltanto il listino assegnato alla propria azienda; l’utente di un’altra organizzazione non può accedervi modificando un indirizzo o una richiesta. Il test deve verificare sia la disponibilità della funzione sia l’isolamento dei dati.

Non prescrivere un modulo specifico se non esiste un vincolo motivato. Per la ricerca semantica AI, descrivi query campione, rilevanza attesa e gestione dei risultati assenti; il nome della tecnologia non sostituisce il criterio di accettazione.

4. Documentare catalogo, sistemi e migrazione

In sintesi 4. Prepara un inventario delle fonti: gestionale, PIM, fogli di calcolo, archivio immagini e sito esistente.

Prepara un inventario delle fonti: gestionale, PIM, fogli di calcolo, archivio immagini e sito esistente. Specifica chi può autorizzare accessi ed esportazioni. Non allegare dati personali o credenziali reali a una richiesta distribuita indiscriminatamente.

Per i collegamenti indica oggetto scambiato, direzione, fonte autorevole, frequenza richiesta e comportamento in caso di errore. Chiedi al fornitore del gestionale documentazione aggiornata e accesso a un ambiente di prova, se disponibile. La guida all’integrazione ERP aiuta a completare questa parte.

La migrazione deve distinguere prodotti, clienti, ordini storici, contenuti e URL. Per ogni elemento definisci necessità, fattibilità e controllo finale. Le credenziali dei clienti, per esempio, non devono essere considerate trasferibili senza analisi dei sistemi coinvolti.

Prevedi una prova di importazione con riconciliazione tra origine e destinazione, non soltanto un controllo visivo. Se il progetto sostituisce un negozio indicizzato, allega la checklist di migrazione SEO.

Per il catalogo descrivi anche chi valida i contenuti. Se valuti schede prodotto con AI, specifica campi consentiti, revisione umana e fonti ammesse. La qualità del testo non può essere dedotta dalla sola capacità di generarlo.

5. Inserire sicurezza, accessibilità e gestione operativa

In sintesi 5. Le funzioni visibili non esauriscono il capitolato.

Le funzioni visibili non esauriscono il capitolato. Devi sapere come vengono gestiti accessi, aggiornamenti e continuità del servizio, e quali verifiche sono comprese. Chiedere semplicemente “sito sicuro” non definisce responsabilità o prove.

Prevedi requisiti su separazione degli ambienti, privilegi degli account, gestione dei segreti, registri tecnici e ripristino. Concorda come vengono segnalate vulnerabilità e anomalie e chi interviene sui sistemi esterni. L’accesso a un servizio non equivale alla possibilità di modificarlo.

Per accessibilità e privacy identifica gli obblighi applicabili con i referenti competenti e traduci l’analisi in attività verificabili. Non considerare un’estensione installata come attestazione automatica di conformità.

Le prestazioni devono essere valutate su pagine, dati e condizioni dichiarati. Specifica dispositivi, scenari e modalità di verifica senza confondere una prova di laboratorio con tutte le esperienze reali degli utenti.

Documenta infine consegna degli account, formazione, manuali, codice applicabile e procedura di passaggio a un altro fornitore. Il capitolato deve descrivere anche il giorno dopo il lancio: chi controlla gli errori, aggiorna i prodotti e autorizza le modifiche? Queste informazioni rendono il progetto gestibile, non soltanto pubblicabile.

6. Impostare la risposta dei fornitori e il confronto

In sintesi 6. Fornisci un formato di risposta comune. Per ciascun requisito chiedi copertura nativa, configurazione, estensione, sviluppo personalizzato o mancata copertura.

Fornisci un formato di risposta comune. Per ciascun requisito chiedi copertura nativa, configurazione, estensione, sviluppo personalizzato o mancata copertura. La dichiarazione “incluso” deve essere accompagnata dalle condizioni che la rendono vera.

Separa proposta tecnica ed economica in sezioni riconoscibili. La parte economica deve distinguere avviamento, ricorrenze, consumo, attività interne ed esclusioni; la guida su quanto costa un eCommerce approfondisce queste categorie.

Richiedi una dimostrazione su scenari rappresentativi. Per un progetto B2B, usa lo stesso cliente campione e le stesse regole di approvazione con tutti i candidati. Per un catalogo complesso, verifica varianti, attributi incompleti e prodotti non disponibili.

Rendi espliciti i criteri decisionali prima di leggere le offerte: copertura, mantenibilità, chiarezza delle responsabilità, qualità delle prove e condizioni contrattuali. Non occorre inventare punteggi apparentemente oggettivi se le informazioni non sono comparabili.

Infine chiedi un elenco delle ipotesi ancora da validare e delle dipendenze esterne. Una proposta che identifica un’incognita non è automaticamente peggiore di una che la ignora. Può essere opportuno prevedere un’analisi preliminare prima dell’impegno sullo sviluppo completo.

Come lavora Armah

In sintesi 7. Armah è attiva dal 2013, con 22 collaboratori in Italia, ed è Hyvä Silver Partner.

Armah è attiva dal 2013, con 22 collaboratori in Italia, ed è Hyvä Silver Partner. Le certificazioni Adobe/Magento presenti tra i collaboratori sono individuali: Armah non è partner aziendale Adobe.

Il capitolato è una base per discutere requisiti, dipendenze e prove, non un elenco da accettare senza verifica. Nel confronto chiedi che siano distinti servizi proposti, attività escluse e responsabilità dei fornitori di sistemi terzi.

Consulta i case study per individuare esperienze pertinenti e i servizi eCommerce per orientare la richiesta. Questa guida è redatta da Armah e descrive anche il suo approccio, non costituisce una selezione indipendente delle agenzie. Un capitolato ben costruito rimane utilizzabile anche per confrontare altre proposte sullo stesso perimetro.

Confrontiamo requisiti e priorità: richiedi l’audit eCommerce oppure descrivi il progetto. Perimetro e attività vanno definiti sul caso concreto.

FAQ

Il capitolato deve indicare la piattaforma?

Solo se esiste un vincolo già motivato. Altrimenti descrivi requisiti e limiti organizzativi e chiedi al fornitore di motivare la soluzione proposta, indicando compromessi e dipendenze.

Quanto deve essere dettagliato il brief?

Quanto basta per capire obiettivi, perimetro, processi e dati disponibili. I dettagli ancora incerti possono essere marcati come da analizzare, evitando di presentarli come requisiti definitivi.

Come gestire funzioni obbligatorie e opzionali?

Assegna priorità esplicite e chiedi una risposta separata per ciascuna funzione. Le opzioni devono avere impatti economici e dipendenze riconoscibili, senza entrare implicitamente nel perimetro iniziale.

Posso usare un capitolato per confrontare agenzia e freelance?

Sì. Il documento deve restare centrato sulle attività e sulle responsabilità. Confronta anche continuità del servizio, copertura delle competenze e modalità di gestione dei sistemi terzi.

Serve allegare dati reali dei clienti?

Di norma è preferibile usare campioni sintetici o anonimizzati adeguati al test. Eventuali dati personali e accessi richiedono cautele, autorizzazioni e accordi appropriati al contesto.

Il capitolato sostituisce il contratto?

No. Aiuta a definire il lavoro, ma condizioni legali, responsabilità, diritti e gestione delle controversie devono essere verificati e formalizzati con i referenti competenti.

Guide correlate

In sintesi 8. Fasi di realizzazione eCommerce Voci di costo e preventivo Requisiti della piattaforma B2B Checklist di migrazione SEO Agenzia o freelance eCommerce

• Fasi di realizzazione eCommerce
• Voci di costo e preventivo
• Requisiti della piattaforma B2B
• Checklist di migrazione SEO
• Agenzia o freelance eCommerce