Je productdata klopt in geen enkel systeem. Hoe krijg je het synchroon?
Je webshop zegt twaalf op voorraad, je leverancier zegt nul, en de klant die vanochtend besteld heeft krijgt over drie dagen een mail dat het toch niet kan. Dat is geen slordigheid van je team. Het is wat er onvermijdelijk gebeurt zodra data met de hand van het ene systeem naar het andere wordt overgezet.
Hoe je weet dat dit jouw probleem is
Dit knelpunt komt zelden binnen als "onze data klopt niet". Het komt binnen als een reeks losse irritaties die niemand aan elkaar knoopt:
- Je verkoopt af en toe iets dat bij je leverancier al weken op is, en iemand moet de klant bellen.
- Er is een vast moment in de week waarop iemand een export draait en die in een spreadsheet plakt.
- Je marge op sommige artikelen is stilletjes verdampt, omdat je nog verkoopt tegen een inkoopprijs die niet meer bestaat.
- Twee verkoopkanalen tonen een andere prijs voor hetzelfde artikel.
- Nieuwe producten van je leverancier staan pas maanden later online, of nooit.
- Op de vraag welk systeem heeft gelijk? geeft niemand hetzelfde antwoord.
Die laatste is de belangrijkste. Zolang er geen afspraak is over welk systeem per veld de waarheid bevat, is elke correctie een mening en niet een fix.
Wat het je nu kost
De kosten zitten op vier plekken, en de meeste ondernemers zien er maar één van.
De uren. De zichtbare post. Bij een assortiment van een paar duizend artikelen kost handmatig bijhouden al snel een halve tot een hele dag per week. Reken die dag tegen wat een uur van die persoon je werkelijk kost, maal 46 weken, en je hebt het eerste getal.
De omzet die je niet maakt. Artikelen die je leverancier wel heeft maar jij niet online, verkopen niets. Bij een breed assortiment loopt dat verder op dan de uren.
De marge die weglekt. Dit is de stilste post en meestal de duurste. Een prijsverhoging bij je leverancier die je twee maanden te laat doorvoert, kost je op elk verkocht stuk. Niemand ziet het, want de omzet ziet er prima uit.
Het vertrouwen. Een order die je moet annuleren omdat de voorraad niet klopte, kost je die klant vaak definitief — plus de review.
Reken het eerst uit
Voordat er iets gebouwd wordt: tel een maand lang bij hoeveel orders je moest annuleren of naleveren wegens voorraad, en hoeveel uur er in het bijwerken ging zitten. Twee getallen, één maand. Als daar geen bedrag uitkomt waar je wakker van ligt, is dit jouw probleem niet en kun je je geld beter aan iets anders besteden.
Waarom de wekelijkse export het niet oplost
De standaardoplossing is een exportbestand van de leverancier dat iemand importeert. Dat werkt een tijdje en loopt daarna altijd op dezelfde drie dingen vast.
Een export is een foto, geen film. Tussen twee imports in klopt je voorraad niet, en dat is precies het venster waarin je die order aanneemt die je niet kunt leveren. Bij een leverancier die meerdere keren per dag muteert, is wekelijks importeren functioneel hetzelfde als niets doen.
De koppeling tussen artikelen is handwerk. Het artikelnummer van je leverancier is niet dat van jou. Zodra er varianten in zitten — maat, kleur, verpakkingseenheid — is de vertaalslag niet meer in een sheet te onderhouden.
Correcties overleven de volgende import niet. Iemand past iets met de hand aan, de import gooit het eroverheen, en het vertrouwen in het systeem is weg. Vanaf dat moment houdt iedereen zijn eigen lijstje bij en heb je het probleem verdubbeld.
Hoe het wél wordt opgelost
Een werkende koppeling is geen technisch hoogstandje, maar wel vijf beslissingen die je vooraf moet nemen.
1. Bepaal per veld wie de waarheid bezit
Niet per systeem, per veld. Voorraad komt van de leverancier. Je verkoopprijs bepaal jij, niet je leverancier. Productteksten en foto's meestal jij, omdat de teksten van je leverancier ook bij tien concurrenten staan. Deze afspraak is het halve project.
2. Koppel op API-niveau, niet op bestandsniveau
Een API geeft je actuele data op het moment dat je erom vraagt. Een bestand geeft je de situatie van gisteren, in een formaat dat zonder aankondiging kan veranderen.
3. Muteer alleen wat verschilt
Haal de leveranciersdata op, vergelijk met wat er nu in je shop staat en werk alleen de verschillen bij. Dat is sneller, en belangrijker: het maakt zichtbaar wat er per nacht daadwerkelijk verandert.
4. Leg de uitzonderingen vast vóór je bouwt
Wat gebeurt er bij nul voorraad — offline halen of tonen met levertijd? Wat bij een prijsstijging van meer dan tien procent: automatisch doorvoeren of eerst voorleggen? Wat als een artikel helemaal uit de feed verdwijnt? Dat laatste nooit stilzwijgend verwijderen: markeren en melden. Een leverancier met een storing in zijn API haalt anders in één nacht je halve assortiment offline.
5. Logboek en alarm
Elke run schrijft weg wat er is gewijzigd, en meldt het als de run niet is gedraaid. Een koppeling die stilletjes stopt is gevaarlijker dan geen koppeling, want je vertrouwt de cijfers nog wel.
Waar hier AI bij komt kijken, en waar niet
De synchronisatie zelf is geen AI. Dat is een script, een API en een server — en dat moet je zo houden, want je wilt dat je voorraadstand voorspelbaar is en niet geïnterpreteerd.
AI wordt pas nuttig op de plek waar de variatie zit: een leverancier zonder API die prijslijsten als PDF of wisselend opgemaakte Excel stuurt, of het matchen van artikelen die bij jou anders heten dan bij hem. Waar de grens tussen die twee precies ligt werk ik apart uit.
Wat het kost en hoe lang het duurt
Eén leverancier met een fatsoenlijke REST API en een webshop op een gangbaar platform: dagen tot een paar weken werk, in de orde van enkele honderden tot enkele duizenden euro's. Wat dat bedrag omhoog duwt is bijna nooit de code zelf:
- Een leverancier zonder API, of met documentatie die niet klopt.
- Varianten en verpakkingseenheden die niet één op één te mappen zijn.
- Meerdere verkoopkanalen die elk hun eigen regels hebben.
- Een ERP of voorraadsysteem dat niets naar buiten wil geven.
De terugverdientijd ligt hier meestal korter dan bij AI-projecten, simpelweg omdat je puur handwerk vervangt en de rekensom daardoor hard is. Hoe ik zo'n berekening opzet, staat in het overzicht van kosten en terugverdientijd.
Hoe dit er in de praktijk uitziet
Fayters & HighTech-SS had twee webshops met duizenden producten. Voorraden en prijzen bijhouden was handwerk, met als gevolg fouten en verouderde informatie op de site.
Wat er nu draait is een custom Python-script dat praat met de API van de leverancier. Het draait elke nacht op een server en vergelijkt de data met wat er in de shops staat. Producten die bij de leverancier uit voorraad zijn, gaan direct offline. Prijswijzigingen worden automatisch doorgevoerd. Het proces is volledig geautomatiseerd; de wekelijkse exportronde bestaat niet meer.
Technisch is dat Python, een REST API en Shopify. Geen AI, geen platform met een maandelijks abonnement per artikel. Dat is bewust: hoe minder bewegende delen in een proces dat elke nacht moet slagen, hoe beter.
Wat je eerst moet opruimen
Één waarschuwing, want dit is waar dit soort projecten stukloopt. Een koppeling op een rommelig assortiment levert je een rommelig assortiment op, alleen sneller en in meer systemen tegelijk.
Zorg dus eerst dat je artikelnummers uniek zijn, dat dubbele artikelen zijn samengevoegd en dat er per veld één systeem leidend is. Dat is saai werk van een paar dagen dat de bouwtijd daarna halveert. Het is dezelfde volgorde die ik overal aanhoud: eerst opruimen, dan automatiseren — zie ook de uitleg over wat AI-automatisering wel en niet is.
Waar dit bij mij vandaan komt
Ik bouw deze koppelingen zelf: Python, een REST API en een server die 's nachts draait. Meestal hangt het samen met de webshop eromheen, want dezelfde productdata voedt ook je categoriepagina's en je advertenties.
Hoe ik dat bouwtechnisch aanpak staat bij webdevelopment. Loopt het breder dan één koppeling en zit je in de regio, dan pak ik het op als traject — zie online marketing voor bedrijven in Nijmegen.
Meer over ai voor het mkb
Deze pagina hoort bij ai-automatisering voor het mkb. Daar staat de volledige opbouw van dit onderwerp, van basis tot uitvoering.
Wat is AI-automatisering en wat kan het MKB ermee?
Lees verder →AI-automatisering vs. traditionele automatisering
Lees verder →De kosten van AI-automatisering voor het MKB
Lees verder →Wil je weten wat hiervan in jouw bedrijf haalbaar is? Dat staat op de pagina over AI-automatisering.
Vragen die ik vaak krijg
Mijn leverancier heeft geen API. Kan het dan nog?
Meestal wel, alleen anders. Als er een vast bestand op een server of in de mail komt, is dat automatisch op te halen en in te lezen. Verandert de opmaak steeds, dan is dat precies de plek waar een model het uitlezen kan doen in plaats van een mens. Het is minder betrouwbaar dan een API, dus je bouwt er meer controle omheen.
Hoe vaak moet zo'n synchronisatie draaien?
Dat hangt af van hoe snel je voorraad beweegt. Voor de meeste webshops is één keer per nacht genoeg: je begint elke ochtend met kloppende data. Verkoop je snel roterende artikelen of deel je voorraad met andere kanalen, dan wil je het elk uur, of bij elke bestelling.
Wat gebeurt er als de koppeling stukloopt?
Daar hoort de koppeling op ontworpen te zijn. Een mislukte run mag nooit leiden tot massale wijzigingen: bij een lege of onvolledige respons wordt er niets gemuteerd en krijg je een melding. Zonder die rem haalt één storing bij je leverancier in één nacht je hele assortiment offline.
Is dit nu AI of gewoon een koppeling?
Voor het overgrote deel gewoon een koppeling, en dat is goed nieuws: het is voorspelbaarder en goedkoper dan AI. Ik noem het hier toch, omdat dit probleem in de praktijk vrijwel altijd bovenkomt zodra iemand vraagt wat AI voor zijn bedrijf kan doen. Het eerlijke antwoord is dan meestal: los eerst dit op.
Even sparren over jouw groei?
Geen verkooppraatje en geen accountmanager ertussen. Je spreekt direct met de specialist die het werk ook uitvoert. Meestal reageer ik binnen een paar uur.