When is the free connector already the complete answer?
If every question you have lives inside one tool, the connector your software already ships is the complete answer, and you should stop reading and keep your money. GoHighLevel (a CRM platform many agencies and local businesses run on) ships its official connector on Unlimited ($297/mo) and SaaS Pro ($497/mo), with zero API access on Starter ($97) (vendor pricing, verified August 2026), while Trello’s official connector carries no paid gate on API access at all. We mapped all of it, tool by tool, in MCP servers for business tools. This is about the businesses it is not the answer for.
Plain-English access to your own data is now shipped as standard rather than built custom. That is the real shift. What has not shifted is that it is priced by plan tier, and several of the systems in our own map lock it on a tier above the one most small businesses are actually on.
That connector is genuinely good at single-tool, single-record questions: this contact’s history, the status of one deal, a summary of one note. It costs nothing beyond the plan you’re already on, once that plan includes it, and an admin can turn it on the same afternoon. For a business whose questions never leave the one system they live in, that is the complete answer. Where it runs out is not a quality problem with the vendor’s engineering. It’s a structural boundary, and it shows up in three places.
Can a native connector join two systems?
Yes, in the narrow sense: you can point an assistant at two different tools’ connectors at the same time, and it will use both. What you cannot give it is the rule for deciding that the contact in one system is the same person as the contact in the other: no shared customer key, no reconciliation rule, no statement of which system wins when they disagree. Ad spend on one platform and jobs booked on another, or leads captured in a form tool and work completed and invoiced somewhere else entirely, look to an assistant like two separate lists that happen to overlap, not two views of the same customer.
So it joins them on a guess, usually matching by name or email where it can, and it never tells you that is what happened. Ask a question that quietly requires two systems to agree on the same customer or the same job, and the connector answers with full confidence from whatever partial match it assembled. That is the tell to watch for in every wall below: the connector has no vocabulary for “I am out of my depth,” so it never says so. It just answers.
Can a native connector search across everything you’ve got?
A connector built for single-record lookup doesn’t turn into a search engine over your entire dataset just because someone wired an assistant to it, and this gap is easy to miss because it looks like the connector should already handle it. Lookup and search are different capabilities, and most native connectors only ship the first one.
We saw this directly with a Medicare brokerage that wanted plain-English search across their client notes. Their CRM’s own connector sits on one of the paid tiers that carries API access at all, $297/mo and up, and it was good at exactly what it was built for: pull up one contact, read one note, summarize one record. It could not search across the 32,279 notes the brokerage had accumulated, because nothing in a single-record lookup tool does that without a retrieval layer built specifically underneath it for that purpose. A retrieval layer is an index that reads all 32,279 notes and finds the relevant ones, a different piece of software from the one that opens a single note. The gap isn’t a bug anyone forgot to fix. It’s a different kind of software entirely, sitting on top of data the connector already has permission to read but no mechanism to search at scale.
Ask it to search anyway and it doesn’t say “that’s beyond what I can reach.” It answers from the one record it did find, with the same confidence it would use if that record were the whole dataset, because a native connector has no way to tell the difference between the whole answer and the only piece it could get to.
Does a native connector know your definitions?
This wall never produces an error message, because it isn’t two systems disagreeing. It’s one tool holding two different definitions of the same word inside itself, baked in by engineering decisions the business owner never made. Each definition was set years apart by the tool’s own engineering team, without the business ever being asked to pick one.
Revenue at the point of booking versus revenue at the point of invoicing, inside the same platform, is the common version of this. Plenty of CRMs and field-service tools ship a booking dashboard and a separate invoicing report, built by different engineering teams at different points in the product’s history, and neither report tells you the other one exists. On one account we audited, close to a third of completed jobs were not invoiced at close. Point a connector at the booking view and ask for last month’s revenue, and it hands you a number that is completely faithful to that report’s internal definition of revenue, with no way of knowing a different, equally correct number sits in the invoicing report one screen away.
The connector isn’t wrong, and it isn’t confused. It simply never learned that a second definition exists anywhere in the tool it lives in, so the number comes back sounding like the only one there could possibly be.
How do you know which side of these walls you’re on?
Three questions, and they take about ten minutes to run honestly; for the fuller version this compresses, see the AI readiness assessment checklist.
- Does every question you actually want to ask live inside one tool?
- Does answering any of them require joining two systems that were never introduced to each other?
- Would two different people in your business, asked to define your key metrics off the top of their head, give you the same answer?
A pass on the first question looks like this: your CRM’s own dashboard already shows ad spend, job status, and invoice total on the same screen, without you exporting anything anywhere. A fail looks like opening a second tab before you can answer a question you thought was simple.
If the first answer is yes and the other two are no, the free connector your software already ships is the complete answer for you, and nothing further is worth buying. Stop here and use what you have. If either of the other two comes back yes, that’s specifically the gap a build closes, and it’s worth finding out exactly which of your questions fall on which side before anyone writes a check for anything.
What do we check before recommending anything beyond the free connector?
Before we’d ever recommend paying for more than the free connector, we check every real question against what the underlying data can actually answer, not what it should be able to answer in theory. Each one gets sorted: answerable now, needs one specific named addition, cannot be answered by anyone yet, or is a forecast wearing the grammar of a question. Coverage gets stated next to every answer, because a number that looks complete and rests on a third of the picture is worse than no number at all. Coverage means naming the actual share, not a vague caveat: on one account, that number was 29 percent of inbound calls traceable to a completed job, stated plainly next to every figure built on top of it, rather than folded into a footnote nobody reads.
One week, from $1,900, and the document is yours to keep whether or not any build follows. If the walls above sound like your business, the Answer Audit is where to start. For the mechanics of why an assistant and a dashboard can disagree even when both are reading real data, see why your AI gives you a different number than your dashboard.