Why RAG Fails in Enterprise GTM: Solving Broken Object Association with an Object Graph

Q1. Why does your RAG assistant keep returning the wrong account's data? [toc=1. Wrong-Account Answers]

Because the distinguishing information is not in the text. A sales conversation rarely names the opportunity it advances, so when one account has three open opportunities with overlapping stakeholders, similarity search has nothing to disambiguate on. The embedding is fine. What is missing is a reliable foreign key linking each conversation, email, and message to the correct account, opportunity, and person.

⭐ The answer that read perfectly and was wrong

A RevOps lead I worked with asked her internal assistant a simple question. Why has the Acme renewal stalled? The answer came back fluent, sourced, and quoting a real call.

The call was real. It belonged to the Acme expansion deal, not the renewal. Same logo, same two stakeholders, different commercial motion. Nothing in the transcript said "renewal" or "expansion", because sellers do not talk that way.

❌ Why better embeddings do not touch this

Chunking, reranking, and a longer context window all improve how candidates get ranked. None of them decide identity. Ranking asks which passage is most similar. Association asks which object this passage belongs to.

Record linkage research has treated that as a separate statistical problem since 1969, when Fellegi and Sunter formalised deciding whether two records describe the same entity. That decision needs comparison across candidate records. A single vector has no candidates to compare. The same gap shows up in everyday CRM data quality automation for RevOps work, where the field is populated but pointing at the wrong record.

✅ Association is a decision made before retrieval, not during it

Here is the part that is easy to miss. If an email thread is bound to the wrong opportunity at ingestion, every downstream layer inherits the error and presents it with citations attached. The assistant is not hallucinating. It is faithfully quoting a document that was filed in the wrong drawer.

Operators feel this first as a write-back problem, because that is where it becomes visible in the CRM, and it is the recurring theme in Gong CRM integration discussions.

"limitations of getting data back into salesforce"
— Verified reviewer, Sales team user, Gong - G2 Verified Review, 3 stars, 21 May 2026

"Data updates like contact information sometimes does not update... A handful of features don't work properly (inbound calls, task reminders, data connectivity between apps (CRM, Sales Nav)"
— Verified reviewer, Sales team user, Salesloft - G2 Verified Review, 1.5 stars, 26 March 2025

⏰ The number that caps everything you build

The older way of solving this was a simple lookup. Match the email domain, take the first account that comes back, move on. That is not how a seller thinks. A seller looks at every open account, weighs the context, and works out where the conversation belongs.

So there is one number that governs your whole retrieval stack. What share of your conversation corpus carries a correct opportunity ID that no human typed? Most teams have never measured it. I will give you the protocol later, because the honest objection comes first.

Q2. Is this a retrieval problem or an entity resolution problem? [toc=2. Retrieval vs Entity Resolution]

It is entity resolution, and the distinction decides your roadmap. Retrieval quality is bounded by entity resolution, not embedding quality. If 30% of your corpus is bound to the wrong opportunity, no reranker recovers those answers. Entity resolution (deciding which real-world thing a record refers to) is mature in identity, finance, and master data management. GTM is the hard case, because the linking evidence sits in unstructured conversation rather than in a key.

⭐ Two different problems that look identical from the outside

Retrieval is a ranking problem. Given a pool of candidates, order them by relevance. You can A/B test that on Friday and see a number move.

Association is a truth problem. Given an artefact, decide which opportunity it advances. You cannot A/B a wrong foreign key, because both versions of the system will sound equally confident.

✅ What each layer can actually fix

The left column is tractable with better engineering. The right column stays broken no matter how good your embeddings get.

⚠️ Where the vocabulary gets muddy

Entity resolution is a well understood discipline, and nobody in GTM invented it. Banks run it on customer identity. Government registries run it on people. The term "context graph" is in general use across several vendors, and treating it as proprietary language would be dishonest.

What is genuinely unusual about revenue data is the evidence available. Salesforce documents activity matching against contact and lead email addresses, which is exactly the structural approach that works until the email address stops being a reliable signal, a limit covered in more depth in these Salesforce Einstein reviews. In GTM, the deciding evidence is often the content of the conversation itself, which structured matching never reads.

My read is that most teams misdiagnose this because the symptom appears at the answer layer. The fix sits three layers upstream, and the fix is not a model. That is also why an agentic AI implementation starts with RevOps data architecture rather than with model selection.

Q3. Can't you solve this with metadata filtering and a nightly job? [toc=3. The Metadata Filter Objection]

Often yes, and plenty of teams run it in production successfully. Metadata filtering works exactly as well as the metadata. In GTM, the keys are produced by reps typing into fields, which is the failure this entire category exists because of. So the real question is what share of your conversation corpus carries a correct, non-null opportunity ID that no human typed.

✅ The setup that genuinely works

A filter on opportunity_id before the vector search, plus a nightly reconciliation job, plus strict field validation at the point of capture. I have seen that configuration hold up well. If your reps are disciplined and every account has one open opportunity, stop reading and keep it.

The objection is fair, and it deserves a straight answer, not a strawman. If you are weighing the internal build against a vendor, the trade-offs are laid out in this build versus buy guide for revenue AI.

❌ Where the filter has nothing to filter on

Filters operate on keys. The failure is upstream of the keys. Three cases break it, and none of them is exotic.

• One call covers three customer accounts in a partner briefing. There is no single correct value to write into the field.
• The buyer's company gets acquired. The email domain changes, the rule matches nothing, and the activity is silently dropped.
• Two account records exist for the same logo. The rule picks one. Sometimes it picks the ghost.

Practitioners describe the maintenance load plainly, which is the part vendors rarely quantify, and it echoes what shows up across Gong reviews.

"Real Time integrations can be time consuming"
— Verified reviewer, Sales team user, Gong - G2 Verified Review, 2.5 stars, 21 April 2026

"I found the AI tracker setup to be quite difficult, especially concerning the user interface when setting up keywords or smart trackers."
— Verified reviewer, Sales team user, Gong - G2 Verified Review, 3 stars, 3 October 2025

⏰ Run the measurement before you argue about it

Sample your own corpus. Count the artefacts carrying an opportunity ID, then count how many of those IDs a system assigned rather than a person. Then check correctness by hand on the multi-opportunity accounts.

That third number is your ceiling. Every agent, dashboard, and forecast you build on this corpus inherits it, which is why CRM data strategy drives revenue predictability long before any model does.

⚠️ The second objection, which is the real one

"This is a data quality problem, not an AI problem, and buying an AI vendor will not fix it." Correct. Any vendor claiming a model cleans dirty data is selling you something.

The narrower claim worth testing is that association can be produced from the conversation stream itself instead of from rep input. That does not clean your historical CRM fields. It does not recover a deal advanced over an unrecorded phone call. I will show you how that mechanism works once the failure taxonomy is on the table.

Q4. Which association failures break every rule-based system? [toc=4. Four Association Failures]

Four, each with the same root: the key is guessed from an email domain. One account with several open opportunities, so activity files against whichever the rule hits first. One call covering multiple customer accounts, logged wholly to the partner. An acquisition changing the domain, so the activity matches nothing and is silently dropped. Duplicate records, where the tool picks between a live account and a ghost at random. Oliv AI publishes these same four scenarios as the test cases for its Object Graph (retrieved 19 September 2026).

⭐ Why the domain lookup made sense for a decade

When every company ran one product and one deal per logo, a domain match was a reasonable proxy for identity. It was cheap, fast, and mostly right. Pipelines were linear, so first match and best match were usually the same record.

Then multi-product portfolios, renewals running beside expansions, and a decade of CRM sprawl arrived. Your CRM is not clean. Your pipeline is not linear. The proxy stopped holding, and nothing in the rule can tell you when it broke.

❌ The four failures, and how to spot each one in your logs

⚠️ The failure you cannot see is the expensive one

Misfiled activity at least shows up somewhere. Dropped activity never enters retrieval at all, so your assistant answers from a corpus with a hole in it and reports no error. Nothing looks broken on the dashboard.

That is why I push teams to count null links before they count wrong links. The silent bucket is almost always bigger than the noisy one, and it quietly distorts every AI deal intelligence view built on top of it.

✅ What reasoning over candidates looks like in practice

Oliv AI's Object Graph page states the mechanism rather than the benefit: instead of matching a domain and taking the first account, it weighs every open account and opportunity, relationship history, conversation context, and live M&A news before placing an activity, and it treats duplicate resolution as a byproduct rather than a separate cleanup project (published on oliv.ai/object-graph, retrieved 19 September 2026). A call from two people at acme.com lands on Renewal, Acme Inc, because the conversation is about the contract end date, not the new module. That same page attributes rule-based mapping to Gong, Clari, Salesloft, and Salesforce, and I am presenting that as our published claim rather than as an independently verified description of how those products work internally. No association accuracy figure has been published, so I am not going to quote one.

"The Revenue Harness and Context Graph are standouts, giving me detailed briefs before every call and saving me over 10 hours a week on admin tasks... The only downside is that the platform can be a bit glitchy at times."
— Verified reviewer, Sales team user, Oliv AI G2 - Verified Review, 5 stars, 2 July 2026

"I appreciate the feature that brings all tool information into one place, maintaining CRM cleanliness and spotting risks early... I'd love to see few more options to customize dashboards and reports for different teams."
— Verified reviewer, Sales team user, Oliv AI G2 - Verified Review, 4.5 stars, 26 June 2026

💰 The detection job worth running this week

Query your activity table for records ingested in the last 90 days with a null account or opportunity link. Group them by sender domain. The domains that changed hands in the last year will cluster, and that cluster is your acquisition blind spot. Teams running AI agents for RevOps should run this query before they trust a single agent action.

Q5. How do you measure the association ceiling on your own corpus? [toc=5. Measure Your Ceiling]

Sample 200 conversations at random and check three things: does the artefact carry an opportunity ID, was it assigned by a system rather than a human, and is it correct on manual review. The correct-and-machine-assigned share is your ceiling. Weight the sample toward accounts with more than one open opportunity, because that is where errors concentrate and where blended averages hide them.

⭐ The six step protocol

1. Pull every conversation artefact from the last 90 days: calls, email threads, calendar events, and chat threads.
2. Flag each one for a non-null opportunity ID. Record the null rate separately, because nulls never reach retrieval at all.
3. Split the populated IDs by origin. System assigned or human entered. Most CRMs expose the created-by field for this.
4. Draw 200 random artefacts, stratified so half come from accounts with two or more open opportunities.
5. Review those 200 by hand. Read the artefact, decide the correct opportunity, compare.
6. Report three numbers: null rate, machine-assigned share, and accuracy on manual review.

Multiply the last two and you have your ceiling. Nothing built on this corpus beats that number, which is why CRM data quality automation for RevOps belongs upstream of any assistant you deploy.

⚠️ Report it segmented, or the finding disappears

A blended accuracy rate is the most misleading chart in this whole exercise. Single-opportunity accounts inflate it, because the rule cannot get those wrong.

I have seen a 92% blended rate collapse to 61% on multi-opportunity accounts. That gap is the finding. Publish both numbers side by side in your readout, or the room will anchor on the friendly one. The same segmentation discipline is what makes evidence-based forecast commits hold up under scrutiny.

✅ Then build the eval set, not just the audit

The audit tells you how bad the keys are. A golden set tells you what that does to answers. Write 40 multi-hop questions, meaning questions needing two or more linked records to answer correctly.

Good examples: which stakeholder raised pricing on the renewal but not the expansion, and which open opportunity has had no executive contact in 30 days. Gate your pipeline on four published metrics: faithfulness, factual correctness, context relevance, and answer relevance. Add one more that vendors rarely test, which is permission leakage. Ask a question whose answer sits in a record the user cannot open, then check it against your AI CRM trust and governance evaluation.

⏰ What changes once association is handled upstream

You stop measuring the key and start measuring the decision. The question moves from "is the field populated" to "did the system pick the right opportunity among the candidates it considered". That is a harder test and a more honest one.

Oliv AI publishes the same four breaking scenarios as the test cases for its Object Graph: one account with multiple open opportunities, one call spanning several accounts, a post-acquisition domain change, and duplicate records (oliv.ai/object-graph, retrieved 19 September 2026). That makes them a usable checklist even for a team that never buys anything from us, and I would rather you run the test than take my word for the architecture. Our read is that the multi-opportunity case is the only one worth arguing about, because the other three are visible once you look for nulls. If your measured ceiling is already above 90% on multi-opportunity accounts, you have solved this, and you should tell people how.

Q6. What does broken association actually cost in forecast dollars? [toc=6. Cost of Misassociation]

Published benchmarks put poor CRM data quality at roughly $15 million a year per organisation (Gartner). Validity reports that 76% of companies say under half their CRM data is accurate, and 45% say it is not AI-ready. Gartner also forecasts that more than 40% of agentic AI projects will be cancelled by end-2027, citing escalating costs, unclear business value, and inadequate risk controls. An unmeasured association ceiling produces all three.

💰 The numbers a budget review will accept

Three figures do most of the work in a funding conversation. Each one is published, dated, and attributable, which matters more than how large it is.

❌ How a misfiled call becomes a forecast error

Follow one activity through. A discovery call about a new module gets filed to the renewal opportunity. The renewal now shows fresh multi-threaded engagement it never had.

Two things break at once. The renewal looks healthier than it is, so nobody inspects it. The expansion looks dormant, so it slips out of the commit number. One wrong key inflates one deal and starves another, which is the quiet mechanism behind most deal slippage.

⚠️ Why reps already knew and stopped mentioning it

Salesforce surveyed 4,050 sales professionals across 22 countries for its seventh State of Sales report. Just 35% said they fully trust their data accuracy. Among teams using AI agents, 46% said data quality is actively hurting sales.

That is the quiet part. Your reps stopped trusting the system before your assistant did. They route around it with spreadsheets and Slack, which removes even more evidence from the corpus and undercuts sales forecast accuracy before any model runs.

✅ Convert it into your own number before Monday

Vendor benchmarks open the conversation. Your own measurement closes it. Run two queries and put the outputs in pipeline dollars, not percentages.

• Count duplicate account records where both carry open pipeline. Sum that pipeline value.
• Count activities from the last quarter with a null account or opportunity link. Group by sender domain.

Then name the number in your next pipeline review. Something like this: 11% of last quarter's activity never attached to any opportunity, across $4.2M of open pipeline. That sentence survives a budget conversation in a way that a $15M industry average never will, because nobody can argue that your own query is about somebody else's company. It is also the cleanest input to a CRM data strategy for revenue predictability.

I would resist the urge to inflate it. The credible version of this argument is smaller than the marketing version and lasts longer.

Q7. Where does vector search still hold, and where does graph-structured retrieval win? [toc=7. Where Vector Search Holds]

Vector search holds for definitions, field descriptions, SOP lookups, and single-record retrieval. It fails on multi-table joins, aggregations, period comparisons, and metrics whose definitions are team-specific. Peer-reviewed benchmarks show graph-structured retrieval outperforming baseline vector RAG on multi-hop enterprise questions, with hybrid approaches improving factual correctness by around 8%. One product, one opportunity per account, a disciplined CRM: RAG over that corpus works fine.

✅ The case where you should not buy anything

If your team sells one product, opens one opportunity per logo, and runs a tidy CRM, this article does not describe your problem. Similarity search over your call corpus will work. Spend the money on something else.

I want to be blunt about this because the category is not. Plenty of retrieval stacks in production are fine. The failure I am describing is specific to portfolios, renewals running beside expansions, and CRMs with years of drift in them. Smaller teams should read the revenue intelligence guide for startup and SMB sales teams before adding a layer they do not need.

⭐ Works for and fails for

Works for: definitions, field descriptions, SOP and playbook lookups, single-record retrieval, "what did the customer say about pricing on this call".

Fails for: multi-table joins, aggregations across records, period comparisons, exception detection, and metrics whose definition varies by team.

The pattern is simple. One record in, one answer out, similarity is enough. Two or more linked records, and you need something that knows the links. That distinction is the practical difference between revenue intelligence and conversation intelligence.

⚠️ What the benchmarks actually report

Note what these papers do not say. They do not say vector search fails, and they do not report GTM-specific numbers. Anyone quoting a precise accuracy figure for revenue data association is extrapolating.

❌ Tools that are strong at one job, and honest about the rest

The same boundary shows up in how operators rate their existing stack. A tool can be good at one retrieval task and weak at another, and reviewers say so plainly, which is a recurring theme across Gong limitations and challenges.

"Good for tracking deals, account engagement overall, divided transcript and accurate AI highlights for calls... Gong Engage is awful in every single way compared to outreach."
— Verified reviewer, Sales team user, Gong - G2 Verified Review, 1.5 stars, 9 June 2025

"The meeting recordings, ease of use and info sharing and the AI enrichement capabilities... The fact that you cant't edit a recording... and the fact that if you stop working with thew tool you lose the data"
— Verified reviewer, Sales team user, Gong - G2 Verified Review, 3 stars, 19 March 2026

⏰ The one query that tells you which camp you are in

Count open opportunities per account with pipeline attached. If the median is one, your retrieval problem is a ranking problem, and you should tune the reranker. If the median is two or more, you have an association problem, and no amount of tuning reaches it.

Q8. What is an object graph, and how is it different from your warehouse or your CRM? [toc=8. Object Graph vs Warehouse]

An object graph is a resolved map of which people, accounts, and opportunities each activity belongs to, maintained continuously as new activity arrives. A warehouse stores the rows and preserves whatever keys it was given. A CRM owns the object model but depends on humans to populate the links. Oliv AI's Object Graph is this layer in its published architecture, and it sits beside the CRM rather than replacing it (oliv.ai/pricing, retrieved 19 September 2026).

⭐ The plain definition

Think of it as the answer to one question, asked continuously. For every artefact that lands, which account, which opportunity, and which person does this belong to?

That is a decision, not a storage format. The output looks like keys, but the value sits in how ambiguous cases get resolved.

✅ Three layers, three different jobs

A warehouse is excellent at scale and terrible at judgement, by design. It is not supposed to guess. That is why "just put it in Snowflake" does not fix wrong-account answers, a point worth reading alongside this guide to agentic AI implementation and RevOps data architecture.

⚠️ It enriches the CRM, it does not replace it

This is the drift to watch for, and I will name it before anyone else does. A layer holding the resolved object model sounds a lot like a CRM, and vendors slide into that claim easily.

Oliv AI's pricing page answers the question directly: "No. Oliv works with your existing CRM." The object graph writes association back into Salesforce or HubSpot and keeps those records current, so the system of record stays where your process, permissions, and reporting already live. A full argument for why the context layer should enrich rather than replace the CRM is its own piece, and I would rather point you to how revenue intelligence integrates across CRM, Slack, and email than compress it here.

⏰ Where it sits in the stack

The published architecture is three graphs over two foundations. Object Graph, Process Graph, and Signal Graph together form the Context Graph, running on Context Capture and an AI data lakehouse.

I am staying inside the Object Graph for this article on purpose. Assigning an artefact to an entity is association. Interpreting what the artefact means is a different layer with different failure modes, and mixing the two is how architecture posts stop being checkable. If you want the downstream view, the AI agents for RevOps breakdown covers what runs on top of this layer.

Q9. How does association get produced without a human tagging anything? [toc=9. Association Without Tagging]

By reasoning over candidates instead of matching a key. Oliv AI's published pipeline captures each email, call, calendar event, and Slack message as a context object with participants, content, and timestamps, pulls every candidate account and opportunity, then weighs relationship history, conversation context, recency, engagement, and live M&A news to place the activity, including when one account has multiple open opportunities. Duplicate cleanup falls out as a byproduct (oliv.ai/object-graph, retrieved 19 September 2026).

⭐ The four steps, mechanism only

Oliv AI's Object Graph page sets out the sequence in four stages, and I would rather state the mechanism than the benefit. Capture the artefact with its full content and participants. Retrieve every candidate account and opportunity that could plausibly own it.

Score the candidates against relationship history, conversation content, recency, and engagement patterns. Write the resolved link back. Nobody types anything, and the decision is auditable because the candidates are logged. That audit trail is what separates a working RevOps data architecture for agentic AI from a black box.

❌ Why discarding the transcript breaks the whole thing

Here is the part that matters for anyone building this themselves. Many capture layers keep metadata and throw away content. Attendees, timestamps, subject lines, duration.

That is exactly the evidence association needs. The sentence that reveals whether a call is about the renewal or the expansion sits in the body, not the header. Once the content is gone, you are back to guessing from a domain, and no downstream model can recover the signal. It is the same limit that shows up whenever revenue intelligence gets confused with conversation intelligence.

✅ The multi-opportunity case, worked end to end

Take two people from acme.com on a 30 minute call. Acme has a renewal closing this quarter and an expansion in discovery. Both share one of the two attendees.

The conversation covers contract end dates, current seat counts, and a procurement review. The reasoning layer weighs those signals against both open opportunities and places the call on the renewal. A domain rule would have picked whichever record it hit first, and it would have looked equally confident doing it. That single decision is what makes cross-channel deal intelligence trustworthy at the pipeline level.

"Oliv.ai helps me with pipeline visibility and deal overview, keeping my CRM updated and automating contact creation... The initial setup was really easy because the team provided FDE engineers who set everything up."
— Verified reviewer, Sales team user, Oliv AI G2 - Verified Review, 4.5 stars, 17 June 2026

"I love that it automatically updates CRM records after calls and meetings, keeping the data clean and accurate without manual effort... It's a lil slow"
— Verified reviewer, Sales team user, Oliv AI G2 - Verified Review, 4.5 stars, 23 June 2026

⚠️ Where the work happens after resolution

Oliv AI's CRM Manager agent is the actor that writes the resolved association back, creating contacts, updating fields, and syncing next steps into Salesforce or HubSpot. You can ask it to fill a MEDDPICC or SPICED field set from the call content, which only works because the call is already bound to the right opportunity. Ordering matters here. Populate methodology fields on a wrongly associated deal and you have produced tidy, confident nonsense, which is the failure mode to watch for in any sales methodology automation that scores MEDDIC, BANT, or SPICED from calls.

💸 The concession, said plainly

Oliv AI is a young company with a thin public proof base, and a builder should weigh that. Our G2 reviews are recent and few, the case studies sit behind an email gate, and no association accuracy percentage has been published anywhere, which is why I have not quoted one in this article. What is public and checkable is the pipeline itself, the integration list, and the price ladder (Amplify $0, Converse $19, Sell $49, Grow $79, with agent actions billed at $0.01 per credit). My honest read is that architecture should carry this decision rather than logos, and if you would rather verify the association behaviour against your own corpus than trust a case study, that is the right instinct.

Q10. Who is allowed to see what your assistant retrieves, and what does association still not fix? [toc=10. Permissions, Provenance, Limits]

Resolved association changes your access-control surface. Once every artefact carries an account and opportunity, permissions become enforceable per object rather than per index. Left unenforced, the same resolution makes leakage easier. Association also does not clean historical CRM fields, and it cannot resolve entities that were never captured anywhere. Oliv AI states the scope of its own claim on the pricing page, as accurate connection of meeting, phone, email, and Slack activity to the right accounts, contacts, and opportunities, on a SOC 2 Type II and GDPR compliant footing.

⚠️ Permission bloat is a retrieval failure, not a security afterthought

The failure looks like this. An AE asks the assistant a broad question. The answer includes a detail from an opportunity they were never given access to.

Nothing was hacked. The index simply had no idea who owns what, because a vector store holds text, not entitlements. This is one of the most commonly reported enterprise RAG failure modes, and it usually surfaces in front of a customer or an auditor, which is why it belongs in your AI CRM trust and governance evaluation.

❌ The old answer was all or nothing

Before object-level resolution, teams solved this crudely. Either everyone could search the whole corpus, or you built a separate index per team and duplicated everything.

Both options are bad. The first leaks. The second fragments your context, which recreates the scatter problem you were trying to fix. Teams running revenue intelligence across CRM, Slack, and email hit this wall first.

✅ What resolution makes possible

That third row is the one worth building toward. Permissions inherit from the system that already defines them, and every answer can show which artefact it came from and which opportunity that artefact was bound to.

⏰ The 2026 procurement context

This has moved from good practice to a checklist item. The EU AI Act entered into force in August 2024, with obligations phasing in through 2026, and it requires traceability and human oversight for higher risk uses. India's Digital Personal Data Protection Act, 2023 carries its own consent and purpose limitation duties for personal data.

Ask vendors for three things: permission-aware retrieval, audit logs of agent actions, and provenance on every generated answer. The broader governance argument for trusting AI with CRM data deserves its own read, and I would rather point you to the mid-market revenue AI buyer guide on governance and SOC 2 than compress it.

❌ What this layer genuinely does not do

• It does not clean historical CRM fields. Bad data from 2022 stays bad.
• It cannot resolve entities that were never captured. An unrecorded phone call is invisible to every graph.
• It does not make a model honest about gaps in its evidence.
• It does not remove your governance work. Someone still decides what an agent may act on without asking.

💰 Where I would leave you

Oliv AI makes an association claim, not a data hygiene guarantee, and I think that distinction is the most useful thing in this article. Run the measurement from Q5 on your own corpus this week. Segment it by opportunities per account, then look at the multi-opportunity number, because that is your real ceiling. If it is high, keep building what you have. If it is not, you now know which layer to fix, and you can book a demo or go build it yourself with a clear spec, using the build versus buy comparison for revenue AI as your framework.