Claude for Business: SEO, Outreach, Where It Breaks

The pitch for Claude in a business context is that it closes deals while you sleep. That pitch is wrong, and believing it is the reason most deployments stall in month two.

The better pitch arrived this month, and it is much more specific. Anthropic shipped Claude Cowork, which it describes as Claude Code for everything that is not software work: research, analysis, and document creation, driven by the same agentic loop. It runs on your desktop, it gets permission to read and write the folders you name, and it connects to the tools you already pay for. Anthropic’s own tutorial for it is titled “research any account before the first call.”

That is the honest shape of the opportunity. Claude does not close and it does not attend. It compresses the work that happens on either side of those two human acts.

Claude is a pipeline optimizer, not a closer. Everything that follows is a description of where that line sits in practice, and where the current tooling genuinely is not ready.

The release that changes the answer

Until recently the honest answer to “should a marketing or sales team use Claude” was “use Chat, and accept that it cannot touch your files.” Cowork removes that caveat. Anthropic describes the difference in plain terms: in regular chat, Claude responds to messages but cannot access your files directly, whereas in Cowork it has permission to read, edit, and create files in folders you specify, so it can actually complete tasks rather than just describe how to do them.

The framing Anthropic uses for the product is worth repeating because it is the most accurate one available: “Cowork is where you hand Claude real work. It runs on desktop, with web and mobile in beta. Claude works in the files and tools you choose and completes multi-step tasks from start to finish. You define the goal. Claude figures out how to get there.”

For a sales or marketing team, that is not a toy. The vendor publishes concrete workflows rather than vibes. One is a marketing team that uses Cowork to gather weekly reviews on a schedule. Another is a sales team that uses it to research any account before the first call. A customer quoted in the launch post describes the value in the least hypey way possible: “In most AI chat tools, you’d query Slack, then query Databricks, then manually stitch the results together. Cowork can do all of that in a single pass. That’s a fundamentally different kind of capability.”

There is a limit worth pricing in before anyone builds a habit around it. The same page states plainly that Cowork consumes limits faster than Chat, and for heavy usage you should consider upgrading. This is an operations product that does real work per run. Budget for consumption the way you budget for seats.

Computer use is included but sits in research preview for both Cowork and Claude Code, and it asks permission before touching each application. That is the right default and it is also the current ceiling. If your workflow depends on Claude clicking through a legacy CRM, you are depending on a preview feature.

SEO: the return is in coverage, not volume

The unglamorous half of SEO is the half that scales badly with headcount. Competitor gap analysis. Mapping queries to the pages that already rank for them. Metadata at volume. Content briefs that reflect what the search results actually reward rather than what the founder believes the market wants.

All of it is text transformation over a corpus you already own, and all of it is exactly the shape of task an agent handles well. The wins are real and they are unglamorous: the long tail you currently decline to touch because nobody has time, the internal link audit that has been on the backlog for two quarters, the metadata refresh across four hundred pages.

The failure mode is volume. Publishing more pages than you can maintain makes the domain worse, not better. The binding constraint on most content operations is not generation throughput, it is review capacity. An agent that produces forty drafts a week and a team that can properly review six is not a content operation, it is a landfill with a publishing API.

There is also a tooling gap that is easy to miss. If the plan is “connect Claude to our SEO stack,” the connectors are not there yet. A GitHub search for MCP servers tagged for SEO returns fifteen repositories, and the most starred of them has three. A search for CRM-facing MCP servers is worse: modelcontextprotocol salesforce returns nothing at all, and a search for HubSpot servers returns four repositories whose best is a single star. This ecosystem is effectively greenfield. The honest version of the plan is that your team writes the connector, or you accept a manual export and import step.

That gap shapes how you should sequence the work. A content team can get most of the value from a folder on a laptop, because the corpus is already text and the deliverable is text. A revenue team cannot, because the corpus is a database and the deliverable is a record that has to survive contact with a CRM.

The same split shows up in what people actually build. On the automation side, the tools that dominate practitioner posts are the connective ones, the platforms that sit between systems rather than inside them: Zapier and Make and n8n for orchestration, Clay for list building and signal capture. What the model does inside that chain is narrower than the marketing suggests. It reads a list, scores it, drafts a message, and writes a field. The judgment about which list to run and what to do with the reply stays with the person who owns the number.

There is a measurement trap that catches teams at exactly the moment automation starts working. Rank trackers and traffic dashboards reward volume, so the first month of generated content almost always looks like progress. The signal that actually correlates with revenue is much slower: whether pages that were rewritten started ranking for terms they previously sat on page three for, and whether those pages convert. If you cannot answer that, you have built a content factory and not an SEO program.

The cheapest first win is almost never new pages. It is the audit nobody runs: title tags, meta descriptions, heading hierarchy, internal links between pages that obviously belong together, redirect chains left over from a migration two years ago. It is boring, it is entirely mechanical, and it is exactly the kind of work an agent does in an afternoon and a team defers for a year.

Outreach: research compression meets a saturation wall

Outbound fails for a boring reason. Research per prospect takes six minutes, so nobody does it past the first hundred names, and the hundredth prospect gets the same three-sentence template as the first. Reply rates collapse and everyone concludes the channel is dead.

Agents compress the research to seconds. Company background, recent announcements, the tooling visible in their job postings, who the decision maker actually is, what they have argued about publicly, and which of their problems your product has a credible answer to. A seller with no engineering background described building a full B2B sales outreach platform alone with Claude as the only engineering team, and another described spending a weekend replacing a multi-tool prospecting setup with an outbound system built in Claude Code plus a couple of APIs.

It drafts the message. A human sends it. That single boundary is the whole game.

Here is the part that gets left out of every vendor deck. The tooling does not just make your outbound better, it makes everyone’s outbound better, and the inbox is a shared, finite resource. A seller writing from r/sales, who started in the industry in 2004 and has taught social selling since 2014, put the mechanism plainly: “When you have tools and technology that allows us to find and reach prospects more efficiently, more people will do it, so eventually, the problems become - people just ignore everything. The data and tools have lowered the barrier to entry.”

That is not a reason to skip the work. It is a reason to compete on the one thing the tooling cannot manufacture, which is a reason your prospect has actually given you. Volume advantages belong to whoever is cheapest. Relevance does not scale the same way.

The results people report are real and also wildly inconsistent, which is the honest summary. One senior sales manager at a B2B software company doing roughly $15M ARR reported that an AI outreach workflow brought in 29 new paying enterprise customers at a 0.67% conversion rate without hiring a BDR. Another poster, a working inside-sales rep, reported building a four-system platform in six days for about $274 per month. Both are self-reported and unverified, and the spread between them is the point. Treat every number in this category as a claim until you have run it yourself.

Deliverability deserves its own paragraph because it is where most outbound automation quietly dies. The mechanics are unglamorous and unforgiving. Sending volume from a domain that has not been warmed up gets the domain flagged, and once it is flagged the reply rate on your best contacts collapses along with it. Prospects who agreed to a meeting stop reading. Nothing in the model layer fixes this, because nothing in the model layer causes it.

The teams that report durable results describe a specific shape: a small, well-researched list, a human reviewing every message before it sends, and a cadence measured in conversations per week rather than emails per day. That is a smaller number than the tooling implies you could send, and it is the number that survives contact with a filter.

Segmentation is where the model adds something a template cannot. A template produces one message shape with variables swapped. An agent that has actually read the prospect’s recent announcements, their job postings, and their public writing can find the specific sentence that matters to them, which is the difference between a message that reads like research and one that reads like a form letter with a name in it. The cost of that quality is latency and human review time, which is why the teams doing it well are not automating the send.

Lead enrichment: the data is the bottleneck, not the model

This is the least discussed and most valuable of the three. Your product database already contains intent signals that nobody reads. Which accounts stalled during trial. Which opened four emails and clicked nothing. Which invited a colleague and then went quiet. That last group is buying intent rather than engagement, which is the most valuable segment most companies have and cannot see.

Anthropic’s own MCP documentation gives the shape of the work with a literal example: find emails of ten users who used a specific feature, by querying your own PostgreSQL database. Once the plumbing is in place the model is doing something unremarkable and useful, which is a compliment.

The problem arrives one layer down, and no model fixes it. A post in r/gtmengineering described the state of the stack that these agents read from: contact records where the economic buyer left nine months ago, the same person entered five times with slight name variations, opportunity stages that mean something different in the CRM than they do in the marketing system.

An agent pointed at a dirty warehouse will produce confident, well-formatted conclusions from bad rows, and it will do so faster than a human ever would. The failure is silent and the output is plausible. If you skip the data work, the enrichment layer will confidently tell you a company is evaluating a competitor based on a contact record from someone who left in March.

The same thread of practitioners asking whether inbound qualification can be fully automated asked the questions that actually matter and are worth reading as a checklist: how you pull enrichment data at all, whether the scoring is reliable or still messy, and whether the hallucination rate is acceptable. Those are data engineering questions wearing an AI costume. Answer them before you buy a tool.

Fix the rows first. The model is the cheap part.

Getting to that place takes more than an agent, and the order of operations matters. Three things have to exist before enrichment produces anything you would act on.

The first is an account model. Most teams have a contact model and a company model that are joined by a field that is wrong for a meaningful share of rows. Agents do not fix joins. They amplify whatever the join produces, which means a fuzzy match that quietly fuses two accounts into one produces a confident profile of a company that does not exist.

The second is a definition of intent that predates the tool. The teams getting value from this work are not asking a model to decide who is interested. They have already written down what interesting looks like, usually as a short list of behaviors, and the agent’s job is to find instances of that list. If the definition is still “someone from a target company who opened an email,” you have an automation with no thesis.

The third is a suppression list, and it is the one people skip. A prospect who already bought, a customer who already has the feature, an account that went quiet on purpose, and a contact who asked not to be contacted are four different exclusions. An agent will happily route all four into a sequence. B2B practitioners building lead systems on top of enrichment routinely list suppress and route as first-class steps alongside find and score, which tells you what actually breaks in production.

The value is not in the enrichment. It is in finally acting on signals the database has held for two years.

The software exception, and its new counterpart

The standard argument is that if you work in software, Claude can handle almost everything for you. That is not favoritism toward developers. It is a property of the output.

A software artifact is a file that compiles, runs, or fails. There is an objective check, a fast feedback loop, and a diff to review, and every one of those is a place where a wrong answer gets caught automatically instead of reaching a customer. When the deliverable is verifiable, delegation goes nearly all the way. When the deliverable is a human judgment, it stops early.

The useful question is not whether you work in software. It is how much of your output has a machine check. A financial model has one. A contract does not. A keyword map has a weak one. A hiring decision has none, which is why the same tooling that is unremarkable to an engineer is genuinely novel to a recruiter.

You can audit this in ten minutes. List the last twenty deliverables your team shipped, and for each one write down what a machine would have to be able to check to know it was wrong. If the answer is a specific artifact that already exists, the work is in the delegatable class. If the answer is a sentence about taste, accuracy, or fit, it is not. Most teams discover they are roughly half and half, and that their entire automation ambition has been aimed at the half that was never the bottleneck.

The half that is delegatable tends to be the half that is already annoying, which is exactly why it produces such visible relief. Nobody misses writing the meeting recap. Nobody misses the third rewrite of a metadata description. That is a feature, not a limitation: automating work nobody values is the correct first target precisely because the downside of getting it slightly wrong is a wasted afternoon rather than a lost customer.

Cowork is the first serious vendor answer for the non-software half, and the interesting part is that it does not pretend to close the gap. Anthropic positions it as built for non-coding knowledge work, using the same agentic approach as Claude Code. The dividing line is still there; what changed is that the non-coding side now gets the same loop, and the vendor is explicit about the division of labor in the customer quotes. One customer put it as: “Cowork helps teams do work at a scale that was hard to justify before. The human role becomes validation, refinement, and decision-making. Not repetitive rework.”

That is the correct division of labor stated by someone who is selling the product, which is worth noting for its own sake.

What it cannot do

It cannot close clients. A close is a commitment made under uncertainty, by a named person who absorbs the loss if the commitment was wrong. No model performs that act, and any demo implying otherwise is selling you a transition rather than a result.

It cannot attend meetings. A meeting is not a transcript to summarize. It is a negotiation over what gets built, what gets paid for, and who absorbs the ambiguity when requirements conflict. Presence in the room is the job itself, not a task inside it.

Note how precisely the vendor’s own sales workflow sits inside those limits. The Anthropic tutorial has an account executive researching the account before a first call, walking in already knowing who the customer is, what they are building, their spend, and their risks, then a second skill turning the call transcript into follow-up work. The agent handles everything except the conversation and the decision. That is not a limitation being worked around. That is the product boundary drawn accurately by the people who built it.

It is worth being concrete about why the boundary is structural rather than a matter of current capability. A commitment transfers risk between two parties who both have legal standing, and the party who absorbs it needs to be able to answer for it. A model has no standing, cannot be sued, cannot be blamed by a customer, and cannot be the reason a bad quarter is explained. The same is true of a negotiation, where the value comes entirely from the fact that a specific person with authority and a reputation agreed to something. That authority does not transfer to a system by improving the system.

The practical consequence is that the highest-value workflows put the model strictly upstream of the commitment. Research, brief, summarize, route, and schedule are all delegable because a person still owns what happens next. This is also why the most credible sales automation in the field looks like a very good research assistant rather than a very persuasive robot.

Which models, and what it costs

Anthropic’s own guidance is to start with Claude Opus 5.5 for most workloads, reserving Claude Fable 5.1 for demanding reasoning and long-horizon agentic work, or for cases where your evals on Opus 5.5 at higher effort still fall short. Claude Sonnet 5.5 is positioned as the best combination of speed and intelligence, and Haiku 4.5 remains the answer for high-volume classification where latency binds.

For research and enrichment workloads, Opus 5.5 and Sonnet 5.5 are the practical pair. They are the two that run everywhere Claude Code runs, which Anthropic lists as the terminal, IDE extensions, a desktop app, and the web. That matters for a business team, because it means the same model is available whether the work happens in a terminal or in a browser tab your team already has open.

The economics support running the stronger model more broadly than teams assume. Opus 5.5 performs at the level of Fable 5.1 on most work while costing 40% less to run than Opus 5, at $4 per million input tokens and $20 per million output tokens, with cached input discounted 95% to $0.20 per million. Research work re-reads the same documents across a long session, so that cache rate is the difference between a pipeline that is affordable and one that is not.

Route the work, do not pick a model

Choosing one model for everything is the most common and most expensive mistake in a deployment like this, because the tasks in a marketing or sales workflow are not equally hard.

Anthropic’s lineup sorts cleanly along the difficulty axis, and the useful move is to assign each of your three areas a tier rather than defaulting everything to the strongest model. Lead scoring and classification across a list of ten thousand rows is a high-volume, low-ambiguity problem. Haiku 4.5 is positioned as the fastest model with near-frontier intelligence, and it is the right tier for it, because the cost of a mistake is a record in the wrong sequence rather than a bad quarter.

Drafting is the middle tier. Outbound message drafts, weekly summaries, and account brief prose are where Claude Sonnet 5.5 earns its name, positioned as the best combination of speed and intelligence. This is the largest volume of the three tiers, and putting Opus behind it is spending five times the output price for a difference in the draft that a human is going to edit anyway.

Synthesis is where Opus earns its price. Turning a messy account history into a brief that changes what a seller does on the call is the task where a stronger model visibly changes the output, and it is also the smallest volume in the pipeline. One call per account, human-reviewed, is cheap at $20 per million output tokens.

The practical test for a tier assignment is simple: if a competent person could do the task in under a minute, it does not need the top model. Most workflows have far more of those minutes in them than their owners expect, and cutting them out is usually the largest single cost reduction available.

If you build connectors, one instruction from the documentation deserves to be posted on the wall: “Verify you trust each server before connecting it. Servers that fetch external content can expose you to prompt injection risk.” A connector that ingests arbitrary inbound content is an input channel and should be scoped like one.

The gap nobody warns you about

There is a version of this article that stops at the demo, and the gap between the demo and month three is where most of the loss happens.

Prompt injection is the security half of it. If you connect a server that fetches external content, you have created an input channel that an attacker can write to, and the content arriving through that channel is read by a model that then acts. Anthropic’s documentation is direct about the failure mode: “Verify you trust each server before connecting it. Servers that fetch external content can expose you to prompt injection risk.” For a marketing team scraping competitor pages or a sales team ingesting inbound email, this is not theoretical, because both of those are exactly the pattern the warning describes.

Scope the connector the way you would scope a form on your own site, which means a constrained set of actions, an audit trail, and no outbound sends triggered by content the tool read rather than content a human approved.

Hallucination is the correctness half. The model will state a fact about a competitor’s funding or a prospect’s headcount with the same tone whether it read it or inferred it. In an internal research brief that is recoverable. In a message a prospect reads under your name, it is a credibility event with a long tail. The fix is structural rather than prompt-level: require a source for every factual claim, and make “I could not find that” an acceptable output rather than a failure the model works around.

The third is quieter. Cowork is explicitly a product that consumes more usage than chat for the same task, and it is in research preview for computer use. Building a workflow that depends on all three, on a preview feature, on a per-seat consumption model nobody has modeled yet, is how a team ends up with a process that breaks on a billing change.

A thirty-day operating plan

Pick one motion. Do not start with a strategy document.

Week one, data. Pick the single highest-value question your team answers repeatedly and badly, the one where a human spends twenty minutes per instance. Export the source data to a folder the tool can read. Count the rows that are stale, duplicated, or contradictory. If more than a tenth are dirty, stop here and fix them. This is the step everyone skips and it is the one that determines whether the rest works.

Week two, one skill. Write the procedure as a repeatable document. Cowork and Claude Code both make this concrete: a skill that pulls the account brief, run against a folder and a set of connected tools. Write it the way you would write a checklist for a new hire, because that is the standard it will be held to.

Week three, shadow mode. Run it on real work and compare the output against what a competent person would have produced. Do not send anything. Measure the disagreement rate, not the impressiveness of the prose. A tool that agrees with your team 70% of the time is already valuable. One that agrees 40% of the time is a research assistant.

Week four, narrow production. Automate exactly the step that was unanimous. Keep the human on the judgment. Instrument the volume ceiling deliberately, because the limit is real and the failure mode is a quiet run of jobs that nobody looks at.

Revisit at day thirty with one number: the hours per week the team got back, and whether anyone changed how they work. If the honest answer is that everyone liked it and nobody uses it, the data step was the problem.

The economics nobody models

The subscription is the small number. The cost that surprises teams is consumption, and it arrives in two places.

The first is inference volume. Opus 5.5 at $4 per million input tokens and $20 per million output tokens is not expensive per call, and it is very expensive if a workflow re-reads the same large corpus on every run. The cached-input rate of 95% is what makes research workloads viable, and it only applies when the cache actually hits, which means stable prefixes. If your prompt puts a changing timestamp at the top, you have silently disabled the discount you built the business case on. Put the volatile part at the end.

The second is the cost of review, and it is almost always underestimated. If generated output runs at ten times the volume your team previously reviewed, and review is the binding constraint, then you have made the team slower. The right metric for a research brief is not tokens or documents, it is accepted-without-edits per hour.

A third cost sits off the books entirely: the connector work. The GitHub counts earlier are the reason. An MCP server for your CRM is a small internal engineering project with an ongoing maintenance cost and a security surface, and pricing it as a tool purchase rather than as a project is how these programs get cancelled in month four.

The honest summary

Point it at the pipeline, not at the customer. Use it to compress research, prep calls, and find intent in the data you already own. Clean the rows before you trust the reads. Accept that it sorts, drafts, enriches, and optimizes, and that a person still closes, negotiates, and attends the meeting.

Everything downstream of that is a configuration problem, and configuration problems are the good kind.