Varför kundspecifik prissättning är annorlunda än kampanjpriser
I en konsumentbutik är priset en egenskap på produkten. Alla ser samma pris, och eventuella rabatter styrs av kampanjkoder eller kundklubbar. I B2B fungerar inte det. Priset är inte en egenskap på produkten utan på relationen mellan kund och produkt. Samma artikel kan ha olika pris för olika kunder baserat på avtalade villkor, volym, marknad eller ett enskilt årsavtal.
Det betyder att e-handeln inte kan lagra priser på produkten i en plattformsdatabas på samma sätt som en B2C-butik gör. Priset måste hämtas dynamiskt baserat på vem som är inloggad och vilken prislista eller vilket avtal som gäller. Det är en arkitekturfråga, inte en funktionalitetsfråga.
Var prislogiken ska ligga
Den viktigaste arkitekturfrågan är var sanningen om priset ligger. Det finns två huvudalternativ, och valet påverkar allt efteråt.
Prislistor i affärssystemet som sanningskälla är det vanligaste upplägget i nordisk B2B. Affärssystemet äger kundregister, avtal och prislistor. E-handeln hämtar rätt pris via en integration vid inloggning eller vid varje produktvisning. Det fungerar bra när prislistorna är komplexa, när samma kunder hanteras både av säljare och via e-handel, och när ni redan har investerat i en strukturerad prismotor i affärssystemet.
Prislistor i e-handelsplattformen är det andra alternativet. Plattformen äger priserna och synkar dem från affärssystemet eller låter er underhålla dem direkt i admin. Det fungerar bra för enklare upplägg, när prislogiken är relativt stabil och när ni vill att marknadsavdelningen ska kunna justera priser utan ERP-åtkomst.
Det som avgör är inte plattformsstyrka, utan var organisationen faktiskt äger prisprocessen idag. Att flytta prislogik från affärssystem till plattform är en stor förändring som kräver ny ägarmodell. Det är oftast enklare att låta affärssystemet fortsätta äga logiken och bygga en bra integration.
Vilka prisstrukturer som är vanliga i B2B
De flesta B2B-verksamheter har några av följande prisstrukturer som ofta kombineras.
Kundgruppspriser är den enklaste formen. Kunder klassificeras i grupper (till exempel återförsäljare, distributörer, direktkunder) och varje grupp ser sin prislista. Alla stora plattformar klarar detta nativt.
Kundspecifika priser innebär att enskilda kunder har egna prislistor utöver gruppriset. Det kan vara ett årsavtal, en volymförhandling eller en nyckelkundsrabatt. Här krävs att plattformen kan hantera prislistesöverlagring: om kunden har ett specifikt pris används det, annars används gruppriset, annars listpriset.
Volymprissättning innebär att priset sjunker med kvantitet. Antingen trappat (priset per styck ändras vid tröskelvärden) eller linjärt. Det måste synas tydligt i checkout så att kunden förstår varför priset ändras när de lägger till artiklar.
Årsavtal med kvartalsvisa efterrabatter är en mer komplex struktur där priset i butiken är ett och efterrabatten beräknas separat i affärssystemet. Det kräver att plattformen visar pris utan efterrabatt men att systemet kan spåra kundens årsvolym för senare kreditering.
Marknadsspecifika priser blir relevanta när ni säljer i flera länder eller valutor. Samma kund kan ha olika priser beroende på vilken marknad eller valuta ordern läggs i.
Plattformsskillnader för kundspecifik prissättning
Norce är byggt för nordisk B2B och hanterar multi-pris, prislistesöverlagring och kundspecifika priser nativt i plattformen. Det är ofta förstahandsvalet när prislogiken är komplex och djup.
Shopware har en stark regelbaserad prismotor där villkor kan stacking kombineras. Det passar bra när ni har sammansatta regler för både gruppnivå, kundspecifikt och volym.
Magento med Hyvä ger genom open source full kontroll över prismotorn. B2B-modulen har inbyggd stöd för kundspecifika prislistor och kategoribaserade rabatter.
Shopify Plus har fått B2B-funktioner med företagsprislistor och kundspecifika katalogrestriktioner. Fungerar för enklare upplägg men når gränser vid djupt överlagrade prisstrukturer.
Integration är där projekten faktiskt avgörs
Plattformen i sig är inte vinnaren eller förloraren. Det är kvaliteten i integrationen mellan plattform och affärssystem.
För varje prisanrop behöver plattformen veta vilken kund som är inloggad, vilken produkt som visas, vilken kvantitet som efterfrågas och eventuellt vilken marknad eller valuta det gäller. Affärssystemet behöver svara snabbt nog att sidan inte blir långsam. I praktiken innebär det ofta en kombination av cachad prislista per kund med live-anrop för kritiska moment som checkout-validering.
Junipeer hanterar dessa flöden mot vanliga affärssystem som Business Central, Visma.net, Monitor, Pyramid och SAP Business One. Läs vår guide till ERP-integration för en djupare genomgång av dataflödena.
Vanliga fel som gör prisimplementeringen dyrare
Det vanligaste felet är att börja bygga innan prisdatan är städad. Om kunderna är felklassificerade, om avtalen är spridda över kalkylblad och PDF:er, eller om prislistorna inte är konsekventa mellan säljare, då blir implementationen en rörlig målbild. En städfas innan plattformsbygget kostar tid men spar mer.
Det näst vanligaste är att inte definiera vad som händer när priset saknas. Om en kund saknar pris på en artikel, ska artikeln inte visas, visas utan pris, visas med listpris, eller visas med felmeddelande? Den frågan verkar trivial men påverkar både UX och förtroende.
Det tredje är att underskatta testningen. Varje kombination av kund, produkt, kvantitet och prislista är en testcase. Med ett par hundra kunder och tusen artiklar blir kombinationerna snabbt orimligt många. Smart QA innebär att testa representativa scenarier från riktiga orderhistorik istället för exhaustiv permutationstestning.
Nästa steg
Kundspecifik prissättning är en kärndel av B2B-e-handeln men sällan ett isolerat projekt. Läs vår huvudguide till B2B e-handel för hur prissättningen passar in i hela leveransen, eller B2B-sidan för hur olika typer av B2B-verksamheter hanterar det. Kontakta oss om ni vill gå igenom er prisstruktur och hur den bäst speglas i e-handeln.