Toen Veldman Groep bij ons aanklopte, draaiden er drie systemen naast elkaar: een CRM, een webshop en een e-mailplatform. Alle drie hadden ze een eigen versie van "de klant" — en geen van die versies klopte helemaal met de andere twee.
Campagnes werden handmatig samengesteld op basis van exports die soms uren, soms dagen oud waren. Het resultaat: aanbiedingen die naar klanten gingen die net iets besteld hadden, en segmenten die achterliepen op de werkelijkheid. Geen van de systemen was stuk. Ze praatten alleen niet met elkaar.
Het probleem: drie systemen, drie waarheden
Elk systeem behandelde een klant als een record binnen zijn eigen grenzen. Het CRM kende aankoopgeschiedenis, de webshop kende actuele voorraad en bestelstatus, het e-mailplatform kende voorkeuren en engagement. Zolang niemand die drie bij elkaar bracht, bleef elk systeem gelijk hebben — over een deel van het verhaal.
De vaste oplossing bij dit soort trajecten is vaak een dagelijkse of wekelijkse export. Dat lost het zichtbare probleem op, maar niet het onderliggende: de vertraging blijft, alleen wordt hij korter. Wij kozen voor een andere route.
De techniek: wat "realtime" echt betekent
Realtime synchronisatie draait niet om snelheid alleen — het draait om architectuur. Drie keuzes bepaalden hoe we de koppeling opbouwden:
Events in plaats van polling. In plaats van elk systeem periodiek te vragen "is er iets veranderd?", laten we elk systeem zelf melden wanneer er iets gebeurt.
Eén bron van waarheid per gegevenstype. Voorraad komt altijd uit de webshop, nooit uit een cache in het CRM.
Idempotente verwerking. Elk bericht dat twee keer binnenkomt mag nooit tot een dubbele actie leiden.
Klantdata verspreid over drie systemen. Wij bouwden een koppeling die alles realtime synchroniseert.
Wat dit in de praktijk oplevert
Voor Veldman Groep betekende dit dat een wijziging in het ene systeem binnen seconden zichtbaar is in de andere twee. Campagnes worden samengesteld op basis van de actuele situatie, niet op basis van een export van gisteren.
- Events werken beter dan periodiek pollen wanneer snelheid en systeembelasting allebei tellen.
- Geef elk gegevenstype precies één bron van waarheid.
- Idempotentie is geen bijzaak: het voorkomt de moeilijkst te vinden fouten in een gekoppelde flow.
Elke koppeling die we bouwen doorloopt dezelfde testronde voordat hij live gaat. Bij een realtime synchronisatie is dat niet optioneel: een fout die je hier over het hoofd ziet, plant zich voort door al je systemen tegelijk.