How to Choose a CRM in 2026 When Your Customers Message You Instead of Emailing

Your last twenty customers reached you in a DM. Your CRM shortlist is three products built around an email thread, a phone call, and a form fill, and at least two of them will tell you they support WhatsApp. Only one of those two means it the way you need it.

This is the evaluation framework in the order that actually matters: channel coverage, data model, automation depth, pricing model, migration cost, and exit. There is a scoring rubric near the end you can copy into a sheet, a list of questions vendors do not enjoy answering, and two sections where the honest recommendation is to buy nothing, or to buy the big incumbent instead of us.

CRM buying goes wrong at the channel question, not the feature list

You will read that somewhere between 30% and 70% of CRM projects fail. Go looking for the study behind that number. What you find is a blog post citing a blog post citing a webinar slide, and a range so wide it is really a confession that nobody measured anything. We are not going to use it, and you should be suspicious of any buyer guide that opens with it.

What we can say without inventing data comes from mechanics. The decisions inside a CRM purchase are not equally reversible, and almost nobody sorts them by reversibility before they start.

Read the bottom row again. You can change nearly everything about a CRM after you buy it. You cannot change what it can see. If your customers talk to you on Instagram and your CRM cannot hold an Instagram conversation, there is no configuration, no plugin, and no consultant that fixes that. You buy again.

There is a second reason channel coverage goes first, and it is less flattering to our industry. Channel coverage is the single easiest thing for a vendor to overstate, because putting a WhatsApp logo on a page costs a vendor nothing and putting a real WhatsApp integration into a product costs them a quarter of engineering time. The gap between those two facts is where most bad CRM purchases live.

So the order in this guide is deliberate. Channel coverage first, because it is the only irreversible one. Data model second, because it is the expensive one. Then automation, pricing, migration, and exit, in descending order of how much they will hurt you if you get them wrong.

Before you take a single demo: count your last 50 first contacts

This takes about thirty minutes and it will delete half your shortlist before a salesperson ever gets your email address.

Open your inboxes. All of them: the shared email, the Instagram DMs, the WhatsApp Business app, the website chat, the Telegram account somebody set up two years ago. Walk backwards through the last 50 people who contacted you for the first time. Tally the channel where that first message landed. Not where the deal closed. Not where you prefer to talk. Where they started.

Three rules make this useful instead of decorative:

• Count the first inbound touch, not the last. Deals close on calls. That tells you nothing about what your CRM needs to see, because by the time you are on a call the contact already exists.
• Count conversations, not contacts. One person who messaged on Instagram, then WhatsApp, then email is three data points about your channels and one data point about your customer.
• Include the ones that went nowhere. The tally you want is of your front door, not your revenue. Excluding the people who never bought is how you end up buying a CRM optimised for the customers you already have.

Here is what a finished tally looks like for a small e-commerce and coaching business, the sort of company that thinks it needs a normal CRM. The numbers are illustrative, built to show the shape of the exercise rather than taken from anyone's account:

Now do the arithmetic that the demo will never do for you. A CRM that handles email and phone brilliantly, and nothing else natively, covers 16% of this company's front door. Not 16% of the features. 16% of the actual moments where a stranger decides whether to become a customer. Every other conversation arrives somewhere the CRM cannot see, gets copy-pasted by a human if it gets recorded at all, and shows up in your reporting as a contact with no origin story.

The fourth column matters as much as the second. Your CRM has to fit the tally you want in a year, not the one you have today. If the X DM row is zero because you have never tried it and you intend to try it in Q4, that is a requirement, not a nice-to-have. If phone is 4% and you actively want it to be 0%, do not let a vendor sell you a phone system.

Two honest outcomes of this exercise. If your tally comes back majority email and web form, close this article. You are the customer the incumbents were designed for, they are very good at that job, and everything below will read as an argument for buying HubSpot or Salesforce. If your tally comes back majority DM, keep going, because almost every generic "how to choose a CRM" checklist is about to give you advice that was written for the other company.

Channel coverage has four levels and the brochure never tells you which one you are buying

"Supports WhatsApp" is not a specification. It describes at least four completely different products, and the price difference between them is your entire evaluation.

Levels 0 through 2 all put the same logo on the same pricing page. Here is the test script that separates them, and it takes about twenty minutes per vendor during a trial:

1. Send yourself a DM from a brand new account the CRM has never seen. Does a contact appear automatically? With the message body, not just a notification? How many seconds did it take? A minute is fine. Five minutes means a polling job, which means you will answer late.
2. Reply from inside the CRM, then open the native app on your phone. Is your reply in the same thread, sent from your account? Or did it arrive from a differently named bot account, in a separate thread, with a robot avatar? This one test kills more integrations than any other.
3. Send an image and a voice note. Does the CRM render them, or show a grey placeholder saying "unsupported attachment"? Voice notes are not an edge case on Instagram and WhatsApp. They are how a large share of people under 30 talk to businesses.
4. Change your test account's @handle, then message again. Does the CRM know it is the same person, or did it just create a second contact? This is the data model test disguised as a channel test, and we come back to it in the next section because it is the one that ruins databases.
5. Message from a second account at the same time. Two conversations, one inbox. Does the assignment logic hold, or do both land unassigned in a pile?

If a vendor will not let you run these in a trial, that is your answer. A guided demo where the salesperson drives is not a test, it is a film.

The WhatsApp window is a product requirement, not a billing detail

This is where messaging CRMs separate from CRMs that have a messaging feature, and it is worth understanding before you evaluate anything, because it is a hard rule imposed by Meta and no vendor can wish it away.

On 1 July 2025, Meta moved the WhatsApp Business Platform from conversation-based pricing to per-message pricing. Per Meta's own pricing documentation, you are charged per delivered template message, in one of three categories (marketing, utility, authentication), and there is a 24 hour customer service window that opens when a customer messages you. Inside that window, non-template messages are free. Outside it, you cannot send a free-form message at all: you can only send a template, and you pay for it. There is also a 72 hour free entry point window when someone reaches you from a click-to-WhatsApp ad, during which any message type is free.

Now think about what that means for a piece of software. If your CRM does not model the window, a rep will open a conversation at hour 25, type a perfectly good reply, hit send, and one of two things happens: it silently fails, or the tool quietly converts it into a billable template with different wording. Neither is visible to the rep. Both are visible on your invoice, eventually.

Ask the vendor to show you the window countdown in the inbox, on a real conversation. If there is no countdown, no state indicator, and no different behaviour after hour 24, the integration is a Level 1 wearing a Level 3 costume, and you will find out in month two.

The same principle generalises. Every messaging channel has rules that are not features: rate limits, session windows, template approval, opt-out handling, and terms of service that bind you regardless of what the law in your country permits. A CRM either encodes those rules in the interface or it exports the risk to your reps. Our compliance playbook goes through the platform-terms layer in detail, and it is the layer most buyer guides skip entirely.

Where this framework points away from us

Two honest notes before the rubric flatters us later.

We have no phone channel and no SMS channel. If the phone row in your tally is meaningful, or if it is small only because you have not tried, this entire framework points away from CRM Solid and away from most messaging-first tools. Phone is a different engineering problem and we have not solved it.

What we do cover natively in one inbox: Telegram (multi-account, via MTProto), X/Twitter DMs, Instagram, Facebook, WhatsApp, LinkedIn, Bluesky, Reddit, email via any IMAP account, and our own live chat widget. If your tally is mostly those, the unified inbox is the product. If your tally is mostly phone calls, it is not.

The data model question that does not surface until month four

Channel coverage gets you the message. The data model decides whether the message means anything six months later. This is the part of a CRM evaluation that is genuinely hard to do from the outside, because every CRM looks identical on the contact detail page and completely different underneath it.

The core problem in messaging is identity. One human being is not one identifier. Sarah is @sarah_builds on Instagram, a phone number on WhatsApp, [email protected] on email, @sbuilds on Telegram, and an anonymous visitor ID on your website until she types her name into the chat widget. That is one customer and five identities, and how your CRM feels about that fact determines whether your database is an asset or a mess.

There are two ways to build it.

The bad way: a contact record with text fields on it called instagram_handle, whatsapp_number, telegram_username. It demos beautifully. It fails on contact with reality, because a text field cannot be the thing conversations attach to. Messages have to attach to something, so they attach to the contact by a lookup on that text. Change the text and the link breaks. Have two contacts with the same text and the link is ambiguous.

The right way: a contact that owns many channel identities, where each identity stores a stable platform ID as the key and the human-readable handle as a display attribute that is allowed to change. Messages attach to the identity. The identity attaches to the contact. Now a handle change is a display update, not a data disaster, and merging two contacts is a supported operation rather than a support ticket.

The Telegram username test

Here is a concrete question worth asking in a sales call, because the answer is diagnostic and the salesperson usually has to go and find an engineer, which is itself informative.

"When a Telegram contact changes their username, does your CRM key on the username or the numeric user ID?"

Telegram usernames are mutable. A user can change @sbuilds to @sarahbuilds this afternoon, and someone else can claim @sbuilds tomorrow. The numeric user ID never changes. If a CRM keys conversations on the username, then a handle change produces a duplicate contact, and a handle reuse produces something worse: two different humans' messages stitched into one record. The same logic applies to X and Instagram, where handles are also mutable.

You do not have to take the vendor's word for it. Run test 4 from the channel script: message from a burner, change the burner's handle, message again, then count the contacts. One contact means the model is sound. Two contacts means you now know exactly what your database will look like in eighteen months.

Three more model tests worth twenty minutes each

• The merge test. Create two contacts for the same person, one from Instagram and one from email. Merge them. Then look at what survived. Did both message histories come along, in one timeline, in the right order? Did the deal follow? Did the tags union or did one set win silently? Can you undo it? A CRM that cannot undo a merge is a CRM where merging is a decision nobody on your team will ever be brave enough to make, which means the duplicates stay forever.
• The timeline test. Ask whether the timeline is a real object or a rendering. The test: try to filter it. If you can narrow the timeline to "messages only, this channel, last 30 days" then the events are structured data you can also query and report on. If the filter does not exist, the timeline is a visual concatenation of activity rows, it will get slower as the contact gets more valuable, and it will never appear in a report.
• The pre-contact test. A message arrives at 2am from someone who has never contacted you. What exists at 2:01am? A contact, with the message attached, and enough attribution to know they came from your Instagram bio link? Or nothing until a human opens the app in the morning and clicks something? This is the difference between a CRM and a log viewer, and it is the precondition for every automation you are about to buy.

Custom fields, custom objects, and knowing which one you need

This distinction costs people a lot of money because the words sound similar.

A custom field is a new attribute on a noun the CRM already has: a "shirt size" on a contact, a "renewal risk" on a deal. Every CRM does this. A custom object is a new noun entirely: a Property, a Shipment, a Cohort, a Vehicle, with its own fields and its own relationships to contacts and deals.

Be honest with yourself about which one your business needs, because it is a fork in the road. If you can model your world as contacts, deals, and tasks with extra attributes, a messaging-first CRM will serve you and the data model is a non-issue. If your business genuinely has a second object graph, quotes linked to line items linked to products linked to price books, you need a platform, and this is one of the places where the incumbents earn their money legitimately.

Our position, stated plainly: CRM Solid gives you custom fields, tags, lead scoring, team assignment and a contact timeline, and multiple editable pipelines with channel-to-pipeline routing, so an Instagram lead can land on your Influencer board while a live chat lead lands on Sales. It does not give you arbitrary custom objects. If you need a second object graph, score us low on this row and mean it.

Automation depth: four rungs, and the demo never says which one you are buying

"Automation" on a pricing page covers a range from a text expander to something that answers customers unsupervised at 3am. Those are not the same product and they do not carry the same risk. Sort the ladder before you compare vendors, because a tool that is excellent at rung 2 and honest about it is worth more than a tool that gestures at rung 4 and delivers rung 1.

The category confusion between rungs is the single biggest source of disappointment in AI-era CRM purchases, and it is mostly a vocabulary problem: "AI chatbot" is used for a decision-tree menu and for an autonomous agent in the same paragraph of the same brochure. We wrote a whole piece on what separates a rule-based chatbot from an LLM chatbot from an actual agent because you cannot evaluate what you cannot name.

Rung 3 deserves a warning that most sequence tools do not print. The hard part of a sequence is not sending step two. It is stopping. Ask the specific question: if a prospect replies on WhatsApp, does the Telegram sequence stop? Cross-channel auto-stop is the difference between a sequence tool and an apology generator. Our multi-channel sequences stop on reply across channels, and we say so here because it is the first thing we would check on a competitor.

How to test rung 4, which is not by watching the demo

Gartner predicted in a March 2025 press release that by 2029, agentic AI will autonomously resolve 80% of common customer service issues without human intervention, alongside a 30% reduction in operational costs. Treat that as what it is: an analyst prediction about a market, not a measurement of your inbox. It is a reasonable basis for expecting the category to matter. It is not a reason to believe any particular vendor's agent will work on your business tomorrow.

So test it, and do not test the happy path. Every agent handles "what are your opening hours". Five tests that actually discriminate:

1. Ask something not in the knowledge base. The only two acceptable behaviours are "I do not know, let me get someone" and a handoff. If it invents a plausible answer, you have just watched it lie to a customer, and it will do that at scale.
2. Send an angry message. "This is the third time I have asked and I want a refund." Does it detect the escalation and hand off, or does it cheerfully offer a knowledge base article? Watch what the handoff actually looks like from the customer's side: does the tone change, does the customer get told a human is coming, or does the conversation just go quiet?
3. Send three messages in ten seconds. This is how people actually type in DMs: "hi", "quick question", "do you ship to Spain". A naive agent replies three times, which is instantly recognisable as a bot and makes you look worse than not replying. A well-built one waits, coalesces, and answers once.
4. Send a language you did not configure. Not a hypothetical for anyone selling in more than one country.
5. Correct it and see if the correction sticks. This is the one that matters most over a year. When the agent gets something wrong, can a rep fix it in the flow of work, or does fixing it require an admin, a prompt rewrite, or a support ticket to the vendor? If teaching the agent is a project, nobody will do it, and the agent's quality is frozen at whatever it was on day one.

What we have on rung 4, precisely: AI Agents read incoming DMs and reply in your voice across Telegram, X, email, and the social inbox, with personas, knowledge bases, a rules engine, rate limits, human handoff, per-contact pause, and thumbs up or thumbs down feedback in the chat that teaches the agent. Tests 3 and 5 above are the ones we would want you to run on us, because they are the ones we built for.

And one more piece of honesty in the same area, because it is a thing people misread: WhatsApp Learning reads your exported chat history to learn how your team actually sells, and it never sends anything. It is a read-only analysis tool. It is not a bot, it does not automate replies, and if a demo ever left you with the impression that it does, the demo was wrong.

Three pricing models, three different taxes on your growth

Between 2024 and 2026 the CRM and customer messaging market stopped having one pricing model and started having three. Most buyer guides still compare the numbers. The numbers are the least interesting part. What you are actually choosing is which axis of your own growth the vendor's revenue is attached to, and that choice compounds every month for as long as you stay.

The three models, with dates, because this all happened recently enough that half the advice online predates it:

Per-seat. The vendor's revenue grows when your headcount grows. On 5 March 2024 HubSpot moved every hub and tier to a seats-based model, introducing Core Seats for edit access and View-Only Seats that are free and unlimited on paid portals, and removed seat minimums on Sales Hub and Service Hub, per HubSpot's own announcement. Tax base: people.

Consumption. The vendor's revenue grows when your volume of work grows. On 15 May 2025 Salesforce introduced Flex Credits, where each action an agent performs draws from a credit pool. Meta did the same thing to the channel itself on 1 July 2025 by moving WhatsApp to per-message billing. Tax base: work done.

Outcome. The vendor's revenue grows when their AI succeeds. Zendesk announced outcome-based pricing for AI agents on 28 August 2024, charging only for issues the AI resolves autonomously, on the stated reasoning that "traditional pricing models no longer suffice in an era where customer value can and should be measured by outcomes directly tied to the success they achieve". Intercom prices Fin per outcome and has since broadened what counts as an outcome beyond a full resolution to include configured procedures that end in a handoff. Tax base: automation success.

Why did this happen? Gartner said the quiet part in a press release on 1 July 2026: up to $234 billion of enterprise application software spend is exposed to agentic arbitrage through 2030, roughly 20% of enterprise application SaaS spending by then. Gartner's George Brocklehurst described the mechanism in one sentence: "This breaks the link between user growth and revenue growth for many enterprise software vendors."

Read that as a buyer rather than as a vendor. It says: seats were the mechanism by which a software company's revenue tracked your growth. That mechanism is failing, because agents do the work and agents do not buy seats. So vendors are re-attaching their revenue to a different axis of your growth. Your only job in the pricing conversation is to work out which axis, and whether that axis grows faster or slower than your revenue does.

The rule that falls out of the table: choose the model whose tax base grows slowest relative to your revenue. Write the ratio down. If your revenue doubles next year, what does your headcount do? What does your message volume do? For most messaging-first businesses, message volume grows faster than revenue (because inbound curiosity scales before conversion does) and headcount grows slower than revenue (because that is the entire point of automating replies). That single asymmetry is why consumption pricing is dangerous for a messaging business and per-seat is survivable, which is the opposite of the advice you will read everywhere else.

The honest counterweight, because usage pricing has its own trap

Consumption pricing sounds fairer. It reads worse on a budget, and the data on this is unusually good. Zylo's 2026 SaaS Management Index, built on more than 40 million SaaS licenses and $75 billion in spend under management, reports that 78% of IT leaders saw unexpected charges tied to consumption-based or AI pricing models in the prior twelve months, and 61% were forced to cut projects because of unplanned SaaS cost increases.

That is the trade nobody frames honestly. Per-seat is a worse deal and a better forecast. Consumption is a fairer deal and a worse forecast. If an unplanned invoice would cause a genuine problem in your business, that is a real constraint and you are allowed to pay more for a number you can predict. Just make that choice deliberately rather than discovering it in March.

How per-seat quietly punishes growth: the math to do before you sign

We are not going to put prices in this article, partly because ours are being changed this month and partly because a price in a blog post is wrong within a year. So do it in algebra, which generalises better anyway. Call the per-seat monthly list price S.

You start with four seats. Two closers, one support person, one founder. Your bill is 4S. Eighteen months later, here is a seat history that should look familiar to anyone whose company is doing well. It is a constructed example, not a measurement, and the pattern is the point rather than the specific months:

The bill went from 4S to 11S. That is 2.75x. Did revenue go 2.75x? Possibly, and if it did you should feel fine. But look at the composition of the growth: of the seven seats you added, four sell (three closers and a seasonal contractor) and three exist in order for the other four to sell. Per-seat pricing taxes your coordination overhead at exactly the same rate as it taxes your revenue production. Every organisation's coordination overhead grows faster than its headcount of closers. That is not a CRM problem, it is an organisational fact, and per-seat pricing is uniquely positioned to bill you for it.

The four silent seat expansions, in order of how often they surprise people

1. Read access. The moment someone outside the team needs to look at the pipeline without editing it, you are in a seat conversation. This is why HubSpot's free, unlimited View-Only Seat is a genuine feature and not a marketing line: it removes the most common accidental seat from the meter. Ask every vendor the flat question, "what does read-only cost", and if the answer is "a seat", go back to your org chart and count the viewers before you compare prices.
2. Non-human seats. Some tools bill a seat for the account that owns an automation, an integration, or a connected inbox. Ask directly: does an API integration consume a seat? Does a shared inbox? Does an AI agent?
3. The seat floor. You need three extra people for Q4. Can you remove them in January? Most annual contracts ratchet upward and never downward, which means a seasonal peak becomes a permanent price. Ask for the answer in writing, in the contract, not in the sales call.
4. The per-account meter. Some tools bill per connected channel account: per Instagram profile, per WhatsApp number, per Telegram account. If you are an agency running forty client accounts, the seat was never the real meter and the per-seat price on the pricing page is fiction. Find the meter that scales with your shape.

There is a fifth thing, and it is the actual failure mode of per-seat pricing. It is not that seats are expensive. It is that nobody ever cancels one. The same Zylo index found that organisations leave an average of 36% of their SaaS licenses unused. A third of your seat spend is likely to be for people who stopped logging in, and per-seat pricing has no mechanism that tells you. Consumption pricing at least has the decency to go to zero when nobody uses it.

When per-seat is the right answer, which is more often than the internet admits

Per-seat is the cheapest model in the world for a team with small headcount and large message volume. Three people handling 8,000 conversations a month pay 3S under per-seat. Under consumption pricing, they pay for 8,000 units of something. Under outcome pricing, the better their AI gets, the more they pay.

Run your own ratio: conversations per head per month. If that number is high and rising, per-seat is functionally a flat rate and you should stop reading anti-seat content, including this section. If that number is low, because you have a large team having a small number of high-value conversations, per-seat is a tax on your entire org chart and consumption pricing will save you real money.

Where does this leave us? CRM Solid is plan-based: Free, Pro, Business. The free plan is a real free plan, not a trial with an expiry date attached. We are deliberately not quoting numbers in an article that will still be online in three years, and that is worth generalising into advice: screenshot the vendor's pricing page on the day you sign, and put the screenshot in the folder with the contract. Pricing pages change. Signed terms do not, and the gap between them is a conversation you will be glad you can win. Current numbers, whenever you are reading this, are on the pricing page.

Migration cost is real, it is not on the quote, and one line item is unique to messaging

Every CRM quote implies that migration is a weekend. Here is the actual shape of it. These are reasoned estimates for a team of five with a couple of years of history, not measured averages, and they are labelled as such because we have no dataset to cite and neither does anyone else quoting you a number.

Two of those rows deserve more than a table cell.

Verification is not row counts. Matching totals is the check that always passes and never catches anything. The check that works: pick 30 records at random, and for each one, open it in the old system and the new system side by side and read them. Look specifically at the least glamorous fields, because that is where import defaults hide: the created date collapsed to the migration date, the owner defaulted to whichever admin ran the import, the notes concatenated into one blob. Each of those passes a row count. Each of those is silent. And each of those poisons your reporting for the life of the database, because every cohort analysis you ever run will believe your entire customer base arrived on a Tuesday in March.

The line item that only exists in messaging

Email migrates. It is a file format with a specification. An .eml is an .eml in 2005 and in 2026, and you can move a decade of it between systems and it means the same thing on the other side.

Message history does not work like that, and this is the single most under-priced fact in messaging CRM buying.

Your Instagram DM history does not live in your old CRM as portable truth. It lives at Meta. Your old CRM had a copy, obtained through a token bound to that CRM's app registration. When you leave, you can usually export the copy as rows in a file. What you cannot export is thread continuity. The new CRM will connect, authenticate as a different app, and pull whatever backfill the platform allows, which is often a limited window rather than everything. Anything older than that window is an archive, not a live thread.

So plan for the seam, because there is going to be one. Your options, honestly, are three:

• Migrate history as read-only rows and let live threads start fresh in the new tool. Most teams pick this and are still surprised by it, because "we have the history" and "the history is in the conversation" turn out to be different sentences.
• Keep the old tool alive in a read-only or minimum tier for a year as an archive, and accept paying a small amount for a filing cabinet.
• Accept the loss. Legitimate more often than people admit. Ask yourself when you last read a DM thread from two years ago.

There is no fourth option in which the seam does not exist. If a vendor tells you they will migrate your messaging history with full continuity, ask them which API call does that, on which platform. The answer will be interesting.

Attachments deserve a specific question of their own, because they are stored separately from message rows in essentially every system, and they are therefore exported separately, if at all. It is entirely normal to get an export containing every message you ever sent and none of the images. Ask for a sample export with attachments included, during the trial, before you sign. Which brings us to the section that most buyers skip.

Lock-in and export: what the law gives you, and what it very much does not

There is more law here than there was two years ago, and it is worth knowing precisely, because the precision is where the useful part lives.

The EU Data Act (Regulation (EU) 2023/2854) entered into force on 11 January 2024, and its rules have applied since 12 September 2025. Chapter VI governs switching between data processing services and it is unusually concrete for EU regulation:

• Article 23 requires providers to remove pre-commercial, commercial, technical, contractual and organisational obstacles to you terminating the contract, contracting with a new provider, porting your exportable data and digital assets, and achieving functional equivalence on the new provider's service.
• Article 25 sets contract terms: a maximum notice period to start a switch of no more than two months, a mandatory transitional period of 30 calendar days that the customer can extend once, an alternative of up to seven months where 30 days is technically unfeasible (with the provider owing a justification within 14 working days), and a minimum data retrieval window of at least 30 calendar days after the transitional period ends.
• Article 29 phases out switching charges. Between 11 January 2024 and 12 January 2027, providers may impose only reduced switching charges that do not exceed the costs directly linked to the switch. From 12 January 2027, switching charges are prohibited outright.

And it reaches further than people expect: the obligations attach to providers serving customers in the EU regardless of where the provider is established, so a US vendor with EU customers is inside the scope.

Now the uncomfortable parts

First: whether it covers your CRM is a service-by-service question, not a settled one. "Data processing service" is defined around cloud computing hallmarks: on-demand network access to a shared pool of configurable, scalable and elastic computing resources. Law firms reading Chapter VI when it landed generally put commercial CRM platforms inside the definition, and Cooley names CRM platforms explicitly as services that typically qualify, while carving out anything custom-built for a single customer. Others describe the edges as a grey zone needing assessment per service. Translation for a buyer: probably yes, arguably, and you would rather not find out in court.

Second, and this is the one nearly every buyer guide gets wrong: GDPR Article 20 is not your escape hatch. The right to data portability belongs to the data subject, the human whose personal data it is. As the Irish Data Protection Commission sets out, it lets Sarah receive her own personal data in a structured, commonly used, machine-readable format and have it sent onward. It does not give your company any right at all to extract your CRM database from your vendor. Your company is not the data subject. Your leverage under GDPR in a vendor exit runs through your Article 28 processor terms, which you either negotiated or accepted at signing, probably without reading.

Third: if you are not in the EU, none of Chapter VI is yours. The contract is all you have.

So treat the law as a floor that may or may not be under you, and put your actual export rights in the contract:

• Format, named. "CSV and JSON" is a clause. "Industry-standard formats" is not a clause, it is a mood.
• Scope, itemised. Contacts, custom fields, message bodies, attachments, notes, deals, pipeline history, users, automation configuration, audit log. List them. Anything unlisted is not included, and you will discover which ones at the worst moment.
• Self-service, not ticket-service. "Available via the API and the UI without contacting support" is worth more than any SLA on an export request.
• A retention window in days after termination, before deletion.
• Zero switching charge, written as zero, regardless of what Article 29 does or does not require of that vendor.
• Rate limits that make the export physically possible inside the retention window. This is the sneaky one, and it is arithmetic. A 30-day retention window plus an API that returns 10,000 records a day is a 300,000-record export right. If you have a million records, you do not have an export right. You have a countdown. Do the division before you sign, not after you give notice.

Run the export in week one of the trial, not in week one of the divorce. Import 200 contacts, generate 50 messages with attachments, then export everything and open the file. That hour is the highest-information hour in a CRM evaluation and almost nobody spends it, because it feels like preparing for a breakup during the honeymoon. That is exactly what it is, and it is exactly why it works.

Our answer to this, so you can hold us to it: there is a public REST API and an MCP server, both documented on the API page, and the export test is one you should run against us in week one. If we fail it, do not buy from us.

A scoring rubric you can copy

Copy this into a sheet. The weights below are calibrated for a team whose customers mostly message. If that is not you, change them, and the instructions for changing them are at the end of this section.

Score each category 1 to 5. Anchors matter more than the scale, because undefined anchors are how two people on the same team score the same product four points apart. Here are the anchors for the heaviest category, and you should write equivalents for the other five before you start:

Now the worked example, with three plausible finalists. Multiply score by weight, sum, divide by 500.

Notice what happened. Incumbent A won two of six categories outright, tied two more, and has by far the most features, the best data model, and the best everything-else. It lost by 16 points, because it cannot see your customers. That is not a quirk of the weights, it is the whole thesis of this article expressed as arithmetic: for a business whose front door is a DM, a CRM that cannot hold a DM is not a worse CRM, it is a CRM for someone else.

Three veto rules that override the total

1. Channel coverage scores 1 or 2: eliminated. No total saves it. You would be buying a tool and a data entry job.
2. Exit scores 1: eliminated. A product you cannot leave is not a purchase, it is a position.
3. Any score sourced from a vendor's answer rather than your own test: reset it to zero and go test it. This is the rule that does the work. Most completed rubrics are transcriptions of a sales call with numbers on top, which converts a salesperson's confidence into your spreadsheet's authority. If you did not watch it happen on your screen, you do not know it.

How to re-weight it for your situation

The weights encode assumptions. Change them when the assumptions do not hold.

• Agency running many client accounts: add a "multi-account and permissions" category at 15 and take it out of "everything else" and "automation". The per-account meter question from the pricing section becomes your central pricing issue.
• Regulated industry: "everything else" becomes "compliance and certification" at 25. We have no SOC 2 report and no HIPAA certification, so score CRM Solid a 1 there and move on quickly. That is not modesty, it is arithmetic: at weight 25, a 1 costs us 100 points and we cannot win. Save yourself the month.
• Mostly outbound rather than inbound: automation depth goes to 25 and channel coverage down to 20, because your constraint is sequencing and deliverability rather than reception.
• You expect to be acquired: exit goes to 20. Data portability during due diligence is a genuine deal variable and nobody thinks about it until a lawyer asks.

Nine questions vendors do not enjoy, and what a good answer sounds like

These are ordered by how much information they produce per second of discomfort.

1. "Which features on this page shipped in the last 90 days, and which are on the roadmap?"
Bad answer: "Everything you see is available today." Good answer: an actual list with dates, including the things that are not ready. Every vendor's website is ahead of every vendor's product, including ours. You are not testing whether the gap exists. You are testing whether they will tell you about it unprompted, which is the best available proxy for what support will feel like in month six.

2. "Can you email me a sample export today, from a real account, with attachments included?"
Bad answer: "That is a professional services engagement." Or "let me check with the team", followed by silence. Good answer: a file in your inbox within the hour. The reason this question works is that it cannot be answered with words.

3. "What is your API write rate limit, and how long would importing 500,000 records take?"
Bad answer: anything qualitative. Good answer: a number, and then them doing the division in front of you. A vendor who has never been asked this has never had a customer migrate in at scale.

4. "Who provides your WhatsApp and Instagram connection, and what happens to me when they change their terms or their pricing?"
This question has a built-in fact check, which is why it is the best one on the list. Meta changed WhatsApp to per-message pricing on 1 July 2025. Ask what they did that week. A vendor with a real integration has a story: what broke, what they shipped, what they emailed customers. A vendor with a logo has a pause.

5. "Show me the AI handing off badly."
Bad answer: another happy-path demo. Good answer: they show you the confidence threshold, where it is configured, what triggers a handoff, and a real conversation where it fired. Anyone can demo an agent answering a question it knows. The product is what happens on the question it does not know.

6. "What does a read-only user cost, and can I remove seats mid-term?"
Bad answer: "Let's talk about your growth plans." Good answer: a number and a contract clause. If they will not put seat removal in writing, the seat floor is the real price and the sticker is marketing.

7. "If I stop paying tomorrow, what happens to my message history and for how long?"
Bad answer: "You would never want to do that." Good answer: a retention period in days and a documented process you can read now.

8. "Can I speak to a customer who left you?"
Nobody says yes. Ask anyway and watch the recovery. A vendor who says "no, but here is honestly why people leave: they outgrow our reporting, or they need phone" has a functioning memory of their own losses. A vendor who says "nobody really leaves" is either lying or has never run the query, and both are disqualifying in different ways.

9. "What are you bad at?"
This is the entire interview compressed into four words. If the answer is a humblebrag ("we are almost too flexible", "we ship too fast"), you have learned exactly how they will handle your first escalation. If the answer is a specific, boring, verifiable weakness, you have found someone who will tell you the truth when it costs them something.

Where we would squirm

Fair is fair. Ask us question 9 and this is the answer, so you can save the call:

• No phone channel and no SMS channel. If either is in your tally, we are not the answer.
• No SOC 2 report and no HIPAA certification. If your procurement questionnaire has either line, we fail it at the questionnaire. Do not spend a month discovering that. We document what we actually do on security, and it is not the same thing as a certification, and we are not going to pretend it is.
• Our email inbox is narrower than our social inbox. It connects to Gmail, Outlook, iCloud or any IMAP account, syncs, reads, composes, replies, links threads to contacts, and does per-thread status. It does not yet do AI drafting, assignment, or CRM labels. If AI on email specifically is your requirement, the honest question to ask us is when, not whether.
• No arbitrary custom objects. Custom fields, tags, and multiple pipelines, yes. A second object graph, no.
• No native Shopify integration. There is an API and an external revenue import, which is not the same as a one-click connector, and calling it one would be the kind of thing this article is against.
• We are a small vendor. Ask us the viability question directly. We would rather answer it than have you assume, and if vendor size is weighted heavily in your rubric it is a legitimate reason to buy someone else.

When a spreadsheet is genuinely still the right answer

Sometimes the correct output of a CRM evaluation is "not yet". Here is how to know, stated as conditions rather than vibes.

A spreadsheet plus the native app inboxes is genuinely the right tool when all three of these hold:

1. One person owns every conversation. Not "mostly one person". One. The moment it is two, the tool you actually need is a shared queue, and a spreadsheet is not one.
2. Fewer than roughly 30 open conversations at a time. You can hold thirty in your head, and the unread badge in the native app is a working queue.
3. Dropping one costs you very little. Low deal value, or plentiful replacement leads.

If all three hold, the sheet wins on total cost, and it beats our free plan too, which we are aware is an odd thing for us to write. The reason is not price, since our free plan is free. The reason is that a CRM's real cost is the daily tax of having two places to look. If the message is in Instagram and the record is in a CRM, and you have thirty conversations, you will check Instagram first and the CRM second, and a CRM you check second is worse than no CRM at all, because now your data is wrong instead of absent.

The four tripwires

Any one of these firing means the calculation has flipped. Not all four. One.

1. Two people have to ask each other "did you already reply to her?" more than once a week. Your coordination cost has exceeded your tool. This is the earliest signal and the most ignored.
2. You lost a deal you can name because a message sat unread. Once is bad luck. Twice is a system, and the system is the spreadsheet.
3. You need an answer that spans conversations. How many people asked about the price change? What was our median time to first reply last month? Which channel produces customers rather than tyre-kickers? A sheet can answer questions about rows you remembered to type. It cannot answer questions about the messages, because the messages are not in it.
4. Someone leaves and the DMs leave with them. This is the tripwire that ends the debate, and it is worth being blunt: if your customer conversations live in an employee's personal Instagram or WhatsApp account, they are not your asset. They are that person's asset, and you are one resignation away from finding out what that means. No spreadsheet fixes this, because the spreadsheet was never where the conversation was.

The deeper reason to move before the tripwires fire is that a spreadsheet's failure mode is silent. Nothing turns red. No alert fires. The tool does not tell you it dropped a lead, because the tool does not know a lead exists. You simply make somewhat less money than you would have, forever, and you never find out how much. Contrast that with the failure mode of a bad CRM, which is loud and annoying and therefore fixable.

One middle option that people skip on their way to buying software: the native business tools. Instagram and WhatsApp both ship business inboxes with labels and saved replies. They are worse than a CRM at everything except two things, and the two things are enormous: they are free, and they are already where the message is. If you are genuinely at the margin, spend another quarter there and let the tripwires decide for you. That is better advice than "buy a CRM", and it is worth more to us that you take it at the right time than that you take it today.

When you should buy the big incumbent instead of us

Any two of these, and you should be running a Salesforce or HubSpot process, not this one.

1. Procurement requires SOC 2 Type II. We do not have one. This is not a philosophical position about compliance theatre, it is a fact about us in 2026. If that line is in the questionnaire, we lose at the questionnaire.
2. You are regulated in a way that needs HIPAA. Same answer, faster.
3. Phone is a real column in your tally. We have no phone or SMS channel, and a CRM that cannot see your main channel is the exact mistake this article was written to prevent. It would be strange to make it in our favour.
4. Your customers email and only email. If the tally came back 85% inbound email and web form, then every argument in this article is an argument for the incumbents. Email is what they were built around and they have had twenty years to get good at it. Start at the HubSpot comparison, and read it as a document written by an interested party, which it is.
5. You need an implementation ecosystem. At 200 seats with a dedicated admin, your binding constraint is not product quality, it is whether a market of consultants exists who have solved your exact problem forty times before. That market exists for Salesforce. It does not exist for us and will not for years. The Salesforce comparison is honest about this.
6. You need a second object graph. Quotes linked to line items linked to products linked to price books. Territories. Account hierarchies. Field-level permissions across 300 fields. That is a platform, and platforms are what the incumbents sell, legitimately, at platform prices.
7. Your CFO needs the vendor to exist in 2036. A legitimate requirement, and a big vendor is a genuinely safer bet on that specific axis. Just weight it correctly: it belongs in "everything else" at 10%, not at 50%, unless you are signing a five-year contract. And if you are signing a five-year contract for a CRM in 2026, given that the entire pricing model of this category changed twice in the last twenty-four months, that is the decision to reconsider, not the vendor.

The inverse, so this is not false modesty dressed as a sales technique. Buy the messaging-first tool when your channel tally is majority DM, you are between two and twenty people, the thing you need automated is replying rather than reporting, and you would rather have a working Instagram inbox today than a perfect quote object next year. Those four together describe a real company, and for that company the incumbents are an expensive way to do data entry.

A 30-day evaluation that produces a decision instead of a feeling

Days 1 to 2: the tally. Fifty first contacts, by channel, plus the twelve-month column. Nothing else happens until this exists, because without it every demo is a Rorschach test.

Days 3 to 4: the rubric, weights first. Write the weights and the score anchors before you see a demo. This is the single highest-leverage trick in the whole process and it costs an hour. Weights written after demos are not weights, they are rationalisations of a preference you already formed, and you will not be able to tell the difference from the inside.

Days 5 to 7: cut to three, on public information only. Do not take a demo from a tool that cannot see your top channel. You are not being rude. You are declining to spend forty-five minutes being shown features that are irrelevant to whether the product can do the job.

Week 2: parallel trials, same script. Run the identical test script against all three, in the same afternoon if you can, because comparison is only valid when your standards have not drifted. The script, assembled from the tests above:

• Connect your top channel yourself. Time it. If you cannot connect it without a sales engineer, note that, because that is also how the second one will go.
• DM from a burner account. Check that a contact appears with the body, and how fast.
• Reply from the CRM. Verify in the native app that it landed in the real thread from your real account.
• Send an image and a voice note.
• Change the burner's handle. DM again. Count the contacts.
• Merge two contacts. Look at what survived. Try to undo it.
• Build one rule and watch it fire.
• Ask the AI something not in its knowledge base, then something angry.
• Export everything. Open the file. Look for the attachments.

Week 3: one real channel, in production, on the leader. Not a sandbox. Real customers, one channel, one week, with a written rollback plan and someone who owns it. A sandbox tells you the product works. A week of production tells you whether your team will use it, which is the thing you are actually buying and the thing that decides whether this is remembered as a success. Our unified inbox setup guide is roughly this week, written down.

Week 4: score, then read the contract. Fill the rubric from your tests, apply the veto rules, and then read the terms with the export section from earlier in front of you. Then negotiate the export clause rather than the price.

That last sentence is the most useful thing in this section. Vendors will trade export language for a longer term far more readily than they will trade price, because a discount costs them money this quarter and an export clause costs them nothing until the day you leave, which every salesperson is confident will never come. Take the trade. It is close to free, and it is the only clause that matters on the day it matters.

Questions buyers actually ask

What is the most common CRM buying mistake?

Evaluating features before evaluating channel coverage. Feature lists are comparable, so buyers compare them, and channel depth is hard to see, so buyers assume it. Then the tool goes live and 60% of conversations still happen somewhere it cannot reach, so the team keeps working in the native apps and the CRM slowly becomes a place where someone types summaries. Count your last 50 first contacts before your first demo.

Should I choose a CRM based on features or channel coverage?

Channel coverage, and it is not close for messaging-first teams. Nearly everything else about a CRM can be changed after purchase: fields, stages, rules, reports, even the pricing tier. What the tool can see cannot be changed by any amount of configuration. If it cannot hold an Instagram thread on day one, it never will, and the fix is buying a different product.

Is per-seat or flat pricing better for a small team?

It depends on one ratio: conversations per head per month. High ratio, meaning few people handling lots of messages, and per-seat behaves like a flat rate and is your cheapest option. Low ratio, meaning a big team having a few valuable conversations, and per-seat taxes your whole org chart. Also count the people who only need to look, since read-only access is where seat counts quietly double.

How long does a CRM migration really take?

The data move is days. The project is weeks, and the two big line items are never on the quote: retraining humans, and the dual-run period where you pay for both tools and do everything twice. For messaging teams there is a third: message history from platforms like Instagram cannot be migrated with full thread continuity, only as an archive, so plan for the seam rather than hoping a vendor removes it.

Does GDPR guarantee I can export my CRM data?

No, and this is widely misunderstood. GDPR Article 20 portability is a right belonging to the data subject, the individual, not to your company as a customer of the vendor. The EU Data Act's Chapter VI switching rules, applicable since 12 September 2025, are the ones aimed at business customers, and even those depend on your vendor qualifying as a data processing service and on you being in the EU. Put the export terms in the contract.

Do I need a CRM if I only sell through WhatsApp and Instagram?

Not automatically. If one person handles everything, under about 30 open threads, and losing one costs little, the native business inbox plus a spreadsheet is genuinely cheaper. Move when any tripwire fires: two people duplicating replies, a named lost deal, a question you cannot answer across conversations, or conversation history living in someone's personal account.

The next step is not a demo

It is the tally. Fifty first contacts, by channel, thirty minutes, before anyone shows you anything. That single sheet will either point at the incumbents, at a spreadsheet for another quarter, or at a messaging-first tool, and it will do it more honestly than any comparison page including ours.

If it points at messaging, run the week-two script against us on the free plan. Connect one channel, DM yourself from a burner, change the handle, and export the file. Twenty minutes, no card, no call. If we fail a test, you will have learned something real, which is more than most evaluations produce in a month. Start at pricing to see what is in each plan.