B2B-ehandel på Norce: prislistor, punchout och kundunika sortiment i praktiken

Det är lätt att ta B2C-ehandeln för given. En produkt, ett pris, en kundvagn, en check-out. B2B fungerar inte så. Priset beror på vem som frågar, sortimentet beror på avtalet, betalvillkoren beror på kreditgränsen — och orderflödet passerar ofta genom ett Coupa eller SAP Ariba innan det landar hos er. Vi har byggt det här på Norce Commerce i tillräckligt många projekt för att veta var det tar tid och var det inte gör det. Det här är en pragmatisk genomgång — kontostruktur, prislistor, kundunika sortiment, punchout och de kompromisser som faktiskt uppstår i implementationen.

Vad B2B faktiskt kräver — och varför generiska plattformar gör det svårt

B2B-ehandeln lider av en förväxling. Många plattformar säljs som "B2B-fähiga" när de i själva verket är B2C-plattformar med en inloggningsspärr framför. Det räcker sällan. En seriös B2B-lösning måste hantera fyra saker samtidigt, och de påverkar varandra på ett sätt som gör dem svåra att bolta på efteråt.

• Hierarkisk kontostruktur — moderbolag, dotterbolag, filialer, kostnadsställen. Priser, sortiment och kreditgränser ska ärva nedåt men kunna åsidosättas lokalt.

• Kundunikt pris — listpris, avtalspris, kampanjpris, staffelpris och tillfälliga rabatter behöver kunna räknas i rätt ordning i realtid.

• Kundunikt sortiment — kund A ska aldrig se produkter som bara får säljas till kund B. Ibland av juridiska skäl, ibland av kommersiella.

• Integration mot inköpssystem — punchout via cXML eller OCI mot SAP Ariba, Coupa, Jaggaer eller motsvarande, plus EDI-flöden för order- och fakturasvar.

Norce Commerce är byggd runt de här kraven från början. Det märks i datamodellen — pricing, accounts och assortments är förstaklassiga begrepp, inte tilläggsmoduler. Det är också därför vi ofta hamnar där när kunden har större B2B-ambitioner än vad en Shopify Plus- eller Adobe Commerce-implementation vill bära.

Kontostruktur i Norce: hierarkier som speglar hur inköp faktiskt fungerar

Företagskund i Norce är inte samma sak som en användare med företagsflagga. Det är en egen entitet — Company — som binder samman användare, adresser, kreditgränser, betalningsvillkor och prislistor. Företag kan grupperas i CompanyGroups, och rabatter kan sättas på gruppnivå och ärvas ned till enskilda företag enligt Norces dokumentation för företagsrabatt. Det gör att man i praktiken bygger en två- eller trelagerspyramid utan att man behöver skriva egen kod för att hålla ihop den.

I ett typiskt införande ser rollerna ut ungefär så här:

1. Företagsadministratör — kan lägga upp och avaktivera användare i sitt bolag, sätta beställningsgränser per person, och ibland godkänna orderförslag innan de går vidare.

2. Inköpare — handlar i eget namn men på företagets villkor. Ser företagets priser, sortiment och leveransadresser.

3. Beställare — får bara plocka från en förutbestämd inköpslista eller ett godkänt sortiment. Ofta i punchout-flödet från ett inköpssystem.

Där generiska B2C-plattformar tvingar en att modellera det här via customer groups och egen affärslogik i frontend, så finns det som fält i Norce-modellen. Fördelen är att kreditgränsen sitter på Company — inte på användaren — och räknas ner mot faktiska öppna order oavsett vilken kanal ordern kom in via. Det är sådant som är trivialt när det finns i plattformen och obehagligt komplext när det inte gör det.

Prislistor: från listpris till kundunikt kontraktspris

Prissättning är där B2B-plattformar visar sin arkitektur mest brutalt. I Norce är prislistor en förstaklassig entitet: en prislista har giltighetstider, valuta, en uppsättning priser per produkt och kan kopplas till en klient, ett företag, ett segment eller en enskild användare, se Norces prislistedokumentation. Systemet stödjer dessutom virtuella prislistor som räknas ut i realtid vid varje API-anrop — användbart när kontraktet säger "listpris minus 8 %" och man inte vill materialisera hela listan varje natt.

I praktiken behöver de flesta B2B-implementationer stapla flera prisregler i en bestämd ordning. Norce prissättningsmodell räknar dem enligt en dokumenterad prioritet — se Norces dokumenterade prioritetsordning för prisregler, men den ordningen är också där diskussionerna uppstår i affärsprojekten. Vår standardrekommendation ser ut så här:

• Baspris från ERP eller PIM — sanningskällan för listpris, importerat via SkuPriceList-integrationen.

• Segmentprislista — grov indelning i typ "återförsäljare", "installatör", "offentlig sektor".

• Kundunik prislista — där avtalsrabatten faktiskt bor, ofta som virtuell prislista mot listpris.

• Kampanjpris — tidsbegränsat, dokumentativt separerat från avtalspriset så att kampanjen inte spiller in i årsavstämningen.

• Kvantitetsstege — staffelpriser när volymen passerar tröskeln, räknat på radnivå i kundvagnen.

Kompromissen som brukar överraska: virtuella prislistor kostar responstid. Räknar man vid varje request behöver katalogsidor och sökträffar batcha prisberäkningarna, annars märks det på laddningstiden. I en av våra senaste implementationer löste vi det med aggressiv cachning per (produkt × företag) i en Redis-lager framför Norce API. Rätt hanterat är det oproblematiskt. Fel hanterat blir katalogsidan trög.

Kundunika sortiment: vem får se vad, och varför det är svårare än priset

Sortimentsstyrning är den delen av B2B som ser enkel ut på whiteboarden och blir jobbig i produktion. Kundunika sortiment är regeln i seriös partnerhandel — en distributör får sälja vissa varumärken i vissa geografier, en OEM får se sina komponenter men inte konkurrentens, en offentlig upphandling har en tvingande sortimentsvidd. Det räcker inte att gömma produkter i frontend. De ska bort ur sökindex, ur relaterade produkter, ur kampanjmoduler och ur exportfilerna för prisjämförelse.

I Norce hanteras det via Assortments — samlingar av produkter som kan tilldelas kanaler, företag och företagsgrupper. En produkt kan finnas i flera sortiment samtidigt, och sökindexeringen respekterar sortimentsfiltret när man autentiserar sig. I praktiken sätter vi upp det så här:

1. Ett basassortiment per kanal — det som en "vanlig" B2B-inloggad kund ser.

2. Exklusionssortiment — produkter som ska döljas för en specifik kundgrupp, till exempel privatimport eller konkurrerande varumärken.

3. Kundunikt tillägg — särskilda kontraktsartiklar, förhandlade paket eller white-label-produkter som bara syns för en enskild kund.

Fällan här är sökmotorn. Om man kör Algolia eller Elasticsearch framför Norce måste sortimentet in i indexet som filtrerbart attribut, inte hanteras post-hoc i applikationslagret. Post-hoc-filtrering ger inkonsistenta fasetter — kunden ser "25 träffar" men bara 12 produkter listas, vilket väcker frågor du inte vill svara på i en avtalsförhandling.

Punchout och integration mot inköpssystem

Föreställ dig att du är inköpare på ett större industribolag. Du loggar in i Coupa, söker efter en komponent, klickar dig vidare till leverantörens katalog, plockar det du behöver, skickar tillbaka kundvagnen till Coupa, får den godkänd av chefen, och först då skickas ordern faktiskt vidare till leverantören. Det är punchout. Det är också där en stor del av volymen i mogen B2B ligger — och det är oftast en förutsättning för att över huvud taget få handla med de stora industribolagen och den offentliga sektorn.

Norce har inte en klick-och-klar-integration mot varje inköpssystem, men den datamodell och de API:er som krävs finns på plats. Två protokoll dominerar och Norce används i produktion mot båda:

• cXML — de facto-standard mot SAP Ariba, Coupa, Jaggaer och de flesta amerikanska plattformar. Setup-request, PunchOutOrderMessage och orderrequest i standardiserat XML-format.

• OCI — SAP:s ursprungliga protokoll, fortfarande vanligt i tysk och nordisk industri där en betydande del av kunderna kör SAP S/4HANA. Enklare men mer begränsat än cXML.

Vi bygger vanligtvis punchout-integrationen som ett mellanlager mellan inköpssystemet och Norce Storefront API. Mellanlagret översätter setup-anropet till en autentiserad session i Norce, kopplar användaren till rätt Company (vilket triggar rätt prislista och rätt sortiment automatiskt), och konverterar den returnerade kundvagnen till PunchOutOrderMessage. Ett kärnkrav som är lätt att missa: sessionens giltighetstid måste matcha inköpssystemets tokenlivslängd, annars får du kunder som återvänder till en död kundvagn efter godkännandeflödet.

På orderns väg tillbaka är EDI oftast bättre än cXML för själva orderöverföringen. Order-, orderbekräftelse-, leveransavisering- och fakturaflödet kör vi typiskt via en integrationsplattform (Nshift, Pagero eller något liknande) med Norce som orderproducent. Det gör att B2B-affären ryms i samma flöde som EDI-kunderna som aldrig loggar in på webben — och det finns fler av dem än folk minns.

Norce vs. Litium vs. Optimizely: var de faktiskt skiljer sig

Vi har ingen fanatisk plattformslojalitet. Vi bygger mest på Norce, men vi ser plattformslandskapet från nära håll och har jämfört Norce mot Litium och Optimizely i tillräckligt många utvärderingar för att veta var de faktiskt skiljer sig. De tre är alla trovärdiga val för nordisk B2B, men de gör olika saker olika bra.

• Prismodellen: Norce har den mest expressiva out-of-the-box, med virtuella prislistor som räknas realtid. Litium har starkt stöd för prisregler men förutsätter oftare materialisering. Optimizely (tidigare Insite) har en pragmatisk B2B-modell men fördelen försvinner om ni redan står med ett stort Insite-arv att förvalta.

• Kontohierarki: Norce och Optimizely B2B har det som förstaklassig modell. Litium kräver mer eget arbete för trelagershierarkier med kostnadsställen, särskilt när kreditgränsen ska räknas mot öppna order i realtid.

• Punchout: Ingen av dem har färdig one-click-integration. Optimizely har flest referenser mot SAP Ariba på grund av sin amerikanska historia, Norce är närmast till hands för nordisk industri där kunderna är blandade cXML/OCI/EDI, Litium är ok om ni själva bygger mellanlagret.

• Composable-vänlighet: Norce är API-first och passar en headless-arkitektur med Storyblok som CMS och egen frontend. Litium är mest monolit — det är inte fel, men det bygger på ett annat val. Optimizely gör båda men blir ofta tungt när man kombinerar dem.

• Totalkostnad över tre år: Norce landar oftast lägst för nordisk B2B med mindre marknader och kataloger. Litium konkurrerar bra på mellansegmentet. Optimizely tar täten när ni behöver deras marketingsvit i samma stack.

Solteq konstaterar i sin Nordic eCommerce Trend Report 2026 att personalisering är standardförväntan för B2B lika mycket som B2C, och att AI-drivna beslutsflöden blir kritiska under 2026, enligt Solteqs Nordic eCommerce Trend Report 2026. Det är egentligen samma poäng vi gör mer prosaiskt: om plattformen inte kan säga vem kunden är, vad de får se och vad de betalar, då spelar det ingen roll hur snygg AI-modulen ovanpå är.

Så börjar ni: pragmatisk införandeordning

Vi ser samma tre misstag återkomma. Team försöker migrera allt på en gång. Team lägger punchout först, före själva prismodellen är stabil. Team försöker replikera alla varianter av avtalsrabatter från ERP:et i frontend istället för att flytta dem till Norce där de hör hemma. Den ordning som brukar landa mjukast:

1. Stabilisera masterdata. Produktdata från PIM, kunddata och prislistor från ERP:et. Om priset inte kan beräknas rätt i ERP:et kommer det aldrig kunna beräknas rätt i Norce.

2. Bygg företagsmodellen i Norce. Company, CompanyGroup, användare, roller. Kör det parallellt med det gamla systemet under 4–8 veckor och stäm av att kreditgränser räknas rätt.

3. Lägg upp prislistorna. Börja med segment, lägg kundunika ovanpå. Verifiera med en handfull skarpa kundcase innan ni tar in fler.

4. Sortimenten. Basassortiment per kanal, exklusioner, tillägg. Verifiera i sökindexet — inte bara i produktlistan.

5. Först nu punchout. Välj en pilotkund, kör cXML eller OCI i sandbox, ta det i produktion. Utöka därifrån.

B2B-ehandel på Norce är inte magi. Det är en genomtänkt datamodell, disciplin i prislistorna och tålamod med integrationslagret. Rätt uppsatt får ni en plattform som håller när volymen växer och när kunderna kräver punchout, kontraktspris och kundunikt sortiment på samma gång. Fel uppsatt får ni en B2C-plattform i förklädnad — och en långsam katalogsida.

Är ni redo att titta konkret på hur er B2B-modell skulle landa i Norce? Boka ett samtal med oss — vi tar gärna det där första passet där vi ritar upp företagshierarki, prislistor och integrationsflöden på tavlan tillsammans.