What does connecting a support tool to your CRM actually do?
Most CRM integrations do three different jobs, and vendors tend to describe them as one feature. The first is lookup: when a message arrives, the support tool searches your CRM for a matching contact and shows the agent what it finds. The second is logging: the conversation, or a summary of it, is written back to the contact record as a note or an activity. The third is record creation and updating, where the support tool creates contacts, edits fields, opens deals, or moves a lifecycle stage.
Lookup carries very little risk. Logging carries some, because it adds volume to records that other teams read every day. Creation and updating is where integrations cause real damage, because the support tool is now writing into the system your sales and finance people treat as authoritative.
So the first thing to check is which of the three you actually want, written down before you look at any setup screen. Plenty of teams want lookup and logging only, then find out weeks later that the connector had been creating a contact for every anonymous chat visitor who typed hello and left.
Which records should the integration be allowed to create or change?
Ask for a list of every object the integration touches: contacts, companies or accounts, deals or opportunities, activities, notes, tasks, and any custom objects. Then ask which of those it can be stopped from touching. A connector that only offers an all-or-nothing permission is a connector you should scope carefully, because you cannot narrow it later without disconnecting.
Identity matching deserves its own look. Your CRM almost certainly treats email as the unique key for a person. Support conversations do not arrive that way. A WhatsApp message arrives with a phone number, an Instagram message with a handle, a web chat with nothing at all until the visitor volunteers something. If you run messaging channels, confirm how the tool matches a phone number to an existing contact, what it does when two contacts share that number, and what it does when it finds nothing. The honest answer from a vendor is usually that it creates a new record, which is fine if you planned for it and messy if you did not. This matters more as you add channels, so it is worth settling before you turn on something like WhatsApp rather than after.
Also ask whether anonymous or unidentified conversations can be held in the support tool without being pushed into the CRM at all. Keeping unqualified noise inside the shared inbox and only promoting a contact when a real person identifies themselves is usually the cleaner arrangement.
How do you decide which system owns each field?
Field mapping is the part everyone skips and everyone regrets. For each field the integration writes, decide which system is the source of truth, and what should happen when the two hold different values.
Three behaviours are worth asking about by name. Does the integration overwrite an existing value, append to it, or skip it? Does it write an empty value over a populated one when its own field is blank? And can a given mapping be made one-way? That last question is the one that prevents the classic failure, where a support tool with a blank company field quietly wipes the company name your sales team spent months collecting.
Pay particular attention to fields that drive automation on the CRM side: lifecycle stage, record owner, status, and anything that triggers an email sequence. If a support conversation can move someone back to an earlier lifecycle stage, it can also drop them into a nurture campaign they already graduated from. Map those fields last, deliberately, and leave them unmapped if you are unsure.
Who will be able to see the customer data once it crosses over?
A CRM integration moves customer data into a system with a different permission model and a different audience. Support agents see conversations. CRM users see contact records. Once conversation transcripts are logged as notes, anyone with CRM access can read them, including people who were never meant to see billing complaints or health details or whatever else customers type into a chat box.
Check how the connection authenticates. If it uses one person's personal CRM login, the integration inherits that person's permissions and breaks when they leave the company. A dedicated service account with its own scoped permissions is the better setup, and most CRMs support one.
Then check the practical privacy questions: whether transcripts are stored in full or summarized, whether the tool can redact or avoid writing sensitive content, whether you can delete data from both systems when a customer asks, and which subprocessors are involved. You do not need a legal review to ask these, but you do need answers in writing before customer data starts flowing.
How do you test it before it touches live customer data?
Use a sandbox if your CRM offers one. If it does not, create a small set of test contacts with addresses you control, and run the full set of scenarios against them: a brand new person, an existing person who matches cleanly, a person who matches two records, a person with a phone number but no email, and a conversation that gets handed from the AI to a human.
After each run, open the CRM record and read what was written. Not the integration log, the actual record, the way a salesperson would see it. This is how you catch the sync that technically succeeded but logged a transcript as an unreadable wall of text, or stamped the wrong owner, or created the activity against a company instead of a person.
Plan the reversal before you start. Know how to disconnect, how to find every record the integration created, and how to bulk delete or merge them. If you cannot describe that cleanup in a couple of sentences, you are not ready to connect production data yet. Rolling out one channel at a time makes the cleanup smaller if you need it.
What happens when the sync fails or a record does not match?
Every integration fails sometimes. API tokens expire, CRM rate limits get hit, required custom fields reject a write, and a record occasionally gets deleted on one side while the other still points at it.
What matters is whether you find out. Ask whether failed writes are retried, whether they queue and replay or simply drop, and where errors surface. An error log nobody has ever opened is the same as no error log. Something that reaches a human, an email or a Slack alert, is the minimum worth having.
Ask also about duplicates, because that is the most common quiet failure. A connector that retries after a timeout can create the same activity twice, and nobody notices until a contact record has a dozen copies of the same note. Find out whether writes are idempotent, and whether there is a merge path when duplicates appear anyway.
How will connecting a CRM change what you pay?
Integrations have a pricing dimension that is easy to miss. On the support tool side, CRM connectors are frequently reserved for higher plans, so the integration you evaluated may not exist on the tier you budgeted for. On the CRM side, API call volume can count against a quota, and some CRMs charge for the integration-capable tier too.
There is also a people cost. Once the CRM is connected, more of your team wants access to the support tool: the salesperson who needs context, the ops person who watches the sync, the owner who wants to read conversations. On per-seat pricing, every one of those people is another line on the invoice, which pushes teams into sharing logins and losing the audit trail.
Corebee is flat at $99 per month with unlimited seats and unlimited AI conversations, and no per-resolution fee, so adding the people who need visibility into a CRM sync does not change the bill. Check the pricing details against your own plan either way, because the per-seat question is one you should answer before the integration makes it urgent.
What should you ask the vendor before you commit?
Ask for a written answer to each of these: which objects can you write to, can writes be limited or made one-way, how do you match an inbound phone number to a contact, do you ever overwrite a populated field with a blank, what authentication does the connection use, where do sync errors surface, and how do we remove everything you created if we disconnect.
It is also fair to look at how different tools approach this. Zendesk and Freshdesk come from a ticketing tradition and model the CRM link around tickets and organizations. Intercom leans toward lifecycle and product data. Gorgias is built tightly around ecommerce platforms, so its CRM thinking follows order history. Chatwoot is open source and self-hostable, which gives you direct database access and correspondingly more work. Help Scout and Tidio favour simpler setups with fewer mapping controls, which suits smaller teams and frustrates larger ones. None of these is wrong; they are different defaults, and the right one depends on which system you want to be authoritative. A side-by-side read of the alternatives is a reasonable use of an afternoon.
One last check that has nothing to do with the CRM: make sure the answers your support tool gives are good before you start writing them into permanent customer records. An AI that answers from your website and a maintained knowledge base, and that hands off to a person when it is unsure, produces conversation logs worth keeping. One that guesses produces a CRM full of bad notes, and bad notes outlive the conversation that created them.