Every GTM tool you evaluate will solve the problem you brought to the demo. Most of them genuinely will. The reason stacks still turn into a mess is that solving your problem and fitting your system are two different tests, and only the first one usually gets run.
We run HubSpot as our system of record with three tools around it: Apollo, PandaDoc and Clay. Below is the test we apply before anything gets added, and how each of those three did against it.
Disclosure: IV-Lead is a formal partner of both Apollo and PandaDoc. That is a commercial relationship, and you should read what follows with it in mind. We have no partnership with Clay.
What does "where the truth lives" actually mean?
Every GTM tool holds a record of a person or a company. The question is whether it believes its copy is the real one.
Tools that assume they are the system of record invite your team to work inside them. People build segments there, add notes there, correct data there. None of it flows back. Six months on you have two versions of your pipeline that disagree, and reconciling them has quietly become somebody's job.
Tools that defer to the CRM behave differently. They enrich, they act, they write back, and they don't ask anyone to live inside them.
That one distinction predicts most of how a tool ages in a stack. It's also close to invisible during evaluation, because in a demo every tool integrates beautifully. The way to surface it is to ask the vendor something blunt: if a rep corrects a phone number in your tool, and someone corrects the same number in our CRM an hour later, which one is right tomorrow? A tool that defers has a straight answer. A tool that wants the record will tell you it's configurable.
What does a new integration cost after the setup?
More than the licence, and later than you'd like.
Every integration is a field mapping somebody has to remember, a sync somebody has to notice has stopped, a failure mode somebody has to recognise, and a piece of knowledge that lives in one person's head until they leave.
At three tools that's manageable. At twelve it's a part-time job nobody has been assigned, and it almost never announces itself as an integration problem. It surfaces as "why is this report wrong" — a far more expensive thing to diagnose, because you start by doubting the report.
So the bar isn't whether the tool is good. It's whether the job it does is worth carrying a permanent maintenance obligation for. Most tools fail that, and failing it isn't an insult to the tool.
What are the three tools actually for?
Apollo — finding and enriching. Answering "who should we be talking to, and what do we already know about them" before anyone spends time on it. The database isn't the value; databases are commodities and they all decay. The value is that enrichment lands on the CRM record instead of in a list a rep maintains privately.
PandaDoc — quote to close. Proposals and contracts generated, sent and tracked without leaving the deal. This is the stage that most often escapes the CRM. The last mile of the pipeline ends up in email attachments, and then nobody can answer what was actually sent, when, or what the client did with it after.
Clay — the newest, and the least settled. Where Apollo is a source, Clay is logic sitting over sources: chaining enrichment, filling from one provider when another returns empty, applying rules before anything reaches the CRM. It's the piece we're still forming a view on, which is worth saying plainly rather than presenting three tools as equally proven. Passing the tests above on paper is not the same as passing them in a live stack for a year.
Sequenced, the three cover find, enrich, engage, quote, close — with the CRM holding the record at every step.
Where do stacks like this break?
Two failure modes, both common, neither of them the tool's fault.
Enrichment with no conflict rule. Two providers disagree about a job title or a company size. If you haven't decided in advance which one wins, the winner is whoever wrote last — which means your data depends on sync order, and nobody is monitoring sync order. Decide precedence once, write it down, enforce it in one place.
Automation that outruns the definition. Triggering sequences off enriched fields is easy. Noticing the enrichment was wrong is hard, because the automation fires either way and the person on the other end receives something subtly off. Enriched data deserves at least the scepticism you'd apply to data a rep typed in — arguably more, because nobody watched it arrive.
Both are decisions that got skipped because the tool made it easy not to make them.
What should you decide before you add anything?
Three things, in this order.
Ask where the tool thinks the truth lives, and treat "it's configurable" as an answer in its own right. Price the integration as a permanent cost rather than a setup task, then ask whether the job justifies it. And write your conflict rules before enrichment is switched on, not after you notice the data drifting.
A stack determines far less about the outcome than the people selling it would like. What determines the outcome is whether somebody decided, in advance, which system wins when two of them disagree. Because they will.
We implement HubSpot and Asana for B2B and public-sector organisations in Israel. Most of what we get called in for isn't a missing tool. It's two tools that both think they're right.
If your stack has grown past the point where anyone can say which system wins a disagreement, that's worth looking at before the next tool goes in. Book a 30-minute review and we'll map where your record actually lives today.
