Kort svar: Oversalg opstår, når flere kanaler sælger fra det samme lager uden at vide det om hinanden. Løsningen er arkitektur før teknik: udpeg ÉT sandhedssted for lagertal (webshoppen, lagersystemet eller økonomisystemet – aldrig flere), lad alle andre kanaler LÆSE derfra og melde salg TILBAGE med det samme (webhooks frem for natlige synkroniseringer), og læg en sikkerhedsbuffer på de kanaler, der synkroniserer langsomt. Supplér med to alarmer – negative lagertal og ordrer på udsolgte varer – så fanger du de fejl, der alligevel sniger sig ind, samme dag i stedet for ved næste optælling.
Det første oversalg føles som uheld: to kunder købte den sidste vare med få minutters mellemrum – én på shoppen, én i den fysiske butik. Det tiende oversalg er et mønster, der koster annulleringsmails, dårlige anmeldelser og weekender med manuel lagertælling. Denne guide handler om at få lagertallet til at være SANDT alle steder – uanset om dine kanaler er webshop plus butik, flere webshops eller shop plus markedsplads.
Alle lagerkatastrofer har samme rod: to systemer, der hver især TROR, de ejer tallet. Derfor er første beslutning ikke teknisk, men organisatorisk: HVOR bor det rigtige lagertal? For en ren webshop er svaret ofte WooCommerce selv; med fysisk butik og stregkoder er det typisk kassesystemet eller et lagerstyringssystem; med økonomisystem-lagermodul kan det være dér. Valget er mindre vigtigt end konsekvensen: ÉT system er master, alle andre er spejle – og lagerjusteringer (varemodtagelse, svind, optælling) sker KUN i masteren. Den dag, nogen „lige retter tallet“ i et spejl, er synkroniseringen reelt død – så skriv reglen ned, og tag den alvorligt: den er hele fundamentet.
Tre modne veje: Direkte integrationer – kassesystemer, markedspladser og lagersystemer har ofte færdige WooCommerce-koblinger; tjek én ting før alt andet: synkroniserer de ved HÆNDELSE (salg udløser straks-opdatering, typisk via webhooks) eller pr. interval? Et kvarters interval lyder uskyldigt – men på en Black Friday er et kvarter halvtreds solgte varer. Lagersystem i midten – ved 3+ kanaler er et dedikeret lagerstyringssystem som nav i midten den voksne løsning: alle kanaler taler med ét nav i stedet for med hinanden i et spindelvæv af koblinger. Platform-flows – for specielle kombinationer kan n8n/Make bygge broen selv: salg-webhook ind, lageropdaterings-kald ud. Det giver fuld kontrol – og fuldt ansvar for fejlhåndteringen, så vælg kun den vej, hvis de færdige ikke findes til dit setup.
Selv god synkronisering har sekunder og minutters forsinkelse – og dér bor oversalget. Modtrækket er buffere: sælg på langsomt synkroniserede kanaler (især markedspladser) med et SIKKERHEDSLAGER, så kanalen viser udsolgt, mens der reelt er to-tre stykker tilbage – størrelsen afhænger af varens hastighed og kanalens forsinkelse. Beslut også udsolgt-adfærden bevidst: må kunder købe på restordre (med ærlig leveringstid), eller lukkes varen? Og hvad sker der ved lave lagre – skjules „kun 2 tilbage“, eller vises det som købsmotor? Én undtagelse fortjener omtanke: varer, der også ligger i indkøbskurve, er IKKE solgt – reservér kun lager ved gennemført betaling, ellers kan nysgerrige kurve spærre dit lager i timevis.
Synkronisering fjerner ikke behovet for kontrol – den ændrer den fra brandslukning til rutine. To automatiske alarmer først: negative lagertal (kan matematisk kun opstå ved fejl – og er altid værd at undersøge samme dag) og ordrer på varer med lager nul (tegn på, at en kanal solgte på forældede tal). Begge kan bygges som små flows, jf. overvågningsguiden. Dertil den fysiske virkelighed: cyklisk optælling – tæl en lille del af lageret hver uge (fx én varegruppe) frem for alt én gang årligt, og ret afvigelser i MASTEREN med årsagskode (svind, brud, fejlpluk). Afvigelses-mønstrene fortæller dig, hvor processen lækker – og små lækager, der tælles, forbliver små.
Webshop + fysisk butik: få kassesystemets WooCommerce-integration op med hændelses-synk, gør kassesystemet til master, og start cyklisk optælling – en weekend-opgave, der fjerner 90 % af problemet. Flere webshops fra samme lager: én shop (eller et nav) som master, de andre spejler via integration – og buffere på sekundærkanalerne. Shop + markedsplads: markedspladsens forsinkelse sætter bufferen; sælg aldrig de sidste stykker dér. Og i alle setups: når lagertal flyder automatisk, er næste naturlige skridt at lade ORDRERNE flyde samme vej – fra betaling til pakkelabel uden hænder – og at automatisere leverandør-feeds, så også tilgangen af varer holder sig selv ajour.
Ved hændelse – hvert salg og hver varemodtagelse bør opdatere straks (webhooks). Interval-synk er kun acceptabelt som supplement eller på kanaler med lav volumen og god buffer.
Kontakt kunden med det samme med ærlighed og valg: vente (med dato), alternativ vare eller straks-refusion – plus en lille gestus. Og find så ÅRSAGEN i synkroniseringen, så fejlen ikke gentager sig.
Nej – med én-to kanaler rækker WooCommerce som master plus en direkte integration. Navet i midten bliver relevant fra tre kanaler, eller når indkøb/plukning også skal systematiseres.
