The part that never appears in the demo
Every AI demo shows a clean chat window. Your reality is an ERP that has grown over years, a CRM added later, an application somebody wrote in-house, and the spreadsheet nobody lists as a system. The part that takes longest in any AI project is the part where the model meets that landscape, and it is the part the demo leaves out.
You notice it as the pilot that stays a pilot. The assistant works, but it cannot see the order book, so somebody pastes the order in. The agent drafts the ticket reply, but it has no write access, so somebody retypes it. The value appears exactly where a system reads or writes something a person used to read or write. Everything before that is a demonstration, and a demonstration is what most businesses are still left with.
What integration means here, and what it does not
Integration means the AI reads from and writes to the systems you run, with the rights of the person it works for, and leaves a trace. It does not mean replacing anything. A project that starts by replacing a core system is a migration with AI at the end of it, and it takes as long as a migration does.
There are three levels, and we work through them in order for every system:
- A documented interface. Stable, supported by the vendor, survives updates. The first choice whenever it exists.
- A database or file export. Slower, often nightly, but reliable and easy to reason about.
- Automation at the user interface. The software clicks through the screens a person would. It works, and it breaks every time the target system changes its layout. Last resort, priced as one.
How we work
- Inventory. Which systems does the process actually touch? Usually more than are named, because the shared mailbox and the spreadsheet rarely count as systems until you ask.
- Read and write, per system. What may be read, what may be written, with which credential, and whether a test system exists. Where none does, a route that works without one.
- Choose the level per system, and say what it costs to keep.
- Map the fields. What the ERP calls a line the CRM calls an item and the ticketing system calls a position. That translation is the actual work, and it is written down.
- Issue credentials with the minimum rights, to your organisation, with the keys in your hands.
- Log every transfer, so it stays traceable who wrote what, when, and from where.
- Record the update risk per system: what to check when the vendor ships a new version.
At the end you hold the running connection, the field mapping, the credential list with its owners, the logging, and one page per system on what an update can break.
A worked example: one service request, three systems
A service request arrives as a ticket at a plant engineering firm in the Düsseldorf area. To answer it, the agent needs the customer’s installed base, their contract status and the last visits.
The ERP is old but has a documented interface, so the installed base is read live. The CRM is a cloud product with an API, so contract status is read live too. The visit history sits in a database an employee built years ago, with no interface at all, so it is exported nightly and read from the export.
Writing is narrower than reading. The agent writes only to the ticket. The ERP stays read-only until the department decides otherwise, and that decision is recorded with a date.
What you need to bring, and when it is not worth it
You need somebody who knows the systems, in-house or at your IT service provider, and their time. You need access to a test system or at least a copy of the data. You need to check the terms of your software contracts, because some SaaS products restrict what an interface may be used for. And you need patience with your ERP vendor, because interface questions go through their support queue.
Integration is rarely worth it as a project of its own; it is the part of another project that decides whether that project holds up. It is not worth starting when the core system is being replaced within the year. And it is worth a hard look when the only route is automation at the user interface on a system that updates every month; then the maintenance may cost more than the case brings.
How it differs from the neighbouring services
Integration is the connection. Process automation is a process that runs across that connection, and AI agents and knowledge systems are what gets connected. Where the gap between your systems needs its own screens and its own data, it stops being integration and becomes custom software.
The next step
We weigh the integration for every candidate during the assessment, before a use case is committed to, because a case that cannot reach its systems is not a case. If you already know which systems are involved, bring the list to the free introductory call.