Why AI automation breaks at integrations - and what to check before development

Imagine an ordinary Monday. There is an email from a client asking to move a meeting and add one more person. Your CRM - the program where the team manages clients and sales - still shows the old time. In a spreadsheet, the manager has already written “agreed.” You show all three sources to an AI assistant, and it confidently suggests a fourth option: send a confirmation for an available slot.

It looks as if the AI made a mistake. In reality, it received conflicting instructions and does not know which one has the final say. If you give it permission to act, it may do more than write an unfortunate text. It may change the state of a deal, create a task for the wrong person or leave the team with two different agreements.

That is why it is worth running a process audit before development - a brief review of how work actually moves from one person and system to another. This is not a check of whether your CRM is “modern enough.” It is a way to avoid handing a new tool a process whose rules still live in the team’s heads.

AI is good at reading emails, finding the request in them, explaining the content briefly and suggesting a next action. But there is an important boundary between “read” and “change a working record.”

Schnittstelle is the German word for an integration, meaning the point where two systems exchange data. This is where context is most often lost. One service sends a client’s name without a deal number. Another does not say that a record is already closed. A third accepts any update, although only the responsible manager should make it. AI cannot honestly guess a rule that nobody has written down.

The problem is often not the data exchange itself, but its meaning. For example, the “stage” field in a CRM may mean that a manager has prepared a proposal. The same word in a spreadsheet may mean that the client has already approved it. Technically, both records can be passed between systems. But automation will not distinguish a working note from a decision unless you define that distinction.

An old system is not a sentence

This is not a problem limited to old software. A Zapier survey of large companies names complex integrations with legacy systems, cost, vendor dependence and a lack of needed skills as obstacles to AI adoption. The conclusion for a small B2B business is simpler: you do not need to declare your existing system unusable. You need to check one specific handoff - what comes in, what changes, who confirms it and what comes out.

For example, in a company providing Gebäudereinigung - professional building cleaning - an enquiry may arrive through a website form, email or phone call. If all three channels ultimately end up in the CRM, AI can only read new enquiries, extract the address and property type, and prepare a draft card. But if a manager still checks the service area in a personal spreadsheet, the agent must not independently make a promise to the client. It can show the mismatch and ask for a decision.

Another example: if a client agrees to a price in an email but the CRM still contains a different amount, automatically sending a contract is a bad first step. A useful first run can instead collect such discrepancies into one list for the manager. You do not lose control, but you can see exactly where the process diverges: in correspondence, data entry or the rule by which the team considers an amount final.

A process audit does not require a technical lecture. Take one recurring process: handling a new enquiry, approving a commercial proposal, sorting email or handing a project over for delivery.

It is useful to examine not an imagined ideal process, but one recent case. Open the email, the CRM card and the document where the team clarified something. You will then quickly see not only the official route, but also the detours: a message in a messenger, manually copying a number, the agreement that “I will update it later.” Do not try to describe the whole company at once or prepare a long presentation. Choose the point where the team regularly copies, asks again or searches for the latest version.

Then go through six questions in the order of the actual work.

1. Where does the request start? Write down not “from a lead,” but specifically: from a form, email, call, messenger or a manually created card. This helps you avoid forgetting the channel that exists only because “it is more convenient this way.”
2. Which source is the Quelle der Wahrheit - the record people trust when data conflicts? For price, this may be the approved proposal; for the deal status, the CRM; for the visit date, the calendar. If there is no answer, do not let AI change that state.
3. Which state transitions exist? Name them simply: “new enquiry,” “clarification needed,” “proposal sent,” “approved,” “closed.” Next to each transition, write what must happen to move forward. Not “when everything is ready,” but “the client approved the amount in writing.”
4. Who owns each transition? The owner is not the person who sometimes helps, but the person who has the right to say: “yes, the status has now changed.” If there is no owner, AI will have to guess who is responsible or follow the last random action.
5. Where may AI read, and where may it write? Leserecht means permission only to view data; Schreibrecht means permission to change it. At the start, it is more useful to give AI broader Leserecht and narrow Schreibrecht, or no Schreibrecht at all. This lets you test the rule against real exceptions without putting important records at risk.
6. Which cases do not fit the normal path, and what completes the work? Write down at least the exceptions the team mentions: a duplicate enquiry, a client who changed terms, missing data, an existing contract, denied access. Separately name the proof of completion: the email was sent and saved, a task has an assignee, the record was updated in the source of truth, a person confirmed the decision.

You do not need to draw a complex diagram. One sheet or shared document is enough, as long as every step shows the input, source of truth, responsible person, permitted action, exception and proof of completion. Such a map is more valuable than a beautiful demo because it shows what actually needs to be built and what first needs agreement without any development. If two people answer the question “who can change the status?” differently, that is already a result. Do not argue with AI about the accuracy of its answer. First agree on the rule manually, add it to the working description and only then hand it to automation.

A canary is a small controlled run that tests an idea in a narrow area without handing it the whole process. For AI, it is especially useful where the result can be read, checked and reversed.

A good canary has three characteristics. It takes one type of input, does not change a critical record without a person and leaves a trace that lets you understand why the result appeared. For example, AI reads emails with the subject “enquiry,” extracts facts only from the email itself and prepares a response draft together with a link to the source. A manager approves or rejects it manually. This is how the Klar mail triage example works: not only the AI suggestions matter, but also their link to evidence and human control.

Before such a run, agree on what you will consider an error. Not the abstract “it wrote badly,” but understandable cases: it missed a required detail in the email, mixed up the client, suggested an action without a source or sent something to a queue that does not belong to that queue’s topic. Then the person checking the results does not simply correct everything silently, but returns the process to a specific rule.

The boundary of a safe launch

A bad canary looks different: “let the agent manage all leads on its own.” It contains too many different rules, channels and consequences. When something goes wrong, you will not understand whether email recognition, the integration, a routing rule or write permission failed. Such a launch is like repairing the wiring in an entire building with one switch: the lights may come on, but finding the cause afterwards will not be fun.

If you still need an action in the system, choose a reversible one. For example, AI does not change a deal budget but adds a “review needed” tag; it does not send an invoice but creates a draft; it does not close a task but adds it to a confirmation queue. Before launch, define who reviews that queue and how they reverse a mistaken action. Without this, “automatic” sometimes only means “the error had time to run ahead of you.”

Separating roles matters too. In a good working process, you keep decisions and accountability with a person, assign preparation to an assistant and give an agent a limited action under a defined rule. This is the kind of separation between human leadership, assistant support and agent automation proposed in approaches to workflow design and the rules that govern it.

The result should not be a report that is easy to put in a folder and forget. It should become a short working description that you and the team can use to make decisions.

Keep a map of one process with six fields: request source, source of truth, states, owner, AI permissions, exceptions and proof of completion. Add the boundary of the first launch: exactly what AI reads, what it suggests, what it does not change and who checks the result. Mark separately where a human decision is needed and where a pre-agreed rule is sufficient.

This description is useful not only to a developer. A new manager can use it to understand where to look for the current price. The process owner can see which decisions are hanging between roles. The person responsible for access can give the tool exactly the permissions needed for the first task. And you can compare providers’ proposals not by the promise that “we will integrate everything,” but by whether they see the real boundaries of the process.

After this, you may find that automation should not be built yet. For example, if commercial terms are approved in chat without a single record, and managers use different meanings for the status “ready,” first agree on a manual rule. This is neither defeat nor a rejection of AI. It is a way to remove a broken handoff before adding another service to it. A broken process is inventive enough without AI: it can lose the responsible person even across three tabs.

A controlled workflow can already be proof that the team knows how to build a process with checks. But it does not prove that every next task can safely be handed to an agent. That is why controlled AI systems should be assessed not by how impressive the first screen looks, but by whether it is clear where the agent stops, who sees its action and what confirms the result.

Do not start with the question “which AI should we buy?” Open one real process where people often compare email, the CRM and a spreadsheet. Take the latest example where someone asked “which status is correct?” and write beside it where there should have been one truth, who could change it and what was missing for completion.

You do not need to decide immediately which system to replace or how to connect everything. Your first task is to name the boundary of the problem in a way the team will recognise. When one case has a source of truth, an owner and proof of completion, a safe place for a small launch appears.

That is the first step. Once it is done, AI stops being a guesser between three versions of reality and can become a useful assistant in clearly defined work.