What should a CRM consultant’s job mean once AI is involved?
Wiring a CRM up to an assistant is close to free now. Several of the big CRMs now ship their own plain-English access on the tier you’re already paying for, and where they do, turning it on is an afternoon of admin work, not a project. So if that’s genuinely all a consultant is offering you, connecting the tool, you don’t need to hire anyone. Use what’s already there and keep the fee.
In one audit we ran for a home-services company, roughly 29 percent of their inbound calls could be tied to a completed job. Every figure built on top of that data inherited the same 29 percent ceiling, with nobody downstream knowing to discount it. Finding that ceiling before it reaches a client’s decision, not after, is what the job is actually for.
The job actually worth paying for is different, and it starts after that connection exists, not instead of it. A CRM consultant’s real work, once AI is involved, is checking whether the data behind the connection can answer the questions your business actually has, naming precisely what’s missing, and stating how much of the business any given answer can actually see. If a consultant’s process skips straight to connecting the tool without doing that checking first, that’s usually a sign the checking step got skipped entirely, and you paid a fee for wiring you could have done yourself in an afternoon.
That’s a smaller and more concrete thing than it sounds. “Precisely what’s missing” means naming the actual field, not gesturing at “better data.” “How much of the business any given answer can actually see” means a real share, stated next to the answer, not folded into the pitch as a vague caveat about accuracy. A consultant who can’t produce either of those two things on request hasn’t done the checking yet, no matter how confidently the quote reads.
That distinction is also why the fee makes sense once it exists and doesn’t otherwise. Connecting a tool is a known quantity: the work is bounded, the outcome is predictable, and a business owner with an afternoon free can usually do it without help. Checking whether the underlying data can actually answer real questions is not bounded in the same way, because nobody knows what they’ll find until they look, and that uncertainty is exactly what a client is paying someone experienced to absorb.
What does your CRM already give you for free?
Before recommending anything paid, a real check starts with what the vendor already ships, because that’s the fastest way to save you money rather than spend it. Business software has increasingly stopped charging for plain-English access to its own data. Several of the systems small businesses actually run now include it rather than charging for it, and turning it on is usually admin work rather than a project. For the full map of which business tools ship this today and which don’t, and which are gated behind a plan tier, we built that separately: MCP servers for business tools.
If every question you want to ask lives inside one such system, the honest recommendation is to use what’s already free and stop there. That’s step one of the actual process, said out loud before any paid step, not a caveat tacked onto the end of a pitch.
Whether that applies to you specifically depends on the plan you’re actually paying for, not the plan on the vendor’s homepage. Plain-English access has been rolling out unevenly: of the systems we’ve connected in 2026, some shipped it on every tier, others gated it behind whichever plan sits one level above what most small businesses buy. The five-minute check worth doing before any conversation with a consultant is confirming which side of that line your account sits on, because a consultant who recommends a paid build without checking first has skipped a step that would have cost you nothing to check yourself.
What can’t a single connector reach?
A native connector, the one your CRM vendor already ships, answers from inside its own tool, and that’s a real limit, not a knock on the vendor that built it. It has no visibility into a second or third system it was never introduced to, and if it was built for single-record lookups, it doesn’t become a search engine across your whole dataset just because someone connected it to an assistant. What we mean by “grounded” is simple: an assistant that answers only from your actual records, not one that fills a gap it can’t see with a plausible-sounding guess. We’ve written about that distinction on its own: AI that answers from your own data, explained.
A Medicare brokerage’s own CRM connector could look up a single client’s note but could not search across the 32,279 notes they had accumulated, a fundamentally different kind of task. For the structural version of where a connector’s reach ends, see where a vendor’s own connector stops.
This isn’t a reason to avoid native connectors, most businesses should use them for everything they can reach. It’s a reason to know exactly where the edge is before promising a client, or yourself, that a connected assistant can do something it structurally can’t.
The pattern behind that limit is structural, not a vendor oversight. A connector built to answer “show me this client’s record” was designed around a single lookup, and a single lookup doesn’t turn into a search across every record just because an assistant is now asking the questions instead of a person clicking through a screen. Knowing which shape your connector was built for, one record at a time or the whole dataset at once, tells you in advance whether it can do what you’re about to ask of it.
How do you check what’s actually there, field by field?
This is the diagnostic itself, and it’s the part that gets skipped most often. A competent check doesn’t assume your data matches your own mental model of how the business runs. It pulls real records and looks. Three steps, done in order, and each one produces something you could hand to a client before the next step starts.
First, the questions get collected exactly as the business would ask them, in their own words, not translated into technical language yet. This step produces a numbered list, twenty questions is a workable size, each one written the way a person would actually type it rather than the way a data model would phrase it. Skipping straight to technical language here is how a check ends up answering a question nobody asked.
Second, each question gets checked against the data that genuinely exists, not the data the business assumes exists. This is where somebody opens the actual system and pulls actual records, rather than reasoning from a schema diagram or a sales page. This step produces the sort: answerable now, needs one specific named addition, cannot be answered by anyone, or is actually asking for a prediction, not an answer. That sorting isn’t a sales phrase, it’s the actual output of the work, and it’s the point where a field like a free-text job-title field gets flagged. On one home-services account, that one field held 10,085 distinct values across 10,544 jobs, and no model groups that into categories mechanically. Someone has to look at it by hand.
Third, every gap found in step two gets classified by kind, not just flagged as a problem. A field that returns nothing at all is a different problem than a field that’s merely empty. One means the concept was never captured anywhere in the system, and the other means it was captured, just inconsistently, by whoever happened to be filling it in that day. On the same account, the field meant to record who handled a call was the second kind: it existed, and it was empty on every one of the 2,432 calls we examined that month. This step produces a short note against every gap naming which of the two it is, because they get fixed in completely different ways, and confusing them wastes a build cycle later.
We’ve seen consultants skip straight past all three steps, because none of them look like impressive work. No dashboard, no demo, just someone reading through real records for a day or two and writing down what they find. It’s also the cheapest part of the whole engagement, and the part that determines whether everything after it is worth doing.
What did a real check look like?
We ran exactly this process against a real account: a home-services company running three brands sent us twenty numbered questions plus a standing instruction, twenty-one items in all, about how their marketing connected to completed work. Eight were answerable now, six needed one specific named addition each, four couldn’t be answered by anyone, including a call-handler field that returned empty on every record it touched, and three were not data questions at all: two forecasts wearing the grammar of a question, plus the standing instruction itself.
One of the six needing an addition was revenue per technician, which couldn’t be calculated until the technician assigned to a job was recorded at all, not just entered inconsistently. One of the four unanswerable items asked who had handled a given call, and the call-handler field came back empty on every one of the 2,432 calls we examined that month, not sometimes, all of them. One of the two forecasts asked what the business should spend on ads next quarter, a recommendation phrased as a question, which no amount of data readiness answers, because it was never a question about existing data to begin with.
The full breakdown lives in the AI readiness checklist.
What coverage number should go with every answer?
A consultant who hands over a number without stating what share of the business it covers has skipped the part of the job that matters most. A number that looks authoritative and rests on a third of the picture is worse than no number at all, because it gets treated with the same confidence as one built on the full set, and nobody downstream knows to discount it.
That coverage number has to travel with the answer everywhere the answer goes, not just live in the report where it was first calculated. An answer gets copied into a slide, repeated in a meeting, forwarded in an email, and each time it moves, the coverage caveat that made it honest the first time is exactly the part most likely to fall off. A consultant’s job doesn’t end at calculating the number once. It includes making sure the number can’t circulate without the context that makes it trustworthy.
What are the red flags in a CRM consultant’s process?
All four trace back to one test, and it’s the only one worth memorizing: ask what share of the business the answer will cover. If they cannot give you a number, they have not opened your data.
- Skipping the check entirely. The first thing you receive is a quote for connecting your CRM, and nobody has pulled your actual records yet.
- Quoting a build before knowing coverage. A price for the project exists before a number for what the finished system will actually see.
- Presenting an answer with no coverage figure attached. A dashboard, a report, an assistant’s answer, any of them can look complete while resting on a fraction of the real data.
- Treating a missing field and a missing concept as the same problem. One is a data-entry habit to fix; the other is a structural gap that needs a place built for it before anyone can start filling it in. Lump them together and the wrong fix gets built for the wrong problem.
They travel together. A consultant who skips the check is also the one most likely to quote early, present without coverage. They also blur the difference between a blank field and a missing concept, because all four come from the same shortcut: treating the diagnosis as a formality instead of the job.
What you are actually paying for:
| If the job is | You are paying for | What you get |
|---|---|---|
| Connect the tool | Flipping on a setting your vendor already built | Access to whatever the vendor’s connector already reaches |
| Check whether the data can answer | Real records checked against real questions | A sorted list of what’s answerable now, what needs one addition, and what nobody can answer yet |
The first is included in what you already pay for. The second is the job worth hiring a consultant to do.
When should you hire a CRM consultant, and when not?
If every question lives inside one clean system with a vendor connector, the check will likely tell you so, and that’s where this stops. If your questions cross two or more systems, or a metric gets defined two different ways by two people who each think they’re right, that’s when the actual job, the check, not the connection, earns its price.
Either decision is fine, as long as it gets made with a coverage number in hand rather than before one exists. What’s not fine is signing a build contract on the strength of a demo alone. A demo built around a native connector was always going to work, connectors demo well regardless of what sits underneath them, and the answer to whether your actual data supports the answer is the part a demo never shows you.
If you want to find out which camp you’re in before talking to anyone, the checklist here takes about ten minutes and covers the same ground from the other direction. Either way, the check itself runs as an Answer Audit: real questions checked against real data, from $1,900, and you keep the document whether or not any build follows it.