AI Assistant and CRM: What Works in the Pairing and What Breaks

The assistant talked to a customer overnight, worked everything out and promised a call in the morning. In the morning the manager opens the CRM and finds nothing: the conversation stayed in the chat and nobody knows about it. By lunchtime the customer has stopped replying.

This is the most common way to waste a deployment. An assistant with no link to the CRM does not remove chaos, it moves it somewhere new where it is even harder to notice. Let us go through how the pairing works and where it breaks.

What belongs in the record

The temptation to log everything is strong, but a record with the entire transcript dumped into it is useless: nobody reads it. What you need is a short set of fields that lets a manager grasp the situation in ten seconds.

• Contact and channel. Where they came from: website, messenger, phone. This also determines where to reply.
• The task in the customer own words. Not a retelling in your terminology but how they phrased it themselves.
• Urgency and budget, if established. An empty field beats an invented value.
• What remains unclear. The most valuable field: it tells the manager where to start.
• A link to the full conversation. A link, not the text itself. Whoever needs it will open it.

A sanity check: the manager should understand the record without opening the conversation. If understanding requires reading the whole thread, the fields were chosen wrongly.

Where exactly to write: deal, lead or task

Technically you can create anything, and the choice decides what your funnel looks like in six months.

1. Create a deal for every inquiry. The funnel fills with noise, conversion drops to an embarrassing figure, and you can no longer read anything from it.
2. Create a lead, and a deal only after qualification. The sensible default: raw is separated from working.
3. Create a task for a manager and add the funnel entry by hand. Suits businesses with few, large deals.

Decide this before work starts, not after. Reworking funnel structure on a live database is a separate painful project.

What happens when the CRM is unavailable

It will happen. Maintenance, an expired access token, a provider outage, a change in the interface. The question is not whether, but what then.

The bad answer: the inquiry disappears. The assistant tried to write, got an error and forgot. The customer meanwhile is confident everything is fine, because they were answered.

Correct behaviour has three parts.

• A queue. If it did not save, put it in a queue and retry rather than discard.
• A fallback channel. If it still fails an hour later, send an email or a message to whoever is responsible. Inelegant, but the inquiry survives.
• A notification to a human. The error must be visible to someone. An error known only to a log file is an error that does not exist.

Ask a vendor about this directly. "That will not happen" means nobody thought about it, and the first scheduled maintenance on your CRM will cost you a day of inquiries.

Duplicates will definitely appear

The same person will write to the site chat, then to a messenger, then call. To the CRM these are three separate inquiries, and a month later you have three records for one customer being worked by three different managers.

This cannot be solved completely, but it can be reduced to a tolerable level.

• Search before creating. By phone and email, normalised to one format: two different notations of the same number are the same number, and the system does not know that by itself.
• Do not merge automatically by name. Namesakes exist, and merging two different customers is worse than two duplicates.
• Flag the suspicious ones. Let a person decide: it takes them five seconds, while an automation mistake can cost a deal.

Who owns the conversation: assistant and manager together

A subtlety usually overlooked. The assistant answers at night, a manager joins in the morning. What happens if the customer writes again at lunchtime?

If the assistant keeps answering over the manager, the result is a mess: the customer sees two different voices and the manager does not know what happened without them. You need an explicit rule: once a human enters the conversation, the assistant goes silent on that inquiry until the manager hands it back.

Agree this at the specification stage. It looks like a detail and turns out to be the thing that makes a deployment feel unfinished.

What to do with history from before the deployment

A separate question that surfaces mid-project: you have years of conversations, calls and notes. What happens to them?

• Do not migrate everything. Processing the archive usually costs more than it returns. Migrate open deals and customers from the last year; leave the rest where it is.
• Do not plug the archive in as a knowledge base. The temptation is strong - it is full of real answers from your managers. The problem is that it is also full of outdated prices, cancelled terms and mistakes. The assistant will repeat all of it confidently.
• Use the archive differently, as a source of questions. Read the last hundred conversations and write down what people ask. That is the best foundation for a knowledge base - only written anew and verified.

Access and security

An integration means an external system gets a key to your customer database. This deserves more attention than it usually gets.

• A separate account for the integration. Not the director personal login and not a shared admin one. A separate one with a clear name.
• Minimum permissions. The assistant needs to create deals and read reference data. It does not need to delete deals, export the whole database or change funnel settings.
• Know where the access key lives. If only the vendor has it, you depend on the vendor completely.
• Be able to revoke access in a minute. Check that you know how before you need to.

While you are at it, ask where the conversations themselves are stored and for how long. This is your customers personal data, and you will answer for it, not the vendor.

An order of work that saves a month

1. Tidy the CRM first. If fields are duplicated and half the deals sit in unclear stages, automation will not fix that - it will cement it.
2. Describe the path of an inquiry on paper. From arrival to closure, with an owner at each step.
3. Connect one direction and one channel. Test on real inquiries for two weeks.
4. Add the remaining channels. One at a time, not all at once.
5. A month later, look at what actually lands in the records. Almost always it turns out one field is redundant and another is missing.

Frequently asked

We have no CRM, we work in a spreadsheet. Is that acceptable?

It is, and at the start it is more honest than buying a CRM for the sake of the assistant. A spreadsheet survives a couple of dozen inquiries a month. But decide in advance who looks at it and when: an inquiry landing in a spreadsheet opened once a week is lost just as reliably as one recorded nowhere.

What if our system is custom-built?

The only question is whether it can accept data from outside. If it can, the work is about the same as with an off-the-shelf CRM. If it cannot and there is nobody to add that, the fallback remains: an email or message to whoever is responsible, with manual entry. Worse, but it works.

Who is responsible if the assistant records the wrong data?

In front of the customer, you are - not the vendor. So the contract should fix not only development deadlines but the response time for errors after launch. Errors will happen; the question is whether they are fixed in a day or a month.

Can we skip the integration and just forward conversations by email?

For the first month, yes, and it is a cheap way to test the idea. After that email stops coping: you cannot tell from it who took the inquiry and how it ended. That is precisely what separates it from a CRM.

Signs the pairing was done badly

• Managers have started their own file or notebook alongside the CRM. That means they do not trust the system.
• Many fields in the records are empty. Either the assistant is not establishing what you planned, or there are too many fields.
• You have to open the conversation to understand the record.
• Nobody knows how many inquiries failed to save last month. That means nobody is counting errors.

In short

The CRM link is not a technical detail at the end of the project but the reason the project exists. An assistant that converses well but leaves no trace in your system creates the feeling of work instead of the work.

Agree three things upfront: what goes into the record, what happens during an outage, and who owns the conversation once a human joins. What is worth establishing with the customer is covered in the piece on qualification, and what the whole thing costs in the pricing breakdown.