Online bestellingen en winkelvoorraad: waarom retail en eCommerce om hetzelfde exemplaar blijven concurreren

Om elf uur 's ochtends koopt een klant het laatste exemplaar aan de kassa. De website blijft het tot in de middag aanbieden, en rond lunchtijd heeft een tweede klant hetzelfde exemplaar online gekocht. Het gebruikelijke oordeel: iemand in de winkel was te laat met het bijwerken van de telling. Dat oordeel is makkelijk, want het wijst naar een persoon. Een voorraadconflict tussen winkel en webshop ontstaat wanneer je webshop en je fysieke winkel uit dezelfde voorraad verkopen, terwijl elk er een eigen telling van bijhoudt. De twee kanalen zijn geen twee voorraden. Het zijn twee claims op één voorraad. En als geen van beide de ander voor laat gaan, wordt hetzelfde exemplaar twee keer beloofd.

Zo bekeken was de dubbele verkoop geen vergissing. Hij lag de hele tijd klaar en wachtte alleen op twee bestellingen die kort genoeg na elkaar binnenkwamen om hem zichtbaar te maken. Dit stuk pelt het conflict laag voor laag af. We beginnen bij de verklaring waar de meeste teams naar grijpen en gaan dan een stap verder, naar wat de dubbele verkoop werkelijk mogelijk maakte. Het loont om de situatie in de winkel apart te bekijken. De splitsing tussen online en offline heeft een eigen mechaniek, die de algemene versie over losgekoppelde systemen niet helemaal dekt.

Wat een voorraadconflict tussen winkel en webshop eigenlijk is

Een voorraadconflict tussen winkel en webshop ontstaat als één fysieke voorraad via twee kanalen wordt verkocht die hem elk apart bijhouden. Eén gedeeld schap, twee tellingen, geen regel over welke telling wint. Denken beide kanalen dat een exemplaar van hen is om te verkopen, dan kan hetzelfde artikel tegelijk worden toegezegd aan een klant in de winkel en een klant online. Pas bij de fulfilment blijkt dat een van de twee niets krijgt.

Het sleutelwoord is toegezegd. In de meeste kassa- en voorraadsystemen haal je een verkocht exemplaar niet simpelweg van een fysiek totaal af. Het verschuift naar de status toegezegd of gereserveerd, en het verkoopbare aantal is wat overblijft als je die toezeggingen eraf haalt. Een voorbeeld uit Shopify: beschikbare voorraad is wat aanwezig is, min wat toegezegd en niet beschikbaar is. Het conflict is niet dat het schap niet klopt. Het conflict is dat twee kanalen die aftreksom allebei maken op basis van hun eigen beeld van wat al geclaimd is. Daardoor kunnen ze allebei een exemplaar nog als vrij te koop tonen.

Daarom is “dubbel verkocht” eigenlijk een misleidende term. Fysiek is het exemplaar nooit twee keer verkocht. Het is twee keer beloofd: twee kanalen hadden allebei het recht om het te beloven, en deden dat ook. Dat onderscheid doet ertoe, omdat het de oplossing naar de juiste plek stuurt. Je zoekt geen telfout. Je kijkt naar twee systemen die allebei het mandaat kregen om ja te zeggen.

De eerste verklaring, en waar die tekortschiet

De eerste verklaring is dat de telling te traag werd bijgewerkt. Een medewerker had het druk, een synchronisatie liep achter, een handmatige correctie kwam pas na de verkoop. Meestal klopt dat, en het verklaart het moment van elke afzonderlijke dubbele verkoop. Wat het niet verklaart, is waarom die dubbele verkoop überhaupt mogelijk was. En juist dat bepaalt of het opnieuw gebeurt.

Timing verklaart het moment waarop twee bestellingen botsten. Het verklaart niet de vaste situatie waardoor ze konden botsen. Als snelheid het enige probleem was, zou een snellere update het conflict volledig wegnemen. Toch verkopen merken met een bijna directe synchronisatie op hun drukste uren nog steeds te veel. Dat gat tussen verklaring en uitkomst laat zien dat het verhaal niet compleet is. Onder de timing zit iets structureels, en dat blijft liggen hoe snel de updates ook lopen.

Wie de vertraging de schuld geeft, stuurt de oplossing bovendien ongemerkt de verkeerde kant op. Je koopt een snellere synchronisatie, plant een extra afstemronde in of vraagt het winkelteam om vaker bij te werken. Elk daarvan verkleint het venster waarin het conflict kan opduiken. Geen ervan haalt de reden weg dat het conflict bestaat. De klok gaat sneller. De situatie eronder verandert niet.

De echte oorzaak: twee kanalen, twee tellingen, één voorraad

De echte oorzaak ligt een laag dieper. De twee kanalen zijn zo gebouwd dat ze elk een eigen telling van dezelfde fysieke voorraad lezen, en elk mag op basis van die eigen telling verkopen zonder bij de ander te checken. De dubbele verkoop is geen storing in die opzet. Het is de opzet die precies doet waarvoor hij gebouwd is, want nergens is vastgelegd wiens claim op een exemplaar voorgaat.

Volg één exemplaar. De winkel en de website denken allebei dat het te koop is. De winkel verkoopt het en zet het in het kassasysteem op toegezegd. Op dat moment klopt de telling van de website volgens zijn eigen logica nog steeds, want de website heeft het kassasysteem nooit als leidend gezien. Hij las zijn eigen telling. Twee tellingen, elk op zichzelf correct, die het oneens zijn over één fysiek product. Het conflict zit in de ruimte daartussen. En die ruimte bestaat omdat geen van beide tellingen ooit ondergeschikt is gemaakt aan de ander.

Dat verandert wat “overselling oplossen” eigenlijk betekent. Het probleem is niet dat een getal achterliep. Het probleem is dat twee kanalen elk zelfstandig zeggenschap hebben over dezelfde voorraad. De telling kan op beide plekken actueel zijn en het exemplaar toch twee keer laten gaan. Zolang beide kanalen op eigen houtje ja kunnen zeggen, is het conflict structureel. Het duikt steeds weer op zodra de vraag sneller binnenkomt dan de kanalen hun tellingen gelijktrekken. Winkel en webshop concurreren niet omdat iemand slordig was. Ze concurreren omdat de architectuur ze elk een gelijke, losse claim op hetzelfde schap gaf.

Waarom realtime synchronisatie het conflict kleiner maakt, maar niet oplost

Realtime synchronisatie maakt het conflict zeldzamer zonder het weg te nemen. Het venster waarin twee kanalen het oneens zijn wordt kleiner, maar beide kanalen houden hun eigen claim. Stuurt een verkoop in de winkel direct een update naar de website, dan krimpt het verschil tussen de twee tellingen van uren naar seconden. Op een gewone dag is dat vaak genoeg om het conflict uit beeld te laten verdwijnen. Het is een echte verbetering, en de juiste eerste stap.

Een volledige oplossing is het niet, omdat de twee claims nog steeds los van elkaar bestaan. Tijdens een piek kan een bericht vertraging oplopen door een rate limit of een nieuwe poging, en in de seconden voordat het aankomt kunnen beide kanalen nog verkopen. Snellere doorgifte verplaatst een gekopieerd getal sneller tussen twee systemen. Het maakt niet een van beide de autoriteit die de ander volgt. Het is hetzelfde mechanisme dat verschillen veroorzaakt tussen elk stel losgekoppelde systemen, en dat uitgebreid aan bod komt in het hoofdartikel over waarom voorraad nooit klopt tussen systemen. Hier gaat het om iets smallers, en dat is het onthouden waard: snelheid zorgt dat het conflict tussen winkel en webshop minder vaak voorkomt. Of het kan gebeuren, hangt alleen af van een besluit over wiens claim wint.

Het besluit eronder: telt winkelvoorraad mee als online beschikbaar?

De knop waar de meeste teams nooit bewust aan draaien, is één besluit: mag de fysieke voorraad van elke winkel meetellen als online beschikbaar, en mag een winkel überhaupt online bestellingen uitleveren? Beantwoord dat duidelijk, per locatie, en het grootste deel van het conflict verdwijnt. Laat je het in het midden, dan wordt elke winkel een voorraad waar beide kanalen stilletjes uit putten, zonder dat ooit is afgesproken dat ze dat doen.

Er zijn echte keuzes, en die zijn operationeel, niet technisch. De voorraad van een winkel kan alleen bedoeld zijn voor klanten die binnenlopen, en telt online dan helemaal niet mee. Hij kan volledig online verkoopbaar zijn, waardoor de winkel een fulfilmentlocatie voor webbestellingen wordt. Of hij telt gedeeltelijk mee, met een buffer die achterblijft zodat online vraag de winkel nooit leegtrekt. Shopify ondersteunt dit met voorraad per locatie en een fulfilmentvolgorde, zodat een bestelling wordt toegezegd aan een specifieke locatie in plaats van aan een totaal voor het hele bedrijf. De tools om de keuze te maken bestaan. Wat meestal ontbreekt, is de keuze zelf.

Dezelfde verschuiving zat onder de overstap van OGÉR naar één gezamenlijke opzet, waarbij online en offline eindelijk vanuit één structuur gingen werken, in plaats van twee kanalen die elk een eigen telling bewaakten. Een gekoppeld kassasysteem zoals Shopify POS dicht het gat tussen de toonbank en de website, omdat beide uit dezelfde administratie werken. Een verkoop op de ene plek is dan standaard zichtbaar op de andere. De tool doet er minder toe dan het besluit dat je ermee kunt afdwingen: wiens claim op een gedeeld exemplaar voorgaat, en volgens welke regel.

Wat het conflict echt oplost

Het conflict oplossen vraagt om een besluit, niet om een aankoop. Wijs één telling aan waar beide kanalen uit lezen, en geef de claim van één kanaal voorrang als hetzelfde exemplaar in het spel is. Zodra beide kanalen zich voegen naar één gedeelde administratie van wat toegezegd en wat beschikbaar is, kan hetzelfde exemplaar niet meer twee keer worden beloofd. Er is dan maar één plek waar een belofte wordt vastgelegd.

Dat besluit is de praktische consequentie van alles hierboven. De update door het personeel, de snelheid van de synchronisatie en de extra afstemronde behandelen allemaal het symptoom. Daarom komt het conflict na elk ervan terug. De structurele oplossing is de onafhankelijkheid weghalen waardoor twee kanalen allebei ja konden zeggen. In de praktijk betekent dat: één systeem houdt het verkoopbare aantal bij, elk kanaal leest daaruit voordat het een exemplaar toezegt, en de regel voor wat er gebeurt als winkel en webshop hetzelfde artikel willen, staat op papier. Je ontdekt hem niet pas midden in een dubbele verkoop. Winkel en webshop houden niet op met concurreren omdat ze sneller bijwerken. Ze houden op omdat ze eindelijk uit één telling putten in plaats van twee.

Veelgestelde vragen

Waarom verkoopt mijn webshop producten die in de winkel uitverkocht zijn?

Omdat de website en de winkel elk een eigen telling van dezelfde fysieke voorraad bijhouden, en die met vertraging bijwerken. Wordt het laatste exemplaar in de winkel verkocht, dan neemt de website dat pas over zodra een synchronisatie het doorgeeft. Tot die tijd biedt hij een exemplaar aan dat al weg is. De oorzaak is dat twee kanalen elk een eigen telling hebben, niet één trage update.

Is een voorraadconflict tussen winkel en webshop hetzelfde als overselling?

Overselling is het zichtbare gevolg. Het conflict is de oorzaak eronder. Van overselling is sprake als je meer exemplaren verkoopt dan er zijn. Een voorraadconflict tussen winkel en webshop is de specifieke reden dat dat over kanalen heen gebeurt: twee kanalen houden elk een eigen telling bij van één fysieke voorraad, en elk kan een exemplaar toezeggen zonder bij de ander te checken. Zo wordt hetzelfde artikel twee keer beloofd.

Voorkomt Shopify POS dat online en in de winkel hetzelfde exemplaar wordt verkocht?

Een gekoppeld kassasysteem zoals Shopify POS zet verkopen in de winkel en online in dezelfde administratie. Een verkoop aan de toonbank zie je daardoor standaard meteen terug in de online beschikbaarheid, niet pas na een vertraagde synchronisatie. Zo verdwijnt de alledaagse versie van het conflict, omdat beide kanalen één gedeelde telling hebben. Randgevallen bij veel verkeer hangen nog af van hoe je beschikbaarheid per locatie en reserveringen hebt ingesteld.

Moet winkelvoorraad online te koop zijn?

Dat hangt af van een besluit dat je per locatie neemt, niet van een standaardinstelling. Winkelvoorraad kan gereserveerd zijn voor klanten die binnenlopen, volledig online verkoopbaar zijn zodat de winkel webbestellingen uitlevert, of gedeeltelijk gedeeld worden met een buffer voor de winkel zelf. Het conflict blijft meestal bestaan als dit nooit is besloten. Dan putten beide kanalen uit dezelfde winkelvoorraad, zonder dat ze dat hebben afgesproken.

Lost realtime voorraadsynchronisatie het conflict tussen kanalen op?

Het maakt het conflict veel kleiner, maar lost het niet op. Realtime synchronisatie verkleint het venster waarin twee kanalen het oneens zijn van uren naar seconden. Toch houden beide kanalen hun eigen claim op de voorraad, en een vertraagd bericht tijdens een piek kan ze nog steeds allebei laten verkopen. Het conflict verdwijnt pas met één gedeelde telling waar beide kanalen zich naar voegen, niet alleen met snellere updates.

De kern

• Bij een voorraadconflict tussen winkel en webshop verkopen twee kanalen uit één fysieke voorraad, terwijl elk er een eigen telling van bijhoudt. Het zijn twee claims op één voorraad, geen twee voorraden.

• Het exemplaar wordt twee keer beloofd, niet twee keer verkocht. Beide kanalen hadden het recht om het te beloven, dus deden ze dat allebei. De oplossing ligt daarom bij zeggenschap, niet bij een telfout.

• De eerste verklaring, een trage update, klopt, maar is onvolledig. Ze verklaart wanneer een dubbele verkoop gebeurde, niet waarom die mogelijk was. De structurele oorzaak blijft bestaan, hoe snel je ook synchroniseert.

• De echte oorzaak is dat twee kanalen twee losse tellingen van dezelfde voorraad lezen, zonder regel over wiens claim wint. Het conflict is de opzet die werkt zoals hij gebouwd is.

• De oplossing is een besluit, geen tool: één gedeelde telling waar beide kanalen uit lezen, voorrang voor de claim van één kanaal, en per locatie een duidelijke regel of winkelvoorraad meetelt als online beschikbaar.

Het verschil tussen de toonbank en de website betekent niet dat het winkelteam achterloopt met bijwerken. Het betekent dat twee kanalen elk het recht kregen om hetzelfde schap te verkopen, zonder dat iemand zei wie voorgaat. Dat besluit moet nog genomen worden. En zodra dat gebeurt, stoppen de twee kanalen met concurreren om een exemplaar dat maar één van hen ooit had kunnen leveren.