Omloopsnelheid van voorraad: verdeel uw voorraad slim over marktplaatsen

De omloopsnelheid van uw voorraad verandert sneller dan de meeste inkoopoverleggen kunnen bijhouden. Een SKU kan tijdens een campagne 40 stuks per dag verkopen op Amazon, 6 per dag in uw Shopify-webshop en 2 per dag op bol.com, en toch gezond ogen zolang het team alleen naar één samengevoegd voorraadgetal kijkt. Dat totaalbeeld is comfortabel, maar het verbergt de vraag waar het in de praktijk om draait: welk kanaal verdient de eerstvolgende beschikbare eenheid?

Gidsen van Shopify, Cin7, ShipBob, Finale Inventory en specialisten in magazijnindeling behandelen elk een deel van de puzzel: voorraadrotatie, FSN-analyse, langzaam draaiende voorraad, cyclustellingen en kanaalverdeling. Wat ontbreekt, is de dagelijkse werklaag voor multichannel-verkopers. De meeste adviezen stoppen bij “houd uw verkoopsnelheid bij” of “verdeel per kanaal”. Hoe u die snelheid vertaalt naar regels voor buffers, zichtbaarheid op marktplaatsen, bestelmomenten, magazijnlocaties en uitzonderingslijsten, blijft meestal onbeantwoord.

Precies daar helpen omloopsnelheidsniveaus. In plaats van dat inkoper, marktplaatsmanager en magazijnleiding elk zelf ruwe verkooprapporten moeten duiden, krijgt iedere SKU een praktisch label per kanaal en per locatie. Snelle voorraad beschermt u. Actieve voorraad vult u op de gebruikelijke manier aan. Langzame voorraad beoordeelt u voordat er weer een inkooporder uitgaat. Voor stilliggende voorraad kiest u tussen uitverkoop, bundeling of retour naar de leverancier. Geblokkeerde voorraad valt buiten de berekening totdat het probleem is opgelost.

De stuurgrootheid: SKU × kanaal × locatie

De valkuil is dat u omloopsnelheid alleen op SKU-niveau meet. Een multichannel-verkoper heeft niet één markt, maar meerdere markten die allemaal uit dezelfde fysieke voorraad putten. Amazon beloont beschikbaarheid en snelheid, bij bol.com weegt de leverbelofte zwaar mee, Shopify beschermt vaak de marge en groothandelsklanten nemen grotere aantallen af, maar minder vaak. Dezelfde SKU gedraagt zich per kanaal dus anders.

Een bruikbaar model voor omloopsnelheid begint bij het aantal verkochte stuks per dag, maar corrigeert wel voor beschikbaarheid. Was een SKU acht dagen niet op voorraad, dan geeft het ruwe verkoopcijfer over 30 dagen een te laag beeld van de vraag. Was een product onzichtbaar door een mislukte feed naar een marketplace, dan bewijst dat kanaal nog niets over een zwakke vraag. En als een bundel op de achtergrond componenten verbruikt, telt de omloopsnelheid van die componenten mee, ook al betrof de bestelling op de marketplace de bundel-SKU.

Daarom is SKU × kanaal × voorraadlocatie de beste eenheid om op te sturen. Wie werkt met één magazijn, één 3PL en Amazon FBA, heeft al minstens drie voorraadposities. Wie verkoopt via Shopify, Amazon, bol.com, Kaufland en B2B, krijgt minstens vijf vraagsignalen binnen. Met omloopsnelheidstiers spreekt u over al die signalen in dezelfde taal.

Vijf snelheidsniveaus die u morgen al kunt inzetten

Begin niet met een ingewikkeld voorspelmodel. Werk liever met vijf niveaus die aansluiten op beslissingen die u in de praktijk echt neemt. De drempelwaarden verschillen per categorie, marge en levertijd, maar de onderliggende logica blijft hetzelfde.

• Snel: verkoopt zo vaak dat een ontbrekende synchronisatie, gemiste pick of te late inbound direct zichtbaar omzet en ranking kost.
• Actief: verkoopt constant, maar niet zo hard dat elk uur beschikbaarheid het weekresultaat bepaalt.
• Langzaam: verkoopt sporadisch en verdient geen automatische aanvulling, tenzij er een marge- of campagnereden voor is.
• Slapend: kent geen recente beweging en vraagt om een besluit: uitverkoop, bundel, retour naar leverancier of uit het assortiment halen.
• Geblokkeerd: is niet betrouwbaar door een feedfout, ontbrekend listingattribuut, quarantaine, compliance-blokkade of een onopgelost voorraadverschil.

Juist de geblokkeerde tier wordt door veel verkopers over het hoofd gezien. Een SKU zonder verkopen omdat de listing op de marktplaats is geblokkeerd, is niet langzaam. Een SKU die wel in het magazijn ligt, maar door quarantaine niet verkoopbaar is, is niet slapend. En een SKU die op het kanaal ontbreekt door een PIM- of API-fout, kampt niet met een vraagprobleem. Dit is een operationeel probleem.

Zo bouwt u het tiermodel op

Het tiermodel moet zo eenvoudig zijn dat uw team er ook in een drukke week mee uit de voeten kan. U hoeft niet met een data-science-traject te beginnen. De eerste versie maakt u met orderexports, mutatielogs uit het magazijn en beschikbaarheidsrapporten van de marktplaatsen. Zodra de regels helder zijn, verhuist u het model naar gekoppelde voorraadsoftware.

1. 1
   Meet de verkochte aantallen per SKU per kanaal

   Ga uit van verzonden of betaalde bestellingen, niet van paginaweergaven. Houd Amazon, bol.com, Shopify, Zalando en groothandel gescheiden.
2. 2
   Corrigeer voor het aantal beschikbare dagen

   Laat dagen buiten beschouwing waarop de SKU uitverkocht of verborgen was. Anders lijkt een leveringsgat op zwakke vraag.
3. 3
   Wijs het snelheidstier toe

   Werk met de tiers snel, actief, langzaam, slapend en geblokkeerd, zodat het team direct kan handelen zonder een spreadsheet door te spitten.
4. 4
   Koppel er een voorraadactie aan

   Elk tier heeft een regel nodig voor buffer, allocatie, herbestelbeoordeling, zichtbaarheid op marktplaatsen en locatie in het magazijn.
5. 5
   Loop elke week de uitzonderingen na

   Actiepieken, bundels, retouren, vertraagde inbound en sancties van marktplaatsen horen een SKU naar een uitzonderingenlijst te verplaatsen.

De bruikbaarste drempel is vaak niet “hoge omzet”, maar “verkoopsnelheid afgezet tegen de tijd die u nodig hebt om te reageren”. Verkoopt een SKU 12 stuks per dag en bedraagt de levertijd van uw leverancier 21 dagen? Dan is een buffer van 40 stuks geen buffer, maar drie dagen dekking. Verkoopt een SKU 2 stuks per week en staat hij op een prime pickplek, dan kost dat niet alleen kapitaal, maar ook looptijd, schapruimte en onnodige afwegingen.

ChannelDock sluit op deze werklaag aan, want velocity tiers hebben pas waarde als ze de beschikbaarheid daadwerkelijk aansturen. Via de integraties van ChannelDock koppelt u marktplaatsen en webshops, met de voorraadfuncties houdt u de voorraadbron eenduidig, en met operationele regels voorkomt u dat een marktplaats een verouderd aantal ontvangt terwijl het magazijn de telling nog corrigeert.

Welke acties hoort bij elke tier?

Een snelheidstier zonder bijbehorende actie is slechts een extra veld in uw dashboard. Elke tier moet minimaal één van vijf zaken aansturen: zichtbaarheid op marketplaces, voorraadbuffer, beoordeling van herbestellingen, plaatsing in het magazijn en afhandeling van uitzonderingen.

Juist hier blijven veel artikelen over dit onderwerp te algemeen. “Verbeter de voorraadsnelheid” is geen instructie. “Zet snelle Amazon-SKU’s op dagelijkse uitzonderingscontrole en verlaag de zichtbare voorraad op tragere kanalen zodra de voorraaddekking onder de levertijd zakt” is dat wel: daar kan uw team direct mee aan de slag.

Het model voorkomt bovendien overhaaste beslissingen. Een langzaam artikel hoeft niet meteen af te vallen voor korting, bijvoorbeeld als het een hoge marge heeft, seizoensgebonden is, nodig is voor een bundel of bijdraagt aan uw vindbaarheid in de zoekresultaten van de marketplace. Andersom krijgt een snel artikel niet automatisch elke beschikbare eenheid als het kanaal een lage marge, veel retouren of dure fulfillment kent. Snelheid stuurt de beslissing, maar vervangt uw commerciële afweging niet.

De valkuil op marktplaatsen: verkoopsnelheid zegt niets over vraag als de beschikbaarheid niet klopt

Marktplaatsdata is zelden schoon. Een product lijkt traag te verkopen omdat de listing de Buy Box kwijt is, omdat de levertijd is opgelopen, omdat de feed een verkeerd voorraadniveau doorgaf, omdat een marktplaats eenheden als gereserveerde voorraad vasthield, of omdat een actie de vraag een week lang naar een ander kanaal verschoof. Wie elk laag snelheidssignaal als zwakke vraag uitlegt, verlaagt uiteindelijk de voorraad op de verkeerde plek.

Controleer daarom vier belemmeringen voordat u een SKU terugzet: was het product gedurende de hele meetperiode beschikbaar, stond de listing live en was het product daadwerkelijk te koop, was de leverbelofte concurrerend, en heeft een ander kanaal of een bundel dezelfde voorraad opgesoupeerd? Is het antwoord op een van deze vragen nee, dan classificeert u de SKU eerst als geblokkeerd of als uitzondering. Pas als de vraag een eerlijke kans had om zich te laten zien, noemt u een SKU langzaam.

De beste rapporten over verkoopsnelheid rangschikken niet alleen SKU's. Ze laten ook zien of een SKU per kanaal een eerlijke kans had om te verkopen.

Zo verbeteren snelheidsklassen uw voorraadsynchronisatie en aanvulling

Snelheidsklassen maken voorraadsynchronisatie veiliger, omdat ze bepalen welke SKU's strengere controle verdienen. Snelle SKU's vragen om kortere synchronisatie-intervallen, een lagere tolerantie voor oververkoop en een stevigere buffer tijdens promoties. Langzame SKU's kunnen met een ruimere beoordelingscyclus toe, maar vragen wel om keuzes over kapitaal en opslagruimte. Slapende SKU's horen niet steeds terug te komen in bestelsuggesties alleen omdat ze onder een theoretisch minimumniveau zijn gezakt.

Bij de aanvulling voorkomen snelheidsklassen dat uw inkoopteam op basis van een gemiddelde vraag bestelt. Inkopers onderscheiden zo een echte snelle verkoper van een SKU die tijdelijk piekt. Ze reserveren eenheden voor het kanaal met de beste marge. Ze sturen niet alle inkomende voorraad naar FBA of naar één marktplaats als een ander kanaal sneller omzet in cash omzet. En ze hoeven na elke campagne niet meer handmatig in spreadsheets de voorraad per kanaal aan te passen.

Ook de operatie in het magazijn heeft er baat bij. Snelle SKU's horen op efficiënte picklocase-locaties, terwijl langzame en slapende voorraad geen topplekken hoeft in te nemen. Geblokkeerde voorraad wordt pas gepickt zodra de status is opgelost. Gebruiken magazijn en marktplaatsteam dezelfde klassenindeling, dan zijn voorraadcorrecties geen losse ingrepen meer, maar bedrijfsbeslissingen.

Wat u wekelijks moet meten

De wekelijkse review houdt u bij voorkeur kort. Het gaat er niet om dashboards te bewonderen, maar om SKU's door te schuiven naar een andere tier en uitzonderingen bij een eigenaar neer te leggen. Begin met deze controles:

• Snelle SKU's waarvan de voorraaddekking lager is dan de levertijd van de leverancier.
• Snelle SKU's waarbij één kanaal meer voorraad opsoUpt dan de geplande allocatie.
• Langzame SKU's met openstaande inkooporders die u nog kunt aanpassen.
• Slapende SKU's die plek innemen in de pick-face, bij FBA of in dure 3PL-opslag.
• Geblokkeerde SKU's door feedfouten, voorraadverschillen, quarantaine of ontbrekende marktplaatsattributen.
• SKU's die van tier wisselden door een campagne, seizoensinvloed, prijswijziging of de lancering van een bundel.

Zo wordt snelheid van omloop een vaste regelkring: meten, indelen, handelen, evalueren. Verkopers die deze cyclus elke week herhalen, merken meestal dat de grootste winst niet uit een slimmere formule komt. Die komt uit minder verborgen uitzonderingen, minder verouderde voorraadaantallen op marktplaatsen en minder inkoopbeslissingen op basis van gemiddelden over alles heen.

Conclusie

Met voorraadsnelheidsniveaus bepaalt u als multichannel-verkoper op een praktische manier waar uw voorraad hoort te liggen, nog voordat out-of-stocksituaties, onverkoopbare restvoorraad of marktplaatsboetes die keuze voor u maken. Het beste model is niet de meest geavanceerde forecast, maar het model waar uw team elke week mee uit de voeten kan: meet de snelheid per SKU, uitgesplitst naar kanaal en locatie, corrigeer voor beschikbaarheid, wijs een niveau toe, koppel er een vaste actie aan en leg uitzonderingen neer bij de juiste verantwoordelijke.

Verkoopt u al via meerdere marktplaatsen? Koppel het niveaumodel dan aan de systemen die uw beschikbaarheid publiceren. Houd voorraad, bestellingen en koppelingen op één lijn met ChannelDock en start een gratis account via ChannelDock zodra u het handmatig aanpassen van voorraad per kanaal wilt vervangen door één centrale laag voor uw operatie.

Veelgestelde vragen