Connecting AI to your ERP, CRM and other systems

There are three ways: a standard connector in a workflow tool such as n8n, a custom integration through the system's API, and, if there's no other way, a workaround through email or an export. Which one you use depends on the package, your version and what the AI needs to read or write. A single process often uses two or three of them side by side.

1. A standard connector in a workflow tool

Workflow tools such as n8n, Make and Zapier have ready-made connectors for a lot of common software. You don't have to work out how to log in or what a customer looks like in that system. You choose the system and the action, such as 'find customer' or 'create draft order', and you're connected. Then you build the flow around it: an email comes in, AI reads the attachment, looks up the customer, prepares the order and sends a notification to Teams.

This is the fastest and cheapest route, and also the easiest to maintain. We build a lot in n8n: you can run it in the EU or in your own environment, and AI steps are a normal part of it.

2. A custom integration through the API

An API is the fixed entrance through which software talks to other software. If a package has no standard connector, or the connector doesn't do what you need, you talk to the API directly. That can be from an n8n workflow, or from fully custom-built software.

That's more work. You have to work out how logging in works, which fields are required, what happens if the system briefly doesn't respond and how to prevent the same order being created twice. But it's the route with the most freedom: anything the API allows, you can build.

3. If there's no other way: email or an export

Some systems have no API, or you can't get access to it. Then there are workarounds. The system emails a report every night or creates an export in Excel or CSV, and the AI reads it. Or the AI creates a file that someone imports with one click. Or the system can receive and process emails.

That works, but it's slower and more fragile. You're working with last night's data instead of today's, and if someone changes the layout of the export, it breaks. Use it as a bridge, not a destination. If the package gets an API or is replaced, switch over.

For each system you arrange four things: which account the AI logs in with and what permissions that account has, what it may read and what it may write, a log of everything it does, and a person who approves before anything is written to the system for good. That sounds like paperwork. It's the difference between a useful helper and a risk.

Permissions: its own account, with as little as possible

Never let the connection run on Piet's account. If Piet goes on holiday or leaves, everything stops, and in the log it looks as if Piet created forty orders at three in the morning. Give the AI its own account or its own key, with exactly the permissions it needs for this task. No more.

Reading and writing: make it explicit for each type of data

Reading is usually low-risk, writing isn't. For each system, record what the AI may do:

• Read: customer details, order status, stock, price list, the history of a ticket
• Prepare: a draft order, a draft journal entry, a draft answer, a note in the CRM
• Change itself: only what's cheap to fix, and only once the numbers show it's going well
• Never: make payments, delete customers, change prices or credit limits

Also think about personal data. May the AI see salaries or medical data? Usually not. Follow the permissions the system already has, and only send the language model the data the task needs.

A log: what, when, why and who approved

Record every action: what input came in, what the AI made of it, what it put in which system and who approved it. If a customer calls about a strange order, you can see what happened in a minute. Without a log you spend an afternoon puzzling it out, and afterwards you still don't know whether it was the AI or a colleague.

A person who approves before anything is written

The AI prepares, a person approves. The draft order sits in the ERP, the employee checks it and confirms it. That takes seconds instead of minutes, and a mistake by the AI never reaches a customer or your books unseen. How to keep that approval light is explained in human in the loop.

And also

• A test environment. Don't test in your live system. Ask your supplier whether there's a test or demo environment.
• Error handling. What happens if the ERP is briefly down? A good connection tries again later and reports it if it keeps failing.
• An owner. Someone who knows the connection exists, and who gets the call when something changes.

Because the makers of workflow tools mainly build connectors for software that's widely used around the world. A custom-built ERP, industry software, a customer portal or a package used mainly in the Netherlands often falls outside that. Then you build the connection yourself, through the API. That's almost always possible, but it takes more hours.

In the APO method we record for each system whether a standard connector exists. If it doesn't, that process step gets the label custom work, and that increases the build effort. That's no reason not to do it. It's a reason to factor it in beforehand, so the business case adds up and nobody gets a shock halfway through.

Where do those extra hours go?

• Investigating. Reading the API documentation, and discovering what isn't in it.
• Login and security. Requesting keys, often through the supplier or your IT partner, and storing them securely.
• Edge cases. What if a customer is in the system twice? What if the system can only handle a limited number of requests per minute?
• Testing. With real examples, in a test environment if there is one.
• Maintenance. If the supplier changes something in the API, the connection has to change with it.

Also allow for lead time. Forty hours of build work isn't one week. There's coordination in between, waiting for access and a test round with the people who do the work. So request access to your systems as early as possible. Waiting for a key is a classic cause of delay.

It works wherever people now retype or look up data between systems. Below are a few examples per type of system. The packages are examples: exactly how it works depends on your version, license and configuration.

AI in your ERP and accounting (such as Exact, AFAS, SAP or Microsoft Dynamics)

• Preparing orders from email and PDF as a draft order, with a check that the customer and items exist
• Reading purchase invoices and preparing them as a draft journal entry, checked against the purchase order
• Turning supplier product information into product copy, as at EasyToys in six languages

AI in your CRM (such as Salesforce or HubSpot)

• After a customer conversation, adding the summary and agreements as a note to the right customer
• Reading new requests from the web form, completing them and passing them to the right account manager
• Preparing a follow-up email based on what's in the CRM

AI in your email, calendar and documents (such as Microsoft 365 or Google Workspace)

• Sorting the shared inbox and preparing a draft answer for each email
• Making documents in SharePoint or Google Drive searchable for an assistant that answers with sources, see what is RAG?
• Combining an overview from three systems and putting it in the management team's inbox every Monday

AI in customer service

This is where the systems often come together. A customer asks where their order is. An agent reads the question, looks up the order in the ERP and prepares an answer in the helpdesk. At one of our enterprise clients, an agent prepares the answer this way, with the right order information included. There, 80 percent of the 6,000 customer questions a month now have a prepared answer before the ticket opens, compared with 30 percent at first. An employee checks and sends it. More in AI by department.

Most mistakes have nothing to do with AI. They're about permissions, testing and management. These are the ones we keep running into:

• The connection runs on a personal account. Until that person goes on leave or changes their password.
• Write access to everything. 'Then we won't have to change it later.' An AI with admin rights can do everything wrong, including things it never needed to do.
• Writing straight to the system for good. Without a draft and without a check. A customer notices the first mistake, and after that nobody trusts the system.
• No log. Something goes wrong and nobody can see what the AI did.
• Testing in your live system. Forty test orders among your real orders, which someone then gets to delete by hand.
• Starting with the technology. 'We have an API key now, what shall we build?' Start with the process: which step takes the most time now, and which systems belong to it?
• Connecting everything at once. Five systems in one project. Start with one process and the two or three systems that go with it.
• Forgetting the package administrator. Your IT partner or key user knows which fields really matter and when the next update is coming. Involve those people from day one.
• No management after go-live. Packages get updates, fields get renamed, keys expire. A connection nobody monitors will one day quietly break. Ideally you notice before a customer does.

We start with the process, not the connection. In the AI Quick Scan we spend one day at your site mapping how the work runs now, step by step, including the systems. For each step we check whether there's a standard connector or whether it will be custom work, and we factor that into the business case for each opportunity. The Quick Scan costs € 6,000 one-off.

After that we build within the AI Partnership, from € 4,500 per month. This is how we work:

1. 01Read first. The AI fetches data and puts its proposal next to the employee's work. That way you see whether it understands correctly, without any risk.
2. 02Then prepare. Drafts in the system, a person approves and confirms. With its own account, the smallest permissions and a log.
3. 03Only then more room. Only for steps where the numbers show it's going well, and where a mistake is cheap to fix.

We build a lot in n8n, and custom where needed. The data stays in the EU: on your own infrastructure or with a European provider. Whatever goes live then falls under a maintenance contract from € 245 per month, including AI usage. With Bronze it runs on your own servers, with Silver and Gold on our platform, on servers in Germany with a European provider. Code, data and documentation are yours. All amounts exclude VAT.

And if a connection costs more than it delivers, we'll tell you. Sometimes an export that someone imports once a day is simply good enough.