Portale ordini B2B: guida allo sviluppo software

Un portale ordini B2B permette ai clienti approvati di vedere il proprio catalogo e i prezzi concordati, di effettuare e ripetere ordini e di seguire i documenti, il tutto sincronizzato con l'ERP. Delimitatelo per fasi: prima account, prezzi e ordini, poi pagamenti e approvazioni — un portale che prova a partire completo di solito parte in ritardo e viene usato per metà.

Cos'è un portale ordini B2B?

Un portale ordini B2B è un canale web con il vostro marchio in cui distributori e clienti commerciali approvati accedono e fanno affari da soli: sfogliano il catalogo visibile al proprio account, vedono i prezzi concordati con loro, compongono un ordine o ripetono uno precedente e trovano i documenti che appartengono al loro account — preventivi, ordini, fatture, note di credito, consegne. L'ERP resta il sistema di record; il portale è la finestra su di esso, con regole su cosa ogni account può vedere e fare.

Vale la pena separare il portale da tre vicini con cui viene spesso confuso:

Un e-commerce al dettaglio. Prezzi al pubblico, registrazione aperta, pagamento con carta al checkout. Un portale per distributori è l'opposto: l'accesso si concede per account, i prezzi sono contrattuali e il pagamento segue le condizioni concordate anziché un checkout.

L'area clienti di un sito di marketing. Utile per download e richieste di assistenza, ma senza logica di catalogo, prezzi e ordini non toglie una singola chiamata al servizio vendite.

Un listino prezzi in PDF via posta. Lo stato in cui vive la maggior parte dei distributori prima di un portale: corretto il giorno in cui viene inviato, sbagliato la settimana dopo e non ricercabile per account.

Ciò che fa di questo un progetto anziché un sito web è l'integrazione: il catalogo, i listini, la posizione di credito e i documenti aperti vivono tutti nei sistemi che già fanno girare l'azienda, e il portale deve metterci d'accordo per account, per valuta e per momento. Le sezioni qui sotto trattano questo come la domanda di ambito centrale, non come un dettaglio tecnico, perché la maggior parte dei progetti di portale deludenti è fallita su quell'accordo, non sulla progettazione.

Per discutere l'ambito del vostro portale, richiedete un preventivo.

Tabella delle funzionalità: indispensabili, utili, differibili

Le pagine funzionalità dei fornitori elencano tutto in una volta. La delimitazione per fasi è ciò che tiene il primo rilascio consegnabile. La tabella ordina le funzionalità ricorrenti in ciò che serve al primo rilascio, ciò che il secondo di solito aggiunge e ciò che può aspettare dati d'uso reali:

Tabella A: funzionalità | scopo | fase (1/2/3) | dipendenza ERP

Funzionalità	Scopo	Fase	Dipendenza ERP
Account cliente e accesso	Ogni distributore vede solo i propri dati	1	Account e contatti
Listini per account	Prezzi contrattuali, gruppi prezzi o prezzi a livelli per account	1	Listini e gruppi prezzi
Catalogo con visibilità per account	Prodotti che ogni account può acquistare, con documenti e immagini	1	Anagrafica prodotti, regole account-prodotto
Ordine rapido e riordino	Numeri articolo, CSV o modulo di caricamento, ripetizione dell'ultimo ordine	1	Anagrafica prodotti, regole di ordine minimo
Invio dell'ordine all'ERP	L'ordine diventa un documento ERP, non una e-mail	1	API ordini o canale di integrazione
Stato ordini e visibilità documentale	Fatture, note di credito, consegne visibili per account	2	Archivio documenti o sistema amministrativo
Preventivi e da preventivo a ordine	Richiesta di prezzo, approvazione, conversione in ordine	2	Documenti preventivo nell'ERP
Limiti di credito e condizioni di pagamento netto	Mostra all'account la sua posizione e le sue condizioni; blocca l'invio dell'ordine fuori regole	2	Dati credito e condizioni nell'ERP
Pagamenti nel portale	Regolamento online contro fatture o ordini	3	Gateway di pagamento più riconciliazione ERP
Ruoli di approvazione ordine	Il proponente propone, l'approvatore rilascia, limiti per ruolo	3	Dati di approvazione o flusso lato portale
Catalogo e documenti multilingue	Lingua commerciale per mercato o per account	3	Traduzioni prodotto, modelli di documento
Tracking e notifiche di spedizione	Stato della spedizione senza chiamare il servizio vendite	3	Dati logistici o di trasporto

La fase 1 è il rilascio che cambia il comportamento: se un distributore può accedere, vedere i propri prezzi, ripetere l'ordine del mese scorso e farlo entrare nell'ERP, il canale telefono e foglio di calcolo inizia a chiudersi da solo. Le fasi 2 e 3 aggiungono gli strati di denaro e governance, che richiedono che le decisioni aziendali su credito, finanza e approvazioni siano prese prima che il software possa sostenerle.

Integrazione con ERP e CRM

L'integrazione decide se il portale è uno specchio dell'attività o una brochure con un accesso. Quattro domande richiedono risposte scritte prima di scegliere qualsiasi architettura:

Direzione della sincronizzazione. I dati anagrafici — account, prodotti, prezzi, condizioni — fluiscono dall'ERP al portale. Ordini, richieste di preventivo e pagamenti fluiscono all'indietro. Qualsiasi altra cosa richiede un responsabile esplicito: chi può modificare un prezzo e dove vive quella modifica?

Frequenza di sincronizzazione. Lotti notturni, aggiornamento periodico durante la giornata o quasi in tempo reale. La regola onesta: prezzi e posizione di credito giustificano una sincronizzazione più frequente delle immagini dei prodotti, quindi una strategia mista è normale — i dati critici più spesso, i contenuti di catalogo meno spesso.

Gestione dei guasti. Quando l'ERP è fuori servizio o un record non supera la validazione, cosa fa il portale: mette in coda, rifiuta, oppure mostra l'ultimo stato noto con un avviso chiaro? Il guasto silenzioso è il modo in cui un distributore finisce per ordinare al prezzo della settimana scorsa, che diventa una vostra contestazione, non la sua.

Riconciliazione. Come fate a sapere che ogni ordine del portale è diventato esattamente un documento ERP — niente duplicati, niente buchi, niente record a metà convertiti? La risposta è un report operativo che qualcuno legge ogni giorno nei primi mesi, ed è uno dei test di accettazione qui sotto.

Due schemi di distribuzione coprono la maggior parte dei progetti. Il percorso nativo ERP costruisce il portale come estensione delle capacità stesse dell'ERP, il che minimizza il numero di sistemi che devono mettersi d'accordo ma ne eredita i limiti di front-end. Il percorso piattaforma fa girare una piattaforma commerciale — Shopify e sistemi simili sono gli esempi usuali nei materiali dei fornitori — e la collega all'ERP tramite middleware o connettori; quel percorso compra flessibilità di front-end e un'interfaccia di amministrazione familiare al costo di un sistema in più da tenere sincronizzato. La pagina sul confronto tra ERP su misura e pacchetto tratta la versione più ampia di questa domanda costruire o acquistare, e la checklist RFP per fornitori trasforma entrambe le opzioni in domande che potete punteggiare in una proposta.

Cataloghi multilingue e multi-valuta

Gli esportatori incontrano entrambe le domande presto, e costa meno deciderle che aggiungerle dopo.

Lingue. Il catalogo richiede traduzioni per nomi di prodotto, categorie e documenti; la struttura account richiede una preferenza linguistica per account affinché il portale non chieda allo stesso acquirente di scegliere a ogni visita. Due punti pratici: decidete chi possiede le traduzioni e il loro ritmo di aggiornamento — un catalogo tradotto a metà si legge peggio di uno solo in inglese per l'acquirente che se ne accorge — e decidete se i documenti (preventivi, fatture) seguono la lingua dell'interfaccia o restano nella lingua che il vostro sistema amministrativo richiede. La seconda domanda non è tecnica: una fattura nella lingua sbagliata è un problema contabile.

Valute. I prezzi concordati in una valuta vanno mostrati in quella valuta a prescindere dalla posizione del visitatore; mescolare valute di visualizzazione con quelle contrattuali è il modo in cui iniziano le contestazioni. Se un account opera in più di una valuta, la regola deve vivere nei dati dell'ERP, non nelle impostazioni del portale, e il portale non deve mai essere il posto in cui si inventa una conversione.

Entrambi i temi interagiscono con il piano a fasi: un esportatore che vende in tre mercati può lanciare la fase 1 nelle lingue che quei tre mercati usano davvero negli ordini e aggiungere altre lingue di catalogo man mano che il mercato cresce. La regola generale per il lavoro linguistico sui siti commerciali — un responsabile, un file sorgente, un percorso di aggiornamento — è descritta nella pagina di internet marketing, e vale per un catalogo di portale nello stesso modo.

Sicurezza e ruoli

Un portale è una porta sui vostri dati commerciali, quindi le domande di progetto sono domande di accesso:

L'accesso si concede, non si autoregistra. Ogni account è creato dal vostro team su un account ERP; l'alternativa — registrazione aperta con un passaggio di approvazione — attira rumore e confonde chi è cliente.

Permessi basati su ruoli. Un acquirente può comporre e inviare ordini entro un limite; un approvatore può rilasciarli; un lettore può solo leggere i documenti. I limiti per ruolo fanno parte delle condizioni commerciali, non sono un'aggiunta tecnica a posteriori — codificano chi nell'organizzazione del vostro cliente può impegnarlo.

Isolamento dell'account. La modalità di guasto più grave in questa categoria di prodotto è un distributore che vede i prezzi o i documenti di un altro. La visibilità dei dati per account va testata esplicitamente, ed è uno dei test di accettazione qui sotto.

Traccia di audit. Chi ha posto l'ordine, chi l'ha approvato, chi ha modificato un prezzo e quando — conservata come dato, non come file di log che qualcuno va convinto a leggere. Le contestazioni nel commercio si risolvono con questa traccia più spesso che con la memoria.

Identità e accesso unico. Per i distributori più grandi, il SSO sulla propria directory è un requisito frequente che vale la pena delimitare tardi anziché presto — la maggior parte degli account vive felicemente di inviti e password finché una sede centrale non chiede la federazione.

Protezione dei dati. I dati dei clienti nel portale rientrano negli stessi doveri che l'azienda già ha per i propri registri clienti; per le operazioni turche è il quadro KVKK, per i clienti europei il GDPR, un tema trattato nel dettaglio nella pagina sull'outsourcing IT nel contesto del lavoro con un partner di sviluppo.

Sviluppo su misura o piattaforma

La scelta non è tra su misura e confezionato in astratto; riguarda quale livello state comprando davvero.

Tabella B: percorso | cosa ottenete | cosa portate | adatto quando

Percorso	Cosa ottenete	Cosa portate	Adatto quando
Portale nativo ERP	Un solo sistema di record, prezzi e credito già coerenti, meno interfacce	Front-end e mobilità limitati dalle capacità stesse dell'ERP; i cicli di rilascio dell'ERP governano il portale	L'ERP è moderno, il suo modulo portale copre gran parte della fase 1 e l'IT interno può amministrarlo
Piattaforma commerciale + connettore ERP	Amministrazione familiare, buona esperienza di front-end e mobile, lavorazione del catalogo rapida	Un secondo sistema da tenere sincronizzato; manutenzione del connettore; due percorsi di aggiornamento	L'esperienza d'acquisto conta quanto i dati e qualcuno possiede l'integrazione nel lungo periodo
Portale su misura	Adesione esatta alle regole commerciali, incluse quelle bizzarre che definiscono il vostro commercio	Responsabilità piena: sicurezza, prestazioni, aggiornamenti, l'intero ciclo di vita	Il processo differenzia davvero l'attività e nessuna piattaforma lo regge — il test è se una funzionalità standard più un cambiamento di processo potrebbe bastare

Il percorso intermedio è scelto dalla maggior parte degli esportatori la prima volta, e l'errore da evitare è trattarlo come quello economico: un connettore è un prodotto mantenuto, e il suo costo è ricorrente. Il quadro decisionale per questa domanda — configurare, acquistare o costruire — è ampiamente trattato nella pagina sul confronto tra ERP su misura e pacchetto; ciò che questa pagina aggiunge è il test specifico del portale: qualunque scegliate, il listino per account e l'ordine nell'ERP devono essere provabilmente corretti, e il percorso che scegliete dovrebbe essere quello che lo rende provabile al costo ricorrente più basso.

Rilascio per fasi e test di accettazione

Un lancio di portale fallisce in silenzio quando «funziona» significa «ha funzionato la demo». Ogni fase dovrebbe portare test di accettazione scritti, eseguiti con account reali e dati reali:

Visibilità del catalogo per account. Accedete come due distributori diversi; ciascuno vede esattamente il proprio insieme di prodotti e nessuna traccia di quell'altro. Testato deliberatamente, non dato per scontato.

Correttezza dei prezzi. Per un campione di account e articoli, il prezzo del portale è uguale al prezzo dell'ERP — incluse le regole che lo sostengono (gruppo prezzi, livello, accordo). È il test che protegge la relazione commerciale; un prezzo sbagliato in un portale è peggio di un prezzo sbagliato in un preventivo, perché il cliente l'ha visto come l'accordo vigente.

Integrità dell'ordine. Un ordine collocato nel portale diventa esattamente un documento ERP, con articoli, quantità, unità e prezzi corretti — e il report di riconciliazione lo mostra. Testate anche il percorso di guasto: un ordine bloccato da una regola dovrebbe dirlo chiaramente anziché fallire in silenzio.

Stato e documenti. Una fattura e una consegna registrate nell'ERP compaiono nella vista portale dell'account giusto, con lo stato giusto, entro la finestra di sincronizzazione concordata.

Condizioni e limiti. Credito e condizioni di pagamento per account si visualizzano correttamente e, dove le regole dicono che un ordine va bloccato o segnalato, viene bloccato o segnalato — testato al confine, non nel comodo mezzo.

Le abitudini quotidiane. Riordino, ordine rapido per numero articolo e ricerca — con due listini prodotto dei vostri distributori reali, non il catalogo demo. L'adozione vive o muore su questi tre percorsi, e costano una frazione della costruzione per testarli a dovere.

L'ordine di rilascio conta quanto i test: prima un mercato pilota o un pugno di account, il loro feedback incorporato, poi un'apertura più ampia. L'alternativa — un annuncio di lancio a ogni distributore lo stesso giorno — converte le prime settimane di correzioni inevitabili in un costo di credibilità, e i distributori che trovano un prezzo sbagliato nella prima settimana tornano spesso al telefono per mesi dopo. La logica del pilota è quella descritta per gli incarichi di software nella pagina sull'outsourcing IT, e la disciplina di valutazione per i team che costruiscono portali sta nella checklist RFP.

Domande frequenti

Ci serve prima un ERP?

Non un nuovo — ma servono i dati anagrafici in un posto affidabile: account, prodotti, listini e condizioni. Se vivono solo nei fogli di calcolo, il portale automatizzerà gli errori del foglio per account, il che è peggio che restare al telefono. In quel caso la sequenza onesta è prima stabilizzare i dati (spesso in un ERP esistente sottoutilizzato), poi il portale; la pagina su Odoo per aziende di trading tratta quella decisione dal lato ERP.

I clienti possono avere listini propri?

Sì — la formazione dei prezzi per account è il cuore della categoria di prodotto, non un extra: gruppi prezzi, prezzi a livelli o accordi individuali, tutti tenuti nell'ERP e mostrati per account. La regola su cui insistere è che il portale non prezza mai nulla da solo; mostra ciò che l'ERP detiene, e ogni prezzo che un distributore vede è rintracciabile a un accordo che il vostro team ha fatto.

Come vengono approvati gli ordini?

Di solito due strati. Dentro l'organizzazione del cliente, l'approvazione è sua: un acquirente propone, un approvatore rilascia, facoltativamente entro limiti — il portale può portare quei ruoli nella fase 3. Dentro la vostra organizzazione, l'ordine arriva nell'ERP e segue il vostro normale trattamento degli ordini; il portale non sostituisce i controlli del vostro servizio vendite, rimuove il reinserimento e la telefonata attorno ad essi.

Il portale può gestire più lingue?

Sì, e dovrebbe — ma delimitate l'ambito per fase. Traduzioni del catalogo, preferenza linguistica per account e documenti tradotti sono tre lavori diversi; lanciate la fase 1 nelle lingue che i vostri mercati attivi usano negli ordini e aggiungete le altre con la domanda reale. I punti di governance — un responsabile per le traduzioni, un percorso di aggiornamento — sono nella sezione multilingue qui sopra.

Chi possiede i dati?

Voi — account, prezzi, ordini, documenti e storico restano i registri dell'azienda, nell'ERP. Vale la pena dirlo nel contratto con chi costruisce il portale: accesso all'hosting, codice sorgente o configurazione, ed esportazione dei vostri dati all'uscita, tutto nominato. La pagina sull'outsourcing IT copre proprietà intellettuale e termini di uscita nel contesto più ampio del contratto di sviluppo.

Come si inseriscono i distributori?

Partite dagli account che ordinano di più, invitateli personalmente e date loro tre cose nel primo messaggio: il loro accesso, il loro listino visibile a schermo e una persona da chiamare. Poi osservate il segnale di adozione che conta davvero — non gli accessi, ma la quota di volume di riordino che arriva attraverso il portale. Il lavoro in parallelo (ordinato dal portale, poi confermato per telefono) è normale per settimane; finisce quando il portale è provabilmente corretto su prezzi e documenti, ed è a quello che servono i test di accettazione qui sopra.

Fonti e norme

L'insieme tipico di funzionalità descritto qui (account, listini per account, riordino, fatture e note di credito, visibilità per account, ruoli con limiti, condizioni nette, gateway di pagamento) segue gli elenchi di capacità descritti dai fornitori per i portali ordini B2B in generale; in questa pagina non viene rivendicato alcun esito prestazionale, costo o tempistica.
I schemi di distribuzione (portale nativo ERP; piattaforma commerciale come Shopify sincronizzata all'ERP tramite middleware o connettori) sono descritti come i due percorsi ricorrenti; non viene rivendicata alcuna partnership con fornitore di piattaforme.
Le affermazioni di processo e governance seguono le pagine di questo sito: ERP su misura versus pacchetto, checklist RFP per fornitori, Odoo per aziende di trading e outsourcing IT dalla Turchia (doveri di protezione dei dati, proprietà intellettuale e termini di uscita, progettazione del pilota).
In questa pagina non compaiono esempi di clienti, budget di portale o durate di progetto; ambito, fasi e condizioni commerciali si fissano per progetto nel preventivo.

Pagine correlate

Sviluppo software · ERP su misura versus pacchetto · Checklist RFP per fornitori · Odoo ERP per aziende di trading · Internet marketing · Richiedi un preventivo