How to connect AI to your CRM without breaking your processes

What connecting means in practice

When people say “link AI to the CRM“, they usually mean one of three things — and they are three tasks of very different complexity.

• Reading. The solution sees the customer record and the enquiry history so it can answer to the point. The safest option: nothing in the database changes.
• Writing drafts. The solution creates a task, a comment or a draft email marked “for review”. A person approves it.
• Full write access. The solution creates and changes records itself: deals, statuses, contacts. It delivers the biggest effect and requires the most preparation.

Most projects are wise to start at the first level and move on only once the team is confident the answers can be checked.

Which data to give the model

The temptation to hand over the whole database is understandable, but it makes the solution both more expensive and worse: the more unnecessary fields, the more often the model latches onto the wrong thing.

The minimum set

For the first useful answers, four things are usually enough: who the customer is, what they bought, what stage the enquiry is at and what they have already been told. That is enough to stop the answers being generic.

What is better left out

Personal data not needed for the answer, payment details, employees’ internal comments about each other. The rule is simple: if a field does not affect the answer, it does not go into the integration.

What to do about history

An archive going back several years rarely improves the answers and noticeably increases processing costs. The usual approach is to take the current period and widen it when it is clear the data is not enough.

Access rights: reading and writing are different decisions

Rights should be granted through a separate technical account, not in an employee’s name. That way you can see exactly what the solution did, and access can be revoked in a single action without touching people.

• A separate account. In the CRM log, the solution’s actions are visible separately from the team’s.
• Minimum rights. Start with read access to the entities you need. Write access is added once there is a confirmed scenario for it.
• Object-level limits. Access to deals does not mean access to settings, users and exports.
• Reversibility. Everything the solution writes is labelled, so it can be found and rolled back.

What to check before the first launch

• A test environment. For the first days the solution works on a copy of the data or a limited sample, not the whole database.
• Behaviour on an empty field. What the solution does when data is missing: stays silent, asks, or makes something up. The third must not exist.
• Duplicates. A repeated run must not create a second identical record.
• Rate limits. CRMs have limits on API calls. Better to learn them in advance, not on launch day.
• Who owns failures. Agree in advance where the alert goes and who looks at it.

The mistakes that cost the most

• Integrating before describing the process. If the process is not described, the solution automates the mess and makes it faster.
• Writing without a label. A month later nobody can tell what a person created and what the solution did.
• One account for everything. The solution, the bot and the exports under shared rights: at the first problem you have to switch everything off at once.
• No owner on the business side. Technically the integration works, but nobody can decide what counts as a correct answer.

Frequently asked questions