When Veldman Groep came to us, three systems were running side by side: a CRM, a webshop and an email platform. All three had their own version of "the customer" — and none of those versions quite matched the other two.

Campaigns were put together by hand, based on exports that were sometimes hours, sometimes days old. The result: offers sent to customers who had just ordered something, and segments that lagged behind reality. None of the systems was broken. They simply weren't talking to each other.

The problem: three systems, three truths

Each system treated a customer as a record within its own boundaries. The CRM knew purchase history, the webshop knew current stock and order status, the email platform knew preferences and engagement. As long as nobody brought those three together, every system kept being right — about part of the story.

The default fix for this kind of project is often a daily or weekly export. That solves the visible problem, not the underlying one: the delay stays, just shorter. We chose a different route.

The engineering: what "real time" actually means

Real-time synchronisation isn't about speed alone — it's about architecture. Three decisions shaped how we built the connection:

  • Events instead of polling. Instead of periodically asking each system "did anything change?", we let each system report the moment something happens.

  • One source of truth per data type. Stock always comes from the webshop, never from a cache in the CRM.

  • Idempotent processing. Any message that arrives twice must never trigger a duplicate action.

Customer data spread across three systems. We built a connection that synchronises everything in real time.

What this delivers in practice

For Veldman Groep this meant that a change in one system is visible in the other two within seconds. Campaigns are built on the current situation, not on yesterday's export.

In short
  • Events beat periodic polling when both speed and system load matter.
  • Give every data type exactly one source of truth.
  • Idempotency isn't an afterthought: it prevents the hardest bugs to find in a connected flow.

Every connection we build goes through the same test round before it goes live. For a real-time sync that's not optional: a mistake you miss here propagates through all your systems at once.

Case study ArchitectureCRMEmail platform