Din e-handel översäljer — men felet ligger inte i Shopify

En kund lägger en order klockan 14:03 i din Shopify-butik. Klockan 14:18 får samma kund ett mejl om att varan faktiskt är slut. Den beställningen är inte bara förlorad — kunden har precis lärt sig att din butik inte riktigt vet vad den har. Nästa gång kollar de hos konkurrenten först.

Den här typen av översäljning blir ofta bortförklarad som "ett Shopify-problem" eller "något i integrationen". I praktiken är det ett symptom på något större: företaget har tre eller fyra system som alla hävdar att de vet hur mycket lager det finns — och ingen av dem har riktigt rätt.

Lagersaldot bor sällan bara på ett ställe

I de flesta D2C- och multichannel-bolag vi pratar med finns det minst fyra källor som påverkar vad som faktiskt går att sälja:

• Affärssystemet, som innehåller "physical on hand"
• WMS eller 3PL-systemet, som vet vad som är plockat och packat men inte fakturerat
• Shopify, Centra eller Magento, som har en egen kopia som uppdateras via en integration
• En manuell "safety buffer" som någon lagt in i ett fält någonstans
• Reserverade artiklar för B2B-ordrar som ännu inte är plockade

Det som visas som "14 stycken i lager" på produktsidan är i verkligheten en ögonblicksbild som vandrat genom flera system. Om bara ett av dem ligger några minuter efter tappar du kontrollen. Och bara för att siffran stämmer i ERP:et betyder det inte att den stämmer i kanalen — det är två olika värden som behöver hållas i synk.

Batchintegrationer från 2010-talet hänger inte med

Den klassiska setupen — ett lagerjobb som körs var 15:e minut och trycker ut saldot till Shopify — är byggd för volymer på 40 ordrar om dagen. När ni säljer 400 i timmen under en kampanj räcker det inte. Under de där 15 minuterna kan ett lager på 30 bli 0 utan att butiken hunnit uppdatera siffran.

Lösningen har historiskt varit att lägga på en säkerhetsmarginal: "vi visar aldrig mer än fysiskt lager minus 5". Det fungerar — och det kostar dig 5 sålda enheter per artikel i genomsnitt, varje dag. För ett sortiment på några tusen artiklar blir det snabbt miljonbelopp i tappad topline. Marginalen finns där av rädsla, inte av behov.

Orderflödet måste vara händelsedrivet, inte schemalagt

Det som faktiskt funkar är att affärssystemet skickar ett event när något händer — när en order läggs, när en artikel plockas, när en leverans ankomstregistreras. Shopify får saldot uppdaterat i samma sekund, inte vid nästa schemalagda jobb. På motsvarande sätt får ERP:et en notis direkt när en webborder skapas, istället för att hämtas i en batch klockan 23:00.

Moderna plattformar — däribland Visma Business NXT, som vi jobbar mycket med — har den typen av webhooks och triggers som standard. Det är inte en specialbygd integration längre, det är en inbyggd förutsättning. Det ändrar både hur snabbt siffrorna hänger med och vem som behöver hålla igång dem.

Det är inte bara lager som ska synkas

När man väl byter till ett händelsebaserat flöde blir det tydligt att lagersaldot bara är en av flera datapunkter som behöver vara i fas. Orderstatus, returhantering, kundens kreditgräns, prislistor, kampanjpriser som bara gäller i tre dagar — alla behöver ge samma svar i hela kedjan. Annars dyker samma problem upp igen i ett annat hörn: en kund som returnerar en vara och får pengarna tillbaka två gånger, eller en B2B-kund som får fel pris eftersom kampanjen nådde butiken men inte faktureringen.

Det är också här vi ser flest dolda förluster. Överbetalda returer, felaktiga prisvillkor och reservationer som aldrig släpps tillbaka kostar ofta mer sammanlagt än själva översäljningen — men de är svårare att upptäcka eftersom de inte ger kundklagomål omedelbart.

Vad det faktiskt kräver

Att lösa det här är sällan en fråga om att köpa en ny integrationsmotor. Det kräver att man kartlägger vilka events som ska trigga vad, vem som är "source of truth" för vilken data, och vilka fall som ska hanteras atomiskt — exempelvis order och reservation som samma transaktion, inte två separata anrop som kan glappa. Det är mindre glamoröst än det låter, men det är skillnaden mellan en butik som kunden litar på och en som översäljer.

Det är precis den här typen av arkitekturfråga som är en av anledningarna till att Northscale finns. Affärssystemsvärlden har på många sätt inte förändrats på 30 år — trots att både teknologin och sättet kunderna handlar på har förändrats radikalt. Vi är en ny aktör med ny teknik och en leveransmodell som faktiskt ger ett annat resultat. När affärssystemet är händelsedrivet från början är ett korrekt lagersaldo inte längre ett konstant underhållsprojekt — det blir en bieffekt av att orderflödet faktiskt hänger ihop.