Claude for Business

The real problem in a small agency

In a team of three to twenty people, talent is rarely what is missing. Written process is. The audit the client pays well for gets done well because a specific person does it, and that person has been doing it for four years. She knows what to look at first, she knows which questions to ask the client before starting, she knows which finding is not worth reporting because it creates noise, and she knows how to phrase the recommendation so the client approves it instead of arguing with it. None of that is written down anywhere. It is in her head.

This produces three symptoms that anyone running a small company will recognise. The first is inconsistent quality: the same service, sold at the same price, comes out different depending on who executes it that week. The second is that onboarding is genuinely expensive, not in salary but in senior time, which stops being billable while someone explains the same thing for the third time. The third is that the business does not scale: doing twice the work takes twice the people, and every new person takes months to reach the level of the last one.

The conclusion people reach too quickly is that the answer is better documentation. Partly it is, but procedure manuals have a well known problem: nobody reads them. They get written once, filed in a shared folder, and go stale in three months. The document exists but it changes nobody's behaviour, because reading it costs more than asking the colleague sitting next to you.

This is where Claude changes the arithmetic, and it is worth being precise about why. It is not a way to cut headcount. It is a way to externalise procedure: to turn tacit knowledge into something that executes rather than something that gets archived. The difference between a manual and a system is that the system gets used because using it is the fastest path, not the most virtuous one.

From SOP to Skill: procedure that executes

A Skill is a folder with a SKILL.md file that Claude loads on demand when the task calls for it. The mechanism matters: only the description sits in context, one line saying what the Skill covers, and the full file is read only when the work requires it. This is progressive disclosure, and it solves the classic manual problem, which is that the whole manual weighs on you even when you only need one page.

For an agency this translates into a simple rule: one Skill per recurring deliverable. Not a generic "how we work" Skill, but one for every thing you sell more than three times. The technical audit, the monthly results report, the creative brief, the commercial proposal, the project closeout. Each with its structure, its quality criteria, its examples of what gets approved and what gets sent back.

Writing the first one is work, and that work is the point. The approach that works is to sit with the person who does that deliverable well, take the last one they shipped, and ask them why on every decision. Why that order. Why that data point was left out. What they would have done differently if the client were in another sector. That conversation is the asset. The Skill is just the format it gets stored in.

The outcome you are aiming at is concrete: the tenth client audit should look like the first. Not identical, because every client is different, but the same structure, the same depth, the same criteria. When that happens, the deliverable stops depending on who is free that week, and the conversation with the team shifts from "do it the way Marta does it" to "follow the system and tell me where it does not fit".

There is a side effect that usually surprises people: the Skill turns out to be the best onboarding material you have. Someone joining the team does not read a forty page manual. They run the real process from day one, with the system holding the structure, and they learn by seeing what gets corrected. Time to first useful delivery drops from months to weeks, and senior time stops going into repeating itself.

MCP: connecting Claude to what the business already runs on

The second bottleneck is not judgement, it is access to information. The real work of an agency lives scattered: briefs in Drive, code in GitHub, decisions in Slack, client data in a database or a spreadsheet somebody maintains by hand. The usual way of working with a model is copy and paste between tabs, which works once and is unsustainable as a process.

MCP, the Model Context Protocol, is the open standard that solves this. It connects Claude to external tools and data sources, with the public specification at modelcontextprotocol.io. The practical consequence is that the system stops working on whatever someone remembered to paste in and starts working on the actual source.

The right way to think about it is as an integration layer, not a collection of connectors. The question is not "what integrations does it have", it is "what process stops needing human intervention once the system can read this". If the monthly report needs data from three places, connecting all three turns four hours of gathering into a twenty minute review. If the creative brief depends on finding the right brand document in Drive, connecting Drive removes the step where somebody uses last year's version.

And here comes the other technical fact that changes how you design processes: Fable, Opus and Sonnet work with a one million token context window, roughly a month of a company's documents in a single session. Haiku 4.5 works with 200K, which is plenty for a discrete task but not for a full review. That means checking the consistency of everything delivered to a client over a quarter stops being a project and becomes a task.

Cost is an operations discipline

Putting everything on the most expensive model is comfortable and it is a management failure. The gap between Haiku and Fable is ten times on input and ten times on output. In an agency processing volume, that gap is not an invoice detail: it is the difference between a system that pays for itself and one you have to justify every month to the partner who signs.

The routing rule that works is straightforward. Haiku 4.5 for anything high volume and low ambiguity: classifying tickets, pulling data out of invoices, tagging content, checking format. Sonnet 5 for the bulk of the work, which in an agency means writing, analysis, review and most deliverables. Opus 5 for the hard calls: designing a solution, diagnosing something that does not add up, agentic work with many chained steps. Fable 5 when the problem genuinely earns it and the cost was planned, not when somebody picked it by default from a dropdown.

What makes this a discipline rather than a good intention is measuring it. A process that runs a hundred times a month has a unit cost, and that unit cost should be written next to the process, the same way the time it saves is. When both numbers are visible, the conversation about what to automate stops being ideological. And when something runs over budget, the right question is not whether the system works, but whether that task is running on the tier it belongs on.

Where the human stays in the loop

There are three categories where human review is not optional, and they are worth writing down before the first borderline case shows up.

1. Anything the client sees. A deliverable, an email, a deck, a reply in a shared channel. The system can produce the whole thing, but someone on the team signs off before it leaves. A small agency's reputation is built slowly and broken in one send.
2. Anything contractual. Proposals with pricing, project scope, terms, deadlines, anything that creates an obligation. Drafting is a task. Committing the company is a decision, and decisions are made by a person with a name.
3. Anything irreversible. Publishing, deploying, sending to a list, deleting, changing production data, moving money. The operating rule is that if undoing it costs more than reviewing it, you review it.

Outside those three, autonomy is healthy and necessary: if everything needs approval, the system just moves the bottleneck somewhere else. The goal is not more supervision, it is supervision where it counts.

Data and confidentiality

Before putting client material into any model, from any provider, there are questions you answer once and write down. What the contract with that client says about subcontracting and data handling. If there is an NDA, what its scope is. Which information is identifying and whether the task actually needs it, because often it does not and it can be stripped. Who on the team is allowed to connect which system, because MCP widens access and access has to be governed the same way a shared folder is.

One concrete, verifiable point that affects the model decision: Fable 5 requires 30 day data retention and is not available under zero retention. If the company has clients who require zero retention by contract or by sector, that work cannot run on Fable, and that is not a technical footnote but an operating constraint you need to know before designing the process, not after selling it.

The sensible posture for a small agency is to classify material into three tiers: public, internal, and client confidential. Define what can be processed at each tier and with which model. And revisit it when a new client arrives with different requirements, which is exactly when nobody remembers to revisit it.

A staged rollout

The most common mistake is starting with everything at once. The approach that works is to start with one process, measured, and touch nothing else until that one is working.

The process you pick first should meet three conditions: it repeats at least several times a month, it currently consumes expensive people's time, and its quality is easy to judge. A monthly report meets all three. A strategic commercial proposal does not, because it is too variable and too loaded with implicit context to be the first case.

Before you start you need a baseline, and this is the part almost nobody does. How long that process takes today, actually measured rather than estimated. How many correction rounds it averages before it ships. How many times a month it runs. Without those three numbers, any later claim about improvement is an opinion.

During the first weeks you measure the same three, plus two new ones: cost per run, and the share of outputs that needed substantive correction rather than stylistic correction. Working means time per run drops steadily, substantive corrections drop as the Skill gets refined, and cost per run is a clear fraction of the hourly value it replaces. If those three curves do not move in four to six weeks, the problem is not the model: it is that the process was less clear than it looked, and that is useful information too.

Only when the first process is stable do you move to the second, and the second costs less because the criteria already exist, the connections are already in place, and the data classification is already done. The third costs less again. That is the pattern: the investment is almost all up front, and what you build is not a tool but a way of working that survives someone leaving.