AI Chatbot CRM Integration

Start With a Data Contract, Not an API Key

The quickest way to wreck a CRM is to let a chatbot write to it for a month without deciding exactly what it writes. Sales teams end up with three records for one person, deals parked in a pipeline stage nobody uses, and qualification fields that read “User: hi”. Cleaning that up costs far more than planning it would have.

Before anyone touches credentials, we draft a one-page data contract with your team. It lists every CRM object the chatbot may touch, the fields it may set on each, where each value comes from in the conversation, and the fields it must never modify. A typical contract looks something like this:

The contract also names any custom properties the integration needs, such as Chat intent or Chat transcript URL, so an administrator creates them once with the right data types instead of the integration inventing loose text fields. Once the contract is signed off, the build itself is mostly mechanical.

Lead, Contact or Deal: Choosing What the Bot Creates

CRMs disagree about what the first record for a new person should be. Salesforce separates Leads from Contacts and expects a conversion step once a lead qualifies. HubSpot keeps a single contact record and tracks progress through a lifecycle stage property. Other platforms blend the two ideas in their own way. The chatbot has to fit the model your team already works in, not whichever one is easiest to code against.

Rules of thumb we apply:

• Unqualified questions create the lowest-commitment record. A visitor asking about hours or coverage who leaves an email becomes a lead, or a contact at an early stage, never a deal.
• A deal needs a buying signal. A quote request, a booking or an explicit “we want to go ahead” opens an opportunity in the first stage of the correct pipeline. Every stage after that belongs to a person.
• Existing customers are routed, not re-created. When the bot recognizes a current client asking for service, it logs an activity on their record and creates a task or ticket for the account owner.
• Ownership follows your rules. If the CRM already runs assignment rules or round-robin distribution, the bot leaves the owner blank and lets them work. If not, the contract states who receives chat inquiries by service line or territory.

Vendor-specific mechanics live on our HubSpot chatbot integration and Salesforce chatbot integration pages. The principles here hold whichever CRM you run.

Matching People Who Are Already in Your CRM

Duplicate records are the most common complaint about chatbot-to-CRM connections, and they come from creating first and asking later. Our integrations always search before they write.

Normalize, then search

Email addresses are lowercased and trimmed. Phone numbers are converted to one international format, usually E.164, because “(713) 555-0142”, “713.555.0142” and “+17135550142” are the same phone to a person and three different strings to a database. Search then runs in a fixed order: exact email, then normalized phone, then, for business inquiries, company domain plus name. The first confident match wins.

Update rules when a match exists

On a match, the bot adds an activity and fills only fields that are empty. It never replaces a number a salesperson typed in by hand with whatever a visitor just entered in chat, because the visitor may be a spouse, an assistant, or simply someone who mistyped. Conflicting values go into the activity note for a human to review.

Uncertain matches

If search finds a name match with a different email, the bot creates a new record and flags it as a possible duplicate rather than guessing and merging. Merges are painful to reverse in most CRMs; a flag costs a staff member ten seconds.

Where the CRM supports a native upsert keyed on a unique field, we use it. That closes the gap between search and create in which two simultaneous conversations could each conclude that the same person is new.

OAuth App or Private Token: Who Owns the Connection

Most modern CRMs give an outside system two ways to authenticate. An OAuth app sends a CRM user through a consent screen and receives an access token plus a refresh token. A private app token or API key is generated in the CRM’s admin settings and stored by the integration. Both work, and they fail in different ways.

Whichever model applies, the same rules hold. Authorization comes from a dedicated integration user or service account where the CRM allows one, never from a salesperson’s personal login. Scopes are the smallest set the data contract requires: a bot that only creates contacts, notes and deals gets no permission to read invoices or delete records. Tokens live in a server-side secret store, never in the chat widget’s JavaScript. And a named person at your company knows the integration exists and what to do when the CRM warns that access is about to lapse.

Push, Pull and Webhooks Going the Other Way

The chatbot writing into the CRM is the obvious direction. The less obvious one is the CRM telling the chatbot, or the systems around it, that something changed.

• Writes from the bot happen in near real time when a conversation reaches a defined milestone, such as confirmed contact details or a quote request, not only when the chat window closes. Visitors usually just wander off without closing anything.
• Webhooks from the CRM are worth subscribing to when a deal changes stage or an owner is assigned. Those events can trigger a follow-up message, update a dashboard, or stop the bot from re-qualifying someone a salesperson is already working.
• Polling is the fallback when the CRM offers no webhook for the event you care about. It runs on a modest schedule with a modified-since filter, so it requests only records that actually changed.

Every webhook receiver we build verifies the CRM’s signature or shared secret, acknowledges the request quickly, and does the real processing in a background job, because many CRMs retry, and some eventually disable, webhooks that time out.

Rate Limits, Retries and Never Losing a Lead

Every CRM API caps how many requests a connected app may make in a given window, and the caps differ by vendor and subscription tier. We confirm the actual limits on your account during scoping and design comfortably below them. One chat can easily need four or five calls (search contact, create or update contact, search company, create deal, add note), so the budget drains faster than people expect when a campaign drives a traffic spike.

The design we use is an outbox. When a conversation produces CRM data, the bot writes a job to a queue it controls and immediately confirms to the visitor that their details were received. A worker sends queued jobs to the CRM at a pace inside the limit, retries temporary failures with exponential backoff, and attaches an idempotency key so a retry cannot spawn a second record. Jobs that still fail after several attempts move to a dead-letter list and alert a person, with enough structured data to key the lead in by hand. The visitor’s experience never depends on whether the CRM happened to answer within two seconds.

Should the Chatbot Read From Your CRM?

Writing is low risk compared with reading. A bot that can look up records can greet a returning customer by name, report on an open quote, or skip questions whose answers you already hold. It can also hand a stranger’s home address to anyone who types that stranger’s email.

Our default for a public website assistant is that it writes to the CRM and reads nothing personal from it. When reading earns its place, identity verification comes first: a one-time code sent to the email or phone already on file, or a signed link inside an email the customer received, before the bot reveals anything tied to a record. Even then, it sees only the handful of fields it needs through a narrow server-side function, never the full record. Internal assistants used by your own staff behind your login are a different case and can safely read much more; that kind of tool is closer to our AI automation work.

Mistakes We Find in CRM-Connected Chatbots

When a business asks us to audit an existing integration, the same problems keep appearing:

1. Every chat creates a contact, including the visitors who typed “hello” and left.
2. Lead source is blank or shows the chatbot vendor’s name, so reports cannot separate chat from organic form fills.
3. The full transcript is stuffed into a single-line text property and truncated.
4. The integration authenticates as a former marketing manager whose account was deactivated months ago.
5. Consent to receive text messages is implied rather than recorded, creating compliance exposure for any SMS follow-up.
6. Deals are created with a placeholder amount that distorts the pipeline forecast.
7. Nobody noticed the sync has failed since someone renamed a CRM field.

Each of these traces back to a missing line in the data contract, which is why that document is where our work begins.

How We Roll Out a Chatbot CRM Integration

1. Discovery. A free consultation by phone or video in which we review your CRM’s objects, pipelines and assignment rules alongside the conversations the bot handles.
2. Contract and quote. We draft the data contract, list the custom properties required, and send a fixed-scope written quote.
3. Sandbox build. Where the CRM offers a sandbox or developer account, the integration is built and tested there; otherwise we use clearly tagged test records that are deleted afterward.
4. Shadow mode. For a short period the integration logs what it would write without writing it, and your team reviews a sample against the transcripts.
5. Go live with visibility. After approval, writes switch on, together with a simple view of successful, retried and failed syncs.
6. Handover. You keep the data contract, a runbook for token renewal and common errors, and a list of what to revisit whenever pipelines or fields change.

EVOTECH IT LLC has more than 20 years in business and a 5.0 rating on Google, and works remotely with companies across the United States. We are not a certified partner of any CRM vendor and do not claim to be; we build against each platform’s published API and confirm its current behavior inside your account before writing production code.

Related services

Frequently asked questions