Waarom je webshop en backoffice geen losse eilanden mogen zijn
Een webshop die ik een tijdje van dichtbij volgde, hield zijn verkoopkanalen draaiende met een map vol bestanden. ’s Ochtends duwde Channable de productfeed naar Google Shopping en een paar marktplaatsen. Dat deel deed precies wat het moest doen. Het probleem zat aan de achterkant. De voorraadstand in die feed kwam uit een export die iemand met de hand bijwerkte en daarna weer importeerde. Zolang de omzet bescheiden bleef, werkte dat verrassend lang goed. Tot het bedrijf groeide en die ochtendroutine niet meer kon bijhouden wat er overdag gebeurde.
Wat er dan misgaat, is voorspelbaar zodra je erop gaat letten. De feed zegt ’s ochtends dat er nog vijf op voorraad liggen. Om drie uur zijn het er nul, maar de kanalen weten dat pas de volgende ochtend. In de tussentijd verkoop je door. De klant krijgt een bevestiging, en een dag later een mail dat het toch niet kan.
Voorraad, orders en boekhouding als eilanden
Dat bedrijf is geen uitzondering. Bij veel groeiende webshops draait de winkel op het ene systeem, de voorraad in het andere en de boekhouding in weer een derde. Daartussen zit iemand die bestanden exporteert, aanpast en weer importeert, of gegevens simpelweg overtikt. Dat is geen slordigheid. Het is zo gegroeid. Elk stuk gereedschap was op het moment van kiezen een prima keuze, en niemand heeft ooit besloten om er een keten van te maken.
Het probleem zit dan ook niet in de losse systemen, maar in de ruimte ertussen. Elke handmatige overdracht is een moment waarop informatie veroudert of er een fout insluipt.
De kosten die niet op een factuur staan
Deze kosten blijven lang onzichtbaar. Eén artikel te veel verkopen levert niet één probleem op, maar een kettinkje: een annulering, een klant die je kwijtraakt, een retour of terugbetaling, en iemand die daar tijd in steekt. Loopt je boekhouding een week achter, dan stuur je op cijfers van vorige week. Niets daarvan verschijnt als aparte post, en juist daarom pakt bijna niemand het aan. Tot het hard genoeg piept.

Bron: Mikhail Nilov / Pexels.com
Meer kanalen, dezelfde voorraad
Zodra je op meerdere plekken tegelijk verkoopt, komt de zwakke plek boven. Je eigen shop, Google, een marktplaats, misschien nog een fysieke winkel: ze putten allemaal uit dezelfde voorraad, maar geen van alle ziet wat de ander op dat moment doet. Bij de webshop uit mijn voorbeeld was de kern van de oplossing niet ‘vaker exporteren’. Het was ervoor zorgen dat elk verkocht artikel, van welk kanaal dan ook, direct van diezelfde voorraad afging. Toen dat geregeld was, verdween niet één klacht, maar een hele reeks tegelijk.
Wat een feedmanager oplost, en wat niet
Hier gaat het in de discussie vaak mis, en in mijn voorbeeld hierboven dus ook. Een feedmanager als Channable is sterk aan de kanaalzijde. Hij zet je artikelen op de juiste plek met de juiste titel, houdt per kanaal eigen regels en prijzen aan, sluit uit wat je er niet op wilt hebben, en haalt marktplaatsorders bij je op. Wil je snel een kanaal toevoegen, dan is dat het gereedschap.
Wat zo’n laag niet doet, is bepalen wat waar is. Hij vertelt je kanalen wat jij hem aanlevert. Klopt de bron niet, of is die van vijf uur oud, dan verspreidt hij dat netjes en snel over al je kanalen. Vandaar de situatie die veel shops kennen: de feed staat perfect ingericht en toch verkoop je artikelen die er niet zijn.
Kort gezegd regelt een feedmanager je etalage. De waarheid over je voorraad, je orders en je cijfers komt uit je backoffice. Dat zijn twee aparte beslissingen, en ze lopen makkelijk door elkaar.
Drie manieren om shop en backoffice te laten praten
In de praktijk zie je grofweg drie routes, elk met een prijskaartje.
1. Losse koppelingen, systeem aan systeem
Je verbindt elk systeem direct met het volgende, via een kant-en-klare plug-in of een stukje maatwerk op de API.
Voordeel: snel live, lage instapkosten, en je houdt alles wat je al hebt.
Nadeel: het aantal verbindingen groeit harder dan het aantal systemen. Eén update aan de ene kant breekt de koppeling aan de andere, en meestal ontdek je dat via een klant en niet via een monitoringmail. Bij een stuk of vijf systemen ben je vooral bezig met onderhoud.
Past bij: een shop met twee of drie systemen en één of twee verkoopkanalen, zonder plannen om daar snel iets aan toe te voegen.
2. Een tussenlaag als verkeersplein
Een order-managementsysteem, een feedmanager of een integratieplatform gaat tussen je kanalen en je backoffice zitten. Iedereen praat met die laag in plaats van met elkaar.
Voordeel: een kanaal toevoegen kost weinig, kanaalspecifieke regels staan op één plek, en je bestaande boekhouding of ERP kan blijven staan.
Nadeel: je krijgt een extra schakel, met een eigen abonnement, eigen beheer en eigen storingen. En de vraag welk systeem de baas is over je voorraad blijft staan, want die laag beantwoordt hem niet voor je.
Past bij: shops met veel verkoopkanalen, en shops met een backoffice die ze niet willen of kunnen vervangen.
3. Alles in één systeem
Shop, voorraad, orders en administratie delen dezelfde gegevens, dus tussen die onderdelen valt niets te koppelen.
Voordeel: één voorraadstand, per definitie. Geen vertraging in de kern, en bij een fout is er één plek om te kijken.
Nadeel: verhuizen is een project, met datawerk, inrichting en gewenning. Je maakt je afhankelijker van één leverancier. En je ruilt losse toppers in voor onderdelen die vooral goed samenwerken. De webshopkant van een compleet pakket haalt het zelden bij een gespecialiseerd shopplatform.
Past bij: bedrijven waar de operatie zwaarder weegt dan de etalage. Denk aan voorraad, inkoop, assemblage en facturatie. En bij het moment waarop meerdere systemen tegelijk aan vervanging toe zijn.
Daarbij moet eerlijk gezegd worden dat de meeste shops ergens in het midden eindigen. Eén systeem als bron van de waarheid voor voorraad, orders en geld, met daarboven een laag voor de kanalen. En over mijn eigen positie ben ik graag open: ik richt dit soort systemen zelf in, dus weeg mijn voorkeur voor de derde route mee.

Bron: Kampus Production / Pexels.com
Realtime waar het moet, rustig waar het kan
Realtime klinkt als de veilige keuze, maar gratis is het niet. Elke live verbinding is een verbinding die kan uitvallen en dus iets wat iemand moet bewaken. De vraag is daarom niet hoe snel het kan, maar kijk per soort gegeven: wat kost een uur vertraging hier?
Voorraad over meerdere kanalen: minuten. Elk uur vertraging is ruimte om iets te verkopen dat er niet meer is. Dit is de enige plek waar ik zonder twijfel voor realtime kies.
Orderstatus en verzendgegevens naar de klant: een uur is snel genoeg, zolang je de cut-off van je vervoerder haalt.
Prijzen: hangt van je markt af. Beweeg je op marktplaatsen mee met de concurrent, dan minuten. Heb je een vaste catalogus, dan is een keer per dag genoeg.
Retouren: dezelfde dag. Een artikel dat al binnen is maar pas volgende week in je voorraad landt, is omzet die stilstaat.
Boekhouding en rapportage: een paar keer per dag. Je neemt geen besluiten op de minuut en een dagelijkse batch controleer je makkelijker dan een continue stroom.
Nieuwe artikelen, teksten en foto’s: per dag, in batches. Prima werk voor de nacht.
Het gekke is dat ik het regelmatig precies omgekeerd zie. De boekhoudkoppeling loopt op elke minuut, de voorraad gaat één keer per nacht rond. Terwijl je klant alleen dat laatste merkt.
Checklijst: hoe gezond is jouw keten?
Vijf vragen waarmee je binnen een uur weet waar je staat.
- Welk systeem heeft het laatste woord over je voorraad? Vraag het aan drie collega’s. Krijg je drie verschillende antwoorden, dan heb je je eerste klus gevonden.
- Hoe vaak raakt een mens een order aan tussen bestelling en factuur? Teken de route van klik tot factuur en zet een streep bij elke overname met de hand.
- Hoe lang duurt het voor een verkoop op kanaal A zichtbaar is op kanaal B? Meet het, schat het niet.
- Wie merkt het eerst als een koppeling stilvalt: jij of je klant?
- Je voegt morgen een kanaal toe. Op hoeveel plekken moet je dan iets inrichten? Eén is gezond. Vier betekent dat je keten je groei afremt.
Wat je vandaag anders kunt doen
Een webshop staat niet op zichzelf. Het is de voorkant van een keten die pas klaar is als de order geleverd en verwerkt is. Blijf je alleen in die voorkant investeren, dan schuif je het probleem naar achteren, waar het minder zichtbaar is maar niet goedkoper.
Wil je groeien zonder dat je operatie achterblijft, begin dan niet met een softwarekeuze maar met één beslissing. Benoem het systeem dat de baas is over je voorraad, laat elk kanaal daar afboeken en zet de rest bewust op een ritme dat bij dat gegeven past. Dat is geen migratie en geen project van maanden. Het is een knoop doorhakken die je daarna bij elk nieuw stuk gereedschap blijft helpen, want vanaf dat moment stel je bij elk systeem dezelfde vraag: praat dit met mijn bron van de waarheid of maakt het er een tweede van?