--- title: "Claude Cowork is impressive — here's the infrastructure it assumes you have" description: "A field report on the accuracy gap in AI revenue tooling and how a sourced semantic layer closes it." canonical: "https://vasco.app/claude-case-study" --- # Claude Cowork is impressive — here's the infrastructure it assumes you have For RevOps teams building their GTM on top of AI agents, the question isn't whether Claude Cowork is useful — it's whether the data underneath it is trustworthy enough to act on. The gap isn't data *access*; it's data *architecture* — the layer between your tools and Claude that reconciles identities, enforces meaning, and remembers outcomes. What follows is one customer's story: anonymized details, real data, real consequences. ## Claude won't tell you it's wrong MCP is the connector layer — it gives Claude access to CRM records, call transcripts, billing events, and Slack threads. Most teams connect HubSpot, Gong, Stripe, and Slack and assume they've covered their bases. But four pipes are still just pipes: every MCP reports CONNECTED, and the gap is what sits *between* them. Claude doesn't say "I'm not sure" — it says "here's your pipeline summary," wrong in a way that looks exactly like being right. Five structural gaps: - **No shared definitions** — what's an SQL? How is NRR calculated? A "qualified lead" in HubSpot, a "high-intent signal" in Gong, and a "converted trial" in Stripe might be one account or three. Claude can't reconcile what nobody defined. - **No identity resolution** — the same contact is a HubSpot record, a Gong participant, and a Stripe customer. Without resolution Claude treats them as separate, so the Gong call where budget was flagged never connects to the deal it matters for. - **No plan or targets** — Claude can total closed-won from HubSpot but doesn't know your number, which motion carries it, or pace vs. target. - **No outcome memory** — Claude reasons on current state; it doesn't know the last four deals with this exact pattern (stalled at Stage 3, no exec contact, competitor in calls) all closed-lost. Every deal is assessed from scratch. - **No cross-tool sequencing** — HubSpot thinks in deals, Gong in calls, Stripe in subscriptions, Slack in threads. Nobody told Claude how they relate, how to sequence a deal journey, or which signal overrides which in conflict. ## What "confidently wrong" actually looks like A real (anonymized) setup: B2B SaaS, mid-seven-figure ARR, 38 active accounts, Claude Cowork connected to HubSpot, Gong, Stripe, and Slack via MCP. **What Claude reported:** "Pipeline is stable, you're on track" — 9 active deals, MQL→SQL 75% (healthy), quarter tracking to the $240K target with no alerts, Norden renewal on track. **What the data actually said that same week:** - A **21% revenue gap** — $180,390 actual vs. a $240,000 target. No tool encoded the target, so no tool flagged the miss. - **SQL→SAL conversion was 34%** — Claude reported the MQL→SQL number HubSpot tracks cleanly; the qualification-to-acceptance step needs a definition MCP doesn't carry. - **9 deals with zero engagement for 30+ days** — no calls, emails, or stage changes, yet HubSpot still showed them "active." No rule connects cross-tool silence to a stalled deal. - **Norden cancelled payment and closed its bank account** — the Stripe event existed and Claude had access, but a Stripe customer ID ≠ a HubSpot company without identity resolution. - **Kepler flagged budget as a "huge challenge"** on a recorded Gong call — call participants didn't map to HubSpot contacts, so the signal floated unconnected. - **Meridian competitor displacement** was called out in a Slack thread — no schema tied the thread to the HubSpot opportunity. The automation didn't just miss signals — it replaced the manual check that would have caught them. ## Won't Claude just get better at this? Probably — MCP is evolving and models keep improving, so cross-tool reasoning will get meaningfully better over 12–24 months. But there are categories of knowledge no model can conjure, because they don't live in your data: - **Your definitions** — what counts as an SQL, churn vs. downgrade. Business decisions, not data patterns. - **Your plan** — quota targets, motion benchmarks, segment thresholds. These live in spreadsheets and board decks, not connected systems. - **Your outcome history** — which patterns led to wins, losses, or churn. CRMs store deal status, not the causal chain. - **Your identity map** — revenue decisions need deterministic, auditable resolution; "probably the same account" isn't good enough for a billing-risk alert. Definitions, plans, outcome tags, and identity maps are infrastructure — they must be built, not inferred. ## What Claude needs underneath it: a revenue context graph Dashboards tell you *what happened*; context graphs tell you *why*. (HubSpot's Dharmesh Shah has written about context graphs — AI needs the relationships and decision traces that connect data to meaning — with the caveat that most companies aren't ready.) Revenue teams don't need a fully instrumented decision-trace graph; they need a bounded version that connects the five or six systems holding ~90% of revenue context and gives them shared schema, identities, and definitions. Three layers: - **Foundation** — connectors (HubSpot, Gong, Stripe, Slack) plus a single authored dictionary of what SQL, NRR, pipeline, and churn mean at your company. Where garbage-in stops. - **Planning** — what "on track" means: quota, motion-level pace, segment thresholds, ramp curves — a number Claude can compare against. - **Context** — the graph itself: shared identities, cross-tool sequencing, tagged outcomes, validated patterns. Plug Claude in here and it stops guessing and cites the structure. ## How the graph learns A graph that connects systems is useful; one that learns from outcomes is transformational. The loop: 1. **Outcome tagging** — every deal/customer gets a tagged outcome (Won, Churned, Expanded, Downgraded, Stalled) from CRM close reasons, validated against billing. 2. **Pattern extraction** — with 50+ won and 50+ lost tagged, the graph runs comparative (cohort-style) analysis, surfacing correlations with confidence scores tied to sample size. 3. **Correlation validation (human in the loop)** — RevOps validates whether a pattern is causal, not spurious; "CISO engagement pre-Stage 3 → 2.4× close" becomes a rule only when the team says so. 4. **Continuous recalibration** — as outcomes flow in, correlations update; a rule that held for six months may die after a pricing change, and the graph flags the degradation. ## What it changed in practice Same customer, six months of data — two findings no CRM report could surface: - **38% of pipeline was structurally unlikely to convert.** The winning profile (Series C+ Fintech/HealthTech, 200–500 employees, compliance pain) closed in 132 days at $62K ACV; outside the ICP the numbers collapsed. The move: reallocate ~60% of outbound SDR capacity to mid-market Fintech, stop targeting sub-50, and pivot messaging to "Compliance Automation for International Expansion." - **Speed, not effort.** Top performers closed 3× larger ACVs ($25K vs. $7,560) on lower activity volume — the differentiator was velocity (early qualification, executive stakeholder mapping, proactive ROI defense), written by the graph from patterns rather than gut feel. ## Build it yourself? You can, and some teams do — but the failure mode is the same: ship v1, it works for a quarter, then it drifts because nobody maintains it. If you've built all of this and maintain it continuously, you don't need a platform. If you haven't, that's what Vasco is for. ## Claude is a reasoning engine — give it something to reason on - **MCP gives access** — it plumbs Claude into your systems. Necessary, but never meant to be the architecture. - **Vasco gives meaning** — identities reconciled, definitions enforced, journeys sequenced, outcomes remembered. - **You set the rules** — definitions, plan, ICP, validated correlations. RevOps stays the author; Claude reasons on what you authored, not what it inferred. ## Questions from RevOps leaders - *We already connected our tools to Claude — isn't that enough?* You have access, not architecture. The case study had all four MCPs connected and still missed a 21% revenue gap. - *Won't MCP improve?* At access and basic entity matching, yes — but definitions, plan targets, outcome history, and validated identity maps are business decisions encoded as infrastructure, not patterns a model infers. - *Doesn't my BI/CRM tool already do this?* Those tools analyze the data they own; a context graph is an infrastructure layer underneath all of them — it connects, reconciles, and remembers, without replacing any tool. - *Should I stop using Claude?* No — it's useful today for drafting and summarizing. What to solve is *trusting* its output for pipeline reviews and forecasting, where a wrong number drives a wrong decision. - *How much history do I need?* Tagged outcomes mapped to complete deal journeys; a statistical floor of ~50+ per category. Below that the graph connects and reports; above it, it identifies what works. - *Who should own this?* RevOps. MCP connections inherit the authorizing user's permissions — treat Claude's access like any integration: explicit authorization, documented scope, named owner. ## See it on your data Use Claude now — just know where the trust boundary is. Vasco is the revenue context graph underneath your AI; see it reconcile your four MCPs into one queryable layer in a 30-minute demo on your actual data. [Talk to sales](/request-demo) · [Start for free](https://my.vasco.app/get-started).