A sales lead at a 40-person company asks her AI assistant which deals to chase this week. It gives a careful answer about pipeline habits in general. It cannot see her pipeline. The deals live in the CRM, the unpaid invoices live in the accounting app, and the open complaints live in the support desk. Each one is a tab the assistant cannot open.
This guide is for the owner or sales lead who wants to connect AI to CRM data without hiring engineers. It covers what changes once the assistant can see the CRM, the four ways to set it up, and what to get right before it writes anything. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. The project's own site calls it an open-source standard for connecting AI applications to external systems.
What can your AI assistant do once it can see your CRM?
It can take on some of the non-selling work that fills a rep's week. Salesforce's sixth State of Sales survey found reps spend 70% of their time on non-selling tasks (Salesforce).
Four jobs usually come first:
- Prioritize leads. Ask which new leads look like your best customers. The assistant reads the records and returns a short, ranked list.
- Brief before a call. Ask for a one-page brief on the account. With the accounting app connected, the brief shows the overdue invoice. With the support desk connected, it shows the open ticket.
- Find quiet deals. Ask which open deals have had no activity for three weeks. The assistant lists them and drafts a follow-up for each owner.
- Update records. After a call, ask it to log the notes, move the stage and set the next task. This is the first job that writes, so it needs the most care.
Clean records matter here. In the same survey, only 35% of sales professionals said they completely trust the accuracy of their company's data (Salesforce).
The apps around the CRM matter as much as the CRM. A brief that misses an unpaid invoice can embarrass the rep on the call. Elaichi connects one assistant to HubSpot, Salesforce, Pipedrive, QuickBooks, Xero, Zendesk and 700+ apps in all through one connection.
What are the ways to connect AI to a CRM?
There are four, and each suits a different company. The right one depends on how many apps the work touches and how many people will use it.
| Option | What it is | Good when | Watch for |
|---|---|---|---|
| The CRM's own AI | AI features built into the CRM | The work stays inside the CRM | It is built for that one CRM |
| Per-person add-ons | Each person connects the CRM vendor's own MCP server to their assistant | One or two people, one app | Each person sets it up alone, with no shared rules across apps |
| A shared connection layer | One connection, such as Elaichi, between the assistant and every app | Several people, several apps | Someone has to decide the access rules |
| Engineers set it up for you | A team that connects the apps and builds the jobs | Nobody in-house has the time | Make sure you own what they build |
Per-person add-ons are now common. HubSpot's remote MCP server is generally available to all HubSpot accounts, and it can read CRM records and activity history and create or update contacts, companies, deals and tickets (HubSpot developer changelog, checked October 2026). HubSpot says all actions respect the user's existing HubSpot permissions. For Salesforce, the guide to each rep's own Salesforce access covers its hosted option.
A shared layer works differently. Elaichi gives every company the same address, https://api.elaichi.ai/mcp. Each person adds it to their assistant once and signs in as themselves. Apps are connected once in Elaichi, and the access rules and the activity log cover all of them. Under the default choice at sign-in, an app connected later needs no new step in the assistant.
When is the CRM's own built-in AI enough?
It is enough when the work starts and ends inside the CRM. If your team wants a summary of a deal's emails or a draft follow-up from one record, the AI built into your CRM may be all you need. You skip a second vendor, a second login and a second set of rules.
The same goes for one person and one app. If a founder wants HubSpot in their assistant and nothing else, HubSpot's own MCP server covers it. Elaichi is not needed there.
The case changes when a job crosses apps, or when many people use AI on the same data. A call brief that needs the CRM, the invoices and the tickets reaches past any one vendor's AI. So does one list of who may do what across all three apps, and one log of what the assistant did. That is the point where a shared layer earns its place.
Should each person's AI see only what that person can see?
Yes, and this is the rule to get right first. A shared admin login gives every person's assistant the admin's reach. A new rep could then read every deal, including the ones the CRM hides from them.
In Elaichi, every call runs as the person who signed in, in the organization they picked. Where the CRM should see the person, each person connects the CRM under their own login. The CRM then applies the access its admin already set, such as territories, record owners and private deals. Elaichi decides who may use a connection, and the CRM decides which records that login can read.
Some connections should be shared, such as a reporting account. Share each one only with the people who need it, because a shared connection runs on its owner's login to the app.
People leave, too. When someone is removed from Elaichi, their assistant's next call through Elaichi is refused. Their CRM user is a separate step inside the CRM.
Should the AI only read your CRM, or also write to it?
Start with reads, then add writes one job at a time. Most of the value is in reading: ranking leads, writing briefs and finding quiet deals all read. Most of the risk is in writing, because a wrong stage or a merged contact changes what everyone else sees.
In Elaichi, the sign-in screen has a box called "Run your connected tools". It covers reading and changing data in connected apps, so on its own it does not make the assistant read-only. To hold an assistant to reads, pick toolboxes of read tools at sign-in, or block the write tools with a restriction. A toolbox is a named set of tools. A restriction is a rule that allows or blocks apps and single tools for a role or for one person.
Add writes in small steps. Logging a call note or creating a task is low risk. Changing a deal's owner or amount is not. Let the team use reads for two weeks, check the activity log, and then turn on the first write job.
Which CRM actions should you restrict?
Restrict anything that deletes, merges, works in bulk or changes who can see what. One bad call there reaches many records, and none of the four common jobs needs those actions.
A short list to start from:
- Deletes of contacts, companies or deals.
- Merges of duplicate records.
- Bulk updates, and catch-all tools that can change any kind of record.
- Changes to users, roles and permissions inside the CRM.
In Elaichi, a restriction names whole apps or single tools, for a role or for one person. A block always beats an allow. A restricted tool cannot be run. If the assistant searches for it, it sees only the name, marked as restricted. A delete tool also needs a separate box at sign-in, "Delete data and remove access", which is never ticked by default.
A new rule takes about two minutes to reach everyone. Set the rules before people start, then test them as an ordinary member.
What should the activity log and data storage look like?
Every action the assistant takes should land in a log you can read, and you should know where your data is kept. Without a log, nobody can say what the assistant changed last Tuesday, or for whom.
Elaichi writes one entry per tool-call attempt, succeeded or failed. Each entry names the person, the app, the account the call reached and the assistant that made it. Every member can read their own entries. An admin, or a read-only Auditor, can read the whole organization's log.
For storage, Elaichi has three regions, EU, US and APAC, chosen when the organization is created and fixed after that. For EU or US, the organization's data store stays in that region. The activity log for every region is kept in the EU, as the privacy policy says. Elaichi does not see your conversations with the assistant; it sees only the action the assistant asks to run. The security overview has the rest.
How do you connect AI to CRM without an engineering team?
Pick one job, connect the apps it needs, set the rules, then test with one person. An admin and one person who does the work every day can do it together.
- Pick one job, such as the brief before a call, and list the apps it reads.
- Connect the CRM and those apps in Elaichi. Each rep connects the CRM under their own login.
- Write restrictions on the sales role: reads first, with deletes, merges and bulk tools blocked.
- Add https://api.elaichi.ai/mcp to your assistant's connector settings. Each person signs in once.
- Run the job as one rep, then read the activity log and check each entry.
- After two weeks, add the next job or the first write.
The technical walkthrough for IT has the details of step 4. Many AI projects stall between the demo and daily use, and why AI pilots stall looks at that gap.
If nobody has the time, Elaichi's forward deployed engineers do this with you. They learn how your team works, write a plan you approve, set it up in your own apps, test it on real work and hand over a written guide. You own everything they build. The services process is described step by step, and the use cases page shows the same pattern for other teams.
