Software integration.Enteritonce.Keepeverythinginsync.

Many SMEs run a handful of packages side by side: a CRM, accounting software, a webshop, a planning tool, a mailbox and a few spreadsheets holding it all together. Each package does its own job well. The problem sits in between: the same client, order or invoice gets entered in three places, and as soon as something changes somewhere, the rest falls behind.

Software integration means that data moves from one system to the other automatically. A new client in your CRM immediately appears as a debtor in your accounting. A paid webshop order shows up in your planning. A settled invoice sets the status in your CRM to paid. Nobody retypes anything, and everyone looks at the same data.

We connect what you already have. You don't need to buy a new package and your team doesn't need to change how it works. Where a standard connector exists that is good enough, we say so. Where it doesn't exist or falls short, we build a custom integration with error monitoring built in.

A CRM integration is the one we are asked about most, because the CRM is usually where a client relationship starts. The common combinations:

• CRM and accounting, for example HubSpot or Salesforce with Exact, AFAS, Twinfield or Moneybird. Client details go one way, the payment status of invoices comes back.
• Webshop and accounting, for example Shopify or WooCommerce. Orders, VAT and payments land in your books without exports.
• CRM and planning. A won deal automatically becomes a job in the planning, with the agreements recorded in the CRM.
• Webshop and stock or purchasing. What has been sold is updated where you place your orders.

These are examples, not a fixed list. We are not a reseller or partner of these packages. We check what each package's API allows and choose the integration accordingly. If you use software that isn't listed here, that is rarely a problem.

Zapier and Make are good tools. If a new form submission needs to land in your CRM, or a message should appear in a team channel when an order comes in, such a tool is faster and cheaper than having something built. Do that, and come back when it no longer suffices.

A custom integration is the better choice when:

• there is logic involved: merging, checking or converting data, or routing it according to rules;
• the volume is high and the per-task costs in Zapier or Make add up every month;
• a package has no ready-made connector in those tools, or only a limited one;
• it is business-critical and you want to know exactly what happens when a transfer fails.

Often it's a mix: the simple steps stay in Zapier or Make, and we build the hard part. We discuss that in the discovery.

A build project starts at € 9,500, with a fixed price agreed up front. That often covers more than one integration. What drives the price: how many systems are involved, how good their APIs are, whether data flows one way or has to stay in sync both ways, and how much logic sits in between.

An integration needs maintenance afterwards, because packages sometimes change their APIs. You can handle that yourself or place it with us in a partnership from € 3,500 per month, which also includes monitoring and further development. The discovery up front is free. See all pricing.

Every integration fails at some point. A package is briefly unreachable, a password expires, or someone fills in a field in a way nobody expected. The difference lies in what happens next. The worst case is an integration that stops silently, after which you find out weeks later that orders never came through.

That is why we build in as standard:

• Logging of every transfer, so you can see what was sent when and what the response was.
• Automatic retries on temporary outages, without creating an order twice.
• An alert for an error that doesn't resolve itself, sent to the person who can act on it.
• An overview of what got stuck, so you can resend it in one go once the cause is fixed.

Most modern packages have an API: a fixed entry point through which other software can request and write data. Through webhooks a package can also report straight away that something has changed, so you don't have to wait for a periodic check. That is the route we prefer.

Not everything has a usable API. Older or in-house systems sometimes only offer a database, a CSV export or a folder where files appear. We can integrate with those too: directly on the database where that can be done safely, or by automatically collecting and processing the export files. Your old system doesn't need replacing.

If it's about more than passing data along, and an event should also trigger tasks or notifications, it moves towards workflow automation.

• Map the sources. Which systems are involved, which data needs to go where and how often.
• Pick the source of truth. For each piece of data we decide which system holds the truth, so two packages don't overwrite each other.
• Translate the fields. What one package calls a "contact" is a "debtor" in another. We record that translation, including the exceptions.
• Test with real data in a test environment before anything is written to your books.
• Live and monitored. A first working version is ready in four to eight weeks on average, with error monitoring switched on from day one.