Salesforce published an official guide for connecting Claude to Salesforce via MCP in May 2026. The setup takes about 30 minutes. Within an hour, you can ask Claude to pull pipeline data, summarize an account, or look up a contact.
This is not hype. It works. The question is what happens after the first hour.
We talk to revenue teams every week who started with Claude and hit a ceiling. The pattern is consistent enough that we can map exactly what works, what breaks, and when.
What Works
Claude is genuinely good at a narrow set of revenue tasks. If your need stays within these boundaries, it delivers:
Single-record CRM lookups. "What stage is the Acme deal in?" "Who owns the Datadog account?" "What is the close date on opportunity X?" Claude reads structured Salesforce data through MCP and returns clean answers.
Simple aggregations. "How many deals are in Stage 3?" "What is our total pipeline this quarter?" As long as the query maps to a straightforward SOQL call, Claude handles it.
Drafting from a single source. Give Claude one call transcript and ask it to write a follow-up email or summarize the meeting. It performs well when the entire context fits in one prompt.
These are real use cases. A RevOps leader or an AE who needs quick CRM answers will get value from Claude on day one.
What Breaks
It forgets everything between sessions
Claude has no persistent memory across conversations. It does not know your fiscal year starts in February, that your team uses New_ARR__c instead of Amount, or that "Stage 2" means Solution Demonstration. Every session starts from zero. The workaround is writing skill files: markdown documents that pre-load context into each conversation. One file per use case. Then a GitHub repo to manage them. Then someone to maintain the repo as your CRM evolves. You are now building infrastructure.
It cannot analyze at scale
A single call transcript runs 10,000 to 20,000 tokens. A manager with five reps, ten deals each, and five calls per deal has 250 transcripts. That is 2.5 to 5 million tokens. Claude cannot fit it. It will sample a handful of calls and extrapolate, which means the answer to "what are the top objections across my team this quarter" is based on five calls, not fifty. The manager does not know this unless they check.
It gives different answers to different people
Two AEs ask "how is my pipeline looking?" and get different quality answers depending on how they prompt. One includes the right field names and exclusions. The other gets a plausible but wrong number because Claude used the Amount field instead of the custom ARR field. There is no governance layer. No shared definitions. No way to enforce that "pipeline" means the same thing for everyone.
It cannot cross-reference sources
The hardest revenue questions require combining structured and unstructured data. "Which deals have gone dark based on email and call activity?" "Is the champion still engaged or have they stopped showing up to calls?" These questions require reading CRM fields, scanning email threads, analyzing call transcripts, and cross-referencing all three. Claude through MCP connects to one system at a time and cannot hold the combined context.
It breaks when you add users
The person who built the Claude setup knows how to prompt it. They know the caveats, the field names, and the edge cases. When they hand it to ten AEs, the AEs do not know any of this. They ask natural questions and get confident but incorrect answers. Scaling from one power user to a team requires building guardrails, permissions, and a shared context layer. That is a product, not a prompt.
The Build Progression
Teams that try to fix these problems follow a predictable path. First, they write skill files to pre-load context. Then they stand up a GitHub repo to manage the skill files. Then, because Claude has context limits, they add preprocessing in Snowflake or BigQuery to work around the token ceiling. Then they build a custom UI because the chat interface does not support sharing, role-based data scoping, or dashboards.
Each step is reasonable on its own. Together, they add up to months of engineering and multiple full-time GTM engineers to maintain. The prototype took an afternoon. The production system takes a team.
What This Means
Claude is a strong foundation model. The limitation is not the model. It is the absence of everything around it: the business context, the data preprocessing, the organizational memory, the multi-user governance, and the infrastructure to keep it all current.
A GTM system of intelligence like Von is purpose-built to solve these problems. It connects to your CRM, call recorder, email, Slack, and data warehouse, then spends 3 to 7 days autonomously building a go-to-market brain: your pipeline stages, revenue definitions, sales methodology, team structure, and institutional knowledge. When one user corrects a definition, the correction applies to everyone. When a manager asks about deal risk, Von analyzes thousands of calls, not a sample of five.
Bloomreach tried building the Claude harness themselves for six months with five engineers. Then they switched to Von and went from 20 users to 400 in a few weeks.
Frequently Asked Questions
Can Claude connect to Salesforce? Yes. Salesforce published an official MCP integration guide in May 2026. The connection takes about 30 minutes and supports read and write operations on standard Salesforce objects. It works well for single-record lookups and simple aggregations.
What are the limitations of using Claude for sales? The main limitations are context persistence (Claude starts from zero every session), scale (it cannot analyze hundreds of calls or emails in a single query), governance (no shared definitions across users), and cross-source reasoning (it connects to one system at a time through MCP). These limitations are architectural, not bugs.
Is Claude MCP good enough for a revenue team? For individual use by a RevOps leader or an AE who knows how to prompt it, Claude via MCP delivers real value for CRM lookups and single-source drafting. For team-wide deployment with consistent answers, shared context, and multi-source analysis, it requires significant infrastructure built around it.
How do I scale Claude for my sales team? Scaling Claude for a sales team requires building a context layer (skill files and organizational definitions), a data preprocessing pipeline (to handle call and email volume beyond the context window), a governance framework (shared definitions and permissions), and a user interface (for sharing and role-based access). This is the equivalent of building a product.
What is the difference between Claude and a revenue intelligence platform? Claude is a foundation model accessed through a chat interface. A revenue intelligence platform adds persistent business context, preprocessed unstructured data, organizational memory, multi-user governance, and managed infrastructure. Claude is the engine. The platform is the car.
This is the second post in the AI for Revenue Teams: Build vs. Buy series.
Previous: Why Building a SalesGPT Is Harder Than You Think
Next: ChatGPT Work for Sales: What It Does and What It Does Not
