Vad B2B-köpare faktiskt bedömer en leverantörsportal utifrån
Konsument-e-handel är ett upptäckarproblem. B2B-e-handel är ett verifieringsproblem. Köparen vet oftast vad de vill ha innan de kommer till sidan, och sajtens uppgift är att bekräfta pris, tillgänglighet och leverans tillräckligt exakt för att de ska kunna genomföra köpet utan att behöva kontrollera någon annanstans.
Det vänder på prioriteringarna. Sök och merchandising spelar mindre roll än vad de flesta butiksdemonstrationer antyder. Korrekthet betyder mer än nästan allt annat. Ett felaktigt pris på en B2B-order är inte bara en dålig kundupplevelse, utan en kommersiell tvist och en kreditnota.
De funktioner som driver användning är därför oglamorösa. Köpare vill ha sitt pris, faktiskt lagersaldo, sin historik och ett leveransdatum de kan planera efter. En portal som får dessa fyra rätt slår varje gång en portal med bättre gränssnitt men inaktuell data.
Funktionerna som egentligen är dataflöden
Det mesta som syns på en checklista för B2B-funktioner är att butiken visar något som ett annat system äger.
- Kundspecifik prissättning: avtalspriser, volymrabatter och kontorabatter som finns i affärssystemet och tillämpas per inloggat konto
- Lagersaldo i realtid: en siffra för tillgänglighet från lagersystemet, netto efter allokeringar, snarare än en nattlig ögonblicksbild
- Orderhistorik och ombeställning: tidigare ordrar från alla kanaler, inklusive de som lagts via telefon eller EDI, presenterade som en lista
- Kredit- och betalningsvillkor: kontots gräns och villkor från ekonomisystemet, som tillämpas vid utcheckning istället för att upptäckas i efterhand
- Offert till order: en godkänd offert som konverteras till en order utan manuell inmatning, där det offererade priset respekteras
Butiken kan visa alla fem. Den skapar ingen av dem. Det är därför en plattformsmigrering sällan löser problem med en B2B-portal som köpare inte litar på, och varför lösningen oftast ligger bakom butiken snarare än i den.
Varför slutar kundspecifik prissättning att fungera så ofta?
B2B-prissättning är villkorad på ett sätt som konsumentprissättning inte är. Priset på en enskild rad kan bero på kontot, avtalet, orderkvantiteten, valutan, leveransplatsen och om en kampanj är aktiv vid det datumet. Affärssystemet löser dessa villkor korrekt eftersom det har tillgång till all information.
Problemen börjar när prissättningen kopieras till butiken enligt ett schema. En synkroniserad pristabell är en ögonblicksbild av en beräkning, och den blir inaktuell i samma ögonblick som ett avtal omförhandlas eller en volymrabatt justeras. Än värre är att den tyst utelämnar de villkor den inte kunde representera, vilket gör att ett specialfall visas med fel pris utan att något felmeddelande visas någonstans.
Alternativet är att fastställa priset vid visningstillfället genom att anropa affärssystemet via integrationslagret, så att butiken frågar istället för att minnas. Det bibehåller en enda prisauktoritet och eliminerar avstämningsproblematiken helt.
Kundspecifik prissättning i realtid
De leverantörer som är minst benägna att försöka sig på detta är de vars avtalsvillkor ligger i ett decennier gammalt affärssystem, utifrån antagandet att ett system av den åldern inte kan svara en webbshop medan en köpare väntar. Leeuwerik Plaat är en nederländsk leverantör av skivmaterial med över hundra års erfarenhet, ett lager på 20 000 kvadratmeter och mer än 3 000 produkter för företagskunder. Deras köpare beställer utifrån avtalsvillkor, vilket gör korrekt prissättning till en förutsättning för att webbshoppen överhuvudtaget ska vara användbar.
Leeuwerik kopplade sitt Kerridge-affärssystem till Adobe Commerce via Alumio iPaaS och utbyter nu produkter, lagerstatus, kunduppgifter, leveranser, ordrar och kundspecifik prissättning i realtid. Företagskunder kan nu beställa dygnet runt med live-prissättning, istället för att vara begränsade till kontorstid och priser som bekräftats via telefon.
Utgångspunkten är det som gör det användbart. Detta var en traditionell leverantör med ett etablerat affärssystem och ingen önskan att byta ut det; de överbryggade klyftan mellan sina system och sina kunder genom att koppla ihop dem istället för att bygga om.
Hur en integrationsplattform tjänar en B2B-butik
En B2B-butik måste göra två saker samtidigt: ställa en fråga till affärssystemet och få ett svar medan köparen väntar, samt skicka tillbaka en slutförd order. Alumio iPaaS ligger mellan butiken och de system som äger svaren och hanterar båda riktningarna. Synkrona anrop fastställer pris och tillgänglighet i samma ögonblick som en köpare ser en produkt, så att siffran som visas är den siffra som finns i affärssystemet.
Händelsestyrda flöden hanterar trafiken i den andra riktningen. En order som läggs i webbshoppen visas omedelbart i affärssystemet, och dess leveransstatus återförs till köparens konto utan att någon behöver knappa in uppgifterna manuellt. Transformers hanterar den strukturella diskrepansen mellan en e-handelsorder och en försäljningsorder i affärssystemet. Det inkluderar kund-, avtals- och skattereferenser som affärssystemet kräver men som butiken inte har inbyggt stöd för.
Samma lager accepterar ordrar som inkommer via EDI från större köpare, vilket gör att orderhistoriken förblir komplett över alla kanaler istället för att bara visa det som kommit via webben. Loggning registrerar varje utbyte, så att en prisförfrågan har ett svar istället för att kräva en utredning. Detta mönster är vanligt inom B2B-distribution, där affärssystemet är den auktoritativa källan och butiken är en av flera kanaler som läser från det.
Att välja B2B-e-handelsfunktioner utifrån vad de är beroende av
Det praktiska sättet att utvärdera en B2B-roadmap är att ta varje föreslagen funktion och fråga vilket system som äger datan bakom den och hur aktuell den datan måste vara. Funktioner vars data finns i butiken går snabbt att implementera. Funktioner som är beroende av data från affärssystem eller lager är integrationsarbete, oavsett om plattformen listar dem som stödda eller inte.
Sekvenseringen följer av detta. Se till att pris och tillgänglighet löses i realtid innan du lägger till funktioner för offerthantering, punchout eller godkännandeflöden, eftersom dessa senare funktioner ärver den noggrannhet som de två första etablerat. Att bygga dem på en inaktuell pristabell innebär att de måste byggas om senare.
Leverantörer som arbetar på detta sätt får färre funktioner men högre användning, eftersom de funktioner de lanserar är de som köparna litar tillräckligt mycket på för att sluta ringa om.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
