— Caso / Marketplace Discovery
Marketplace multi-vendorinternazionale
- Repubblica Ceca
- App mobile + sito web
- e-commerce / marketplace-tech B2B2C
Fase di Discovery completa: da obiettivi di business e mappa degli stakeholder a SRS, requisiti non funzionali, mappa delle integrazioni e UX flow dell’app dell’acquirente.
— Descrizione sintetica
Fase di Discovery per un marketplace di nuovo tipo
Un progetto completo di business analysis e definizione dei requisiti per un marketplace multi-vendor (sito web + app mobile), rivolto al mercato europeo, che riunisce acquirenti e venditori di diversi paesi in un unico spazio. Il team ha portato a termine l’intera fase di Discovery: dagli obiettivi di business e dalla mappa degli stakeholder alla documentazione dettagliata, ai requisiti non funzionali, alla mappa delle integrazioni e allo UX flow dell’app dell’acquirente.
Il cliente entra nel mercato non con l’ennesimo negozio online, ma con un ecosistema ibrido in cui le vendite dirette della piattaforma e quelle di centinaia di venditori indipendenti convivono sotto lo stesso tetto. Il progetto è pronto all’avvio dello sviluppo, con scope MVP, budget e roadmap chiaramente definiti.
— Sfida
Cosa formalizzare prima dell’avvio dello sviluppo
01
Modello di business ibrido. La piattaforma vende prodotti a proprio nome e fornisce uno strumento di vendita a venditori terzi — serve una logica separata di contabilità, logistica e commissioni per due venditori profondamente diversi sulla stessa vetrina.
02
Logistica complessa. Il modello target è un unico pacco da più negozi: un ordine con prodotti di più venditori e paesi viene consegnato in un’unica spedizione, per ridurre i costi ed evitare di perdere conversioni su spedizioni multiple.
03
Due tipologie di venditori con regole diverse. I venditori individuali sono persone fisiche con assortimento limitato e pagamento in percentuale sulle vendite; i professionali sono persone giuridiche con assortimento illimitato, canone fisso, analisi e integrazioni.
04
Fiducia e protezione dalle frodi. Sistema trasparente di recensioni e rating per gli acquirenti, verifica KYC/KYB dei venditori prima delle vendite e protezione del programma referral dalle registrazioni fittizie.
05
Perimetro normativo UE denso. GDPR, ePrivacy, PSD2/SCA, DSA, VAT/OSS, AML/KYC e il diritto nazionale dei consumatori andavano incorporati nell’architettura di dati e processi fin dall’inizio.
— Soluzione
Una sequenza di artefatti di business analysis
Business analysis e requisiti per ruolo
- 7 obiettivi di business: dall’ingresso nel mercato target e dall’ottimizzazione della logistica secondo il modello un unico pacco alla conformità UE, redditività e scalabilità
- 28 requisiti formalizzati — separatamente per acquirenti, venditori, team operativo e partner esterni: banche, logistica, enti regolatori
- Acquirente: autenticazione via email, Google, Facebook e telefono, profilo con indirizzi e carte, catalogo con filtri e confronto, checkout con codici promo, resi, bot di messaggistica e notifiche
- Venditore: registrazione con caricamento documenti e verifica KYC, prodotti a mano, con caricamento massivo CSV/Excel o via sincronizzazione API con il proprio ERP/CMS, ordini, saldo, commissioni e pagamenti
- Manager: moderazione di venditori e contenuti, gestione di categorie e promozioni, comunicazione con venditori e utenti
- Amministratore: diritti di accesso e RBAC, configurazione commissioni, programma referral, analisi consolidata di vendite, traffico e ricavi, 2FA e log attività
Requisiti non funzionali, integrazioni e architettura
- 7 domini NFR: disponibilità e tolleranza ai guasti, prestazioni e scalabilità, manutenibilità e SLA, conformità, localizzazione e cross-platform, estensibilità, usabilità e sicurezza
- Documento di conformità per il mercato UE: GDPR, ePrivacy, PSD2/SCA, DSA, VAT/OSS, AML/KYC e diritto nazionale dei consumatori
- Circa 30 integrazioni e servizi esterni in 10 domini funzionali — per ciascuna è indicato se rientra nell’MVP
- Circuito dei pagamenti: acquiring, Apple/Google Pay, PSD2/SCA, split payments e marketplace payouts, API di rimborso, fiscalizzazione e gestione documentale
- Logistica e comunicazione: integrazione con il magazzino, tracking e stati di consegna, notifiche, messenger in-app e chatbot, moderazione AI dei contenuti
- Diagramma di contesto del sistema — un’unica fonte di verità per il team di sviluppo sui confini esterni
- Roadmap di pre-sviluppo: definizione dello scope, scelta della tecnologia e del deployment, checkpoint, composizione del team, stima del budget e sincronizzazione con il team di design
— Risultati
Cosa è stato consegnato allo sviluppo
- 7
- obiettivi di business
- 28
- requisiti stakeholder
- 4
- ruoli utente nella SRS
- 28
- regole di business
- ~30
- integrazioni in 10 domini
- 7
- domini normativi UE
- 7 obiettivi di business e 28 requisiti degli stakeholder formalizzati, consolidati dalle richieste sparse del cliente in un unico documento.
- Una SRS completa per 4 ruoli utente, con MVP e versione completa del prodotto elaborati separatamente.
- 28 regole di business formalizzate: limiti sui prodotti, tempistiche di verifica e pagamento, limiti su carrello e resi, politiche finanziarie e di sicurezza.
- Circa 30 integrazioni e servizi esterni, distribuiti su 10 domini funzionali, ciascuno marcato esplicitamente MVP / non-MVP.
- Diagramma di contesto del sistema e intero user flow end-to-end dell’app mobile dell’acquirente.
- Un documento di conformità per 7 domini normativi UE e la legislazione nazionale.
— Particolarità
Cosa è stato atipico
Modello 1P + 3P
La piattaforma vende a proprio nome e insieme funziona come marketplace per venditori terzi — contabilità, logistica e commissioni separate per due tipi di venditore sulla stessa vetrina.
Un pacco da più negozi
Consolidamento di prodotti di più venditori e paesi in un’unica spedizione all’acquirente — architettura logistica atipica per l’e-commerce standard.
Verifica da fintech
Quattro fasi per il venditore professionale: dati aziendali → identità del titolare con passaporto e selfie → dati di negozio e brand → verifica finale.
Split payments e payouts
Pagamenti ai venditori con periodicità configurabile — 14, 30 o 90 giorni — e generazione automatica delle fatture.
Uptime da calendario
Le date di picco sono elencate esplicitamente — Natale, Capodanno, Pasqua, Black Friday — con test di carico per ≥600 utenti simultanei prima del lancio.
— Conclusione
Il team ha accompagnato il cliente da un insieme di idee e richieste sparse a un pacchetto documentale completo, pronto per lo sviluppo.
Requisiti di business e degli stakeholder, SRS dettagliata per quattro ruoli, requisiti non funzionali e conformità normativa per il mercato UE, mappa delle integrazioni, architettura di contesto del sistema e UX elaborato dell’app mobile dell’acquirente — con MVP e roadmap chiaramente definiti.