B2x Commerce e che cosa significa per l'architettura frontend

B2B e B2C non sono più due progetti separati. Sempre più brand vendono a imprese e consumatori dallo stesso catalogo, dallo stesso dominio e, sempre più spesso, dallo stesso storefront. Questa convergenza ha un nome, B2x commerce, e mette sotto pressione una parte dello stack che la maggior parte dei progetti di replatforming tratta come un dettaglio secondario: il frontend. Prezzi specifici per account, ruoli e approvazioni, cataloghi misti e self-service non sono funzionalità backend da attivare con un interruttore. Sono esperienze che vanno composte in superficie, per utente e per sessione.

Che cos'è il B2x commerce?

Il B2x commerce è il modello operativo in cui un solo storefront serve sia i buyer aziendali sia i consumatori finali, senza dividersi in due applicazioni separate. La "x" sta per qualunque cosa il visitatore si riveli essere: un utente anonimo, un consumatore autenticato, un utente del procurement con un contratto negoziato o un rivenditore con prezzi specifici per account. Invece di far convivere uno shop B2C e un portale B2B affiancati, un setup B2x risolve il contesto del buyer a runtime e renderizza il catalogo, i prezzi e le azioni corretti per quel contesto.

Il motivo per cui la cosa conta adesso: il confine tra i due pubblici si è fatto sfumato. I buyer B2B si aspettano il self-service e la velocità che trovano da consumatori privati, e i brand consumer aprono sempre più spesso tier wholesale, pro o a membership. Mantenere due codebase per quello che è in gran parte lo stesso catalogo è costoso, e garantisce che le due esperienze finiscano per divergere.

Perché la logica B2x appartiene al frontend, non al monolite backend

C'è un'ipotesi allettante secondo cui il B2x sarebbe un problema di backend: aggiungi un modulo B2B, attivi i prezzi per account, fatto. Nella pratica, gran parte di ciò che rende funzionante un'esperienza B2x si decide in superficie.

Considera che cosa cambia tra un consumatore e un buyer aziendale sulla stessa identica pagina prodotto:

• Prezzo: prezzo di listino contro prezzo contrattuale legato all'account.
• Disponibilità e unità: singoli pezzi contro quantità per collo o valori minimi d'ordine.
• Azioni: "aggiungi al carrello" contro "richiedi un preventivo", "aggiungi alla lista di approvvigionamento" oppure "invia per approvazione".
• Visibilità del catalogo: alcuni SKU sono riservati ai consumatori, altri sono limitati agli account approvati.
• Navigazione e contenuti: un buyer aziendale vede riordino, budget e centri di costo dove un consumatore vede wishlist e raccomandazioni.

Nessuno di questi elementi è un singolo valore di backend. Sono composti da più fonti contemporaneamente: il backend commerce per il catalogo di base, un servizio di pricing o di contratti per i prezzi specifici dell'account, un identity provider per i ruoli e un content layer per i messaggi. Il frontend è l'unico livello che li vede tutti insieme per un dato utente in una data sessione. Ecco perché la logica B2x va composta lì. Un monolite backend può conservare i dati, ma non può assemblare l'esperienza senza diventare un secondo frontend travestito.

Ruoli e approvazioni sono una questione di sessione

I workflow di approvazione sono l'esempio più chiaro. Se un utente possa concludere il checkout, oppure solo inviare un carrello all'approvazione di un manager, dipende dal ruolo associato alla sua sessione, dal valore del carrello e dalle regole dell'account. Quella decisione cambia la UI in tempo reale: pulsanti, banner e passaggi disponibili. Codificarla in profondità nel backend significa che ogni modifica a una regola di approvazione deve attendere una release backend. Composta nel frontend, contro un'API dei ruoli, la stessa modifica va in produzione con un deployment frontend.

Come un frontend composable gestisce il B2x senza replatforming del backend

La mossa composable per il B2x è la stessa applicata a ricerca, pagamenti e abbonamenti: lasciare i sistemi specialistici dove sono e comporre l'esperienza in un livello frontend disaccoppiato. In concreto:

• Un data layer unificato (tipicamente GraphQL) si colloca davanti al backend commerce, al servizio di pricing o di contratti e all'identity provider, così il frontend interroga un solo endpoint e riceve catalogo, prezzo di account e ruolo in un'unica risposta già risolta.
• Il contesto del buyer (anonimo, consumatore, account aziendale, ruolo) viene risolto per sessione e determina quali componenti vengono renderizzati. Un frontend composable e headless tratta quel contesto come un input di prima classe, non come un caso speciale innestato su un tema B2C.
• Catalogo, pricing e ruoli restano nei rispettivi sistemi. Non devi migrare il backend per ottenere comportamenti B2x; componi sopra il backend che già utilizzi.
• La stessa libreria di componenti renderizza entrambi i pubblici. Una product card, un blocco prezzo o un'azione di carrello diventano context-aware una volta sola, e ogni pagina che li usa eredita il comportamento B2x.

Poiché la logica vive in un livello disaccoppiato, un team può aggiungere un flusso di "richiesta preventivo" o una lista di approvvigionamento allo storefront consumer esistente senza toccare il backend e senza allestire un'applicazione B2B separata. Lo storefront composable è un unico progetto che si comporta in modo diverso a seconda del contesto del buyer, non due progetti cuciti insieme.

Cataloghi misti e self-service in un unico progetto

Due dei requisiti B2x più difficili, cataloghi misti e self-service, mostrano perché il frontend è il posto giusto in cui comporre.

Cataloghi misti significa che lo stesso storefront espone insiemi di prodotti diversi a buyer diversi: SKU per consumatori, SKU riservati alle aziende e SKU limitati a singoli account. Filtrarli solo nel backend porta a varianti API fragili, una per pubblico. Risolta nel frontend rispetto al contesto del buyer, la visibilità del catalogo diventa un parametro di query, e un solo set di componenti di listing e dettaglio copre tutti i casi.

Il self-service, ossia gestione dell'account, storico ordini, riordino, budget e amministrazione utenti, è l'area in cui i clienti B2B passano la maggior parte del tempo, e quella in cui l'esperienza si rompe più spesso quando li si reindirizza a una schermata di amministrazione del backend. Composta nel frontend, l'area account usa gli stessi componenti dello storefront, così il buyer aziendale non esce mai dal tuo brand per gestire il proprio account.

Modulo B2B nativo contro frontend B2x composable

• Dimensione | Modulo B2B nativo nel backend | Frontend B2x composable
• Contesto del buyer | Fisso per store o per sito | Risolto per sessione e per ruolo
• Prezzi specifici per account | Valore backend, controllo limitato sulla visualizzazione | Composto in superficie, con stile completo
• Ruoli e approvazioni | Ciclo di release del backend | Deployment frontend, contro un'API dei ruoli
• Cataloghi misti | Varianti API separate per pubblico | Una query, visibilità guidata dal contesto
• Area self-service | Spesso una schermata di amministrazione del backend | La stessa libreria di componenti dello storefront
• Aggiungere il B2C a un progetto B2B (o viceversa) | Seconda applicazione | Un solo progetto, nuovo contesto

FAQ

Il B2x commerce è semplicemente B2B e B2C sullo stesso dominio? No. Condividere il dominio è la parte facile. B2x significa che un solo storefront risolve il contesto del buyer a runtime e renderizza catalogo, prezzi e azioni corretti per quell'utente, invece di instradarlo verso un'applicazione B2B o B2C separata.

Dobbiamo fare il replatforming del backend per supportare il B2x? No. Il senso di comporre il B2x nel frontend è proprio che catalogo, pricing e identità restano nei loro sistemi attuali. Un data layer unificato li mette insieme e il frontend assembla l'esperienza sopra il backend che già utilizzi.

Da dove arrivano i prezzi specifici per account? Di norma da un servizio di pricing o di contratti separato dal catalogo di base. Il frontend richiede il prezzo risolto per l'account corrente attraverso il data layer unificato e lo renderizza nello stesso componente prezzo che vedono i consumatori, con valori diversi.

Come vengono gestiti i workflow di approvazione? Il ruolo dell'utente e le regole dell'account vengono risolti per sessione. Il frontend li legge da un'API dei ruoli e adatta in tempo reale le azioni disponibili, checkout oppure invio per approvazione. Le modifiche alle regole vanno in produzione come deployment frontend, non come release backend.

Possiamo partire dal B2C e aggiungere il B2B più avanti? Sì, ed è questo il vantaggio principale. Poiché il contesto del buyer è un input di prima classe per il frontend, aggiungere un tier aziendale significa aggiungere un contesto e i suoi componenti, non costruire un secondo storefront.

Altro dalla Laioutr Platform

• Composable Headless Frontend: il livello disaccoppiato in cui contesto del buyer, pricing e ruoli vengono composti in un'unica esperienza.
• Composable Storefront: un unico progetto che renderizza sia i buyer aziendali sia i consumatori, senza dividersi in due applicazioni.
• Frontend as a Service: come il livello frontend viene gestito e distribuito in modo indipendente dal backend commerce.
• Agentic Frontend Management Platform: come le modifiche di routine a regole di contesto e componenti possono essere gestite con agenti AI.

Prossimo passo

Vuoi vedere come apparirebbe la tua logica B2x, prezzi per account, ruoli, cataloghi misti e self-service, composta in un frontend disaccoppiato? Parla con il team Laioutr e la mapperemo sul backend che già utilizzi.