Aligning Claude Solutions to Business Value Pillars

1.The frame: business value is measured per outcome, not per token

Every pillar in this objective — efficiency, transformation, productivity, cost, performance SLAs — is a claim about the business, not about the model. So the first move when aligning a solution to value is to fix the unit of measurement. Anthropic's guidance is to measure AI's cost-per-outcome rather than token consumption, and the platform guidance says the same thing in engineering terms: compare candidate designs on cost per completed task, not per token.

That reframing changes which design wins. A cheaper model that burns tokens on retries and needs human correction can produce a more expensive finished task; a frontier model on routine document processing pays for judgement the task never uses. The pillar question is therefore always "is this work hard, or merely large?" — hard work that requires judgment and reasoning justifies a capable model, high volumes of straightforward work do not.

Sources12

2.The cost pillar: separate the free wins from the trades

Cost becomes a design constraint at the moment a prototype turns into production. The useful discipline for a solution design is to sort every cost lever into two buckets, because only one of them touches the quality your business case depends on: free wins lower spend without lowering output quality, while tradeoffs exchange cost for intelligence.

Prompt caching, token hygiene, batch processing and a prompt audit sit in the first bucket; model choice, effort, output caps, an elapsed-time clock and multi-model architectures sit in the second. Ordering matters for the business case: in Anthropic's measurements prompt caching was the largest lever by a wide margin, so a design that argues about model tiers before turning on caching is optimising the smaller number. Two caveats keep the first bucket honest — batching trades latency for its discount, and context editing cost more than it saved in the run measured.

The documented remedy when costs are too high but quality is fine is also not a model swap: sweep effort down on your current model. Effort is the lever that trades intelligence for latency and cost inside one model, which makes it the cheapest thing to try before renegotiating the architecture.

One caution before any of these numbers enters a business case: the measured factors quoted above are Anthropic-internal results, and the documentation calls them directional, not guarantees, so measure on your own workload with the four-step method. The pillar you commit to in a design review is the one you measured on your own traffic.

Sources23

3.The performance SLA pillar: latency is bought, not wished for

A performance SLA turns latency into a contractual number, so the design has to name which lever buys it and what that lever costs. Three appear in the documentation. Effort is the first: it trades intelligence for latency and cost within a single model, and lower effort also means fewer and terser tool calls, which shortens agentic turns as well as single responses.

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=4096,
    messages=[
        {
            "role": "user",
            "content": "Analyze the trade-offs between microservices and monolithic architectures",
        }
    ],
    output_config={"effort": "medium"},
)

The second is fast mode, and it is the cleanest example of paying money for an SLA with no quality story attached: it runs the same model with a faster inference configuration, with no change to intelligence or capabilities, at premium pricing. Read the SLA it actually improves before promising it — speed benefits are focused on output tokens per second (OTPS), not time to first token (TTFT), so a design whose SLA is measured on first-byte latency buys nothing here.

The third lever is telling the model that time matters and showing it the elapsed time. This one moves cost and SLA together but is the only latency lever with a measured quality cost: runs took 33% to 69% less time at a 28% to 54% lower cost per task, with scores up to 1.9 points lower. That number is what a wall-clock SLA costs you in quality, and it belongs in the design document. In the other direction, batch processing trades latency for its discount, so anything under a tight SLA cannot be moved there.

SLAs also exist above the API. In a support-routing solution, the business-side latency target is an assignment time: best-in-class systems often achieve average assignment times of under 5 minutes, and near-instantaneous routing is possible with LLM implementations. That is the number a value-pillar argument commits to, not tokens per second.

Sources4526

4.The productivity pillar: output per worker, measured before and after

Productivity is the pillar most often asserted and least often instrumented. The documented way to state it is as a per-person throughput delta with a target attached. In the ticket-routing guide the claim is that improved routing should increase productivity, and the measurement is spelled out: tracking tickets resolved per agent per day or hour, aiming for a 10–20% improvement after implementing a new routing system.

Notice the shape, because it generalises to any solution you design: an existing operational counter, a per-unit denominator, and a percentage improvement the business will accept as success. Related routing targets in the same guide — routing accuracy of 90–95%, a rerouting rate below 10%, an escalation rate below 20% — are quality measures that feed the productivity number rather than replacing it.

Sources6

5.The efficiency pillar: less work per unit of outcome

Efficiency differs from cost: cost is what you pay, efficiency is how much work the system needs in order to produce one outcome. Two documented patterns express it. The first removes outcomes from the expensive path entirely — a deflection rate measures the share resolved by self-service before routing, and the guide aims for a deflection rate of 20–30%, with top performers achieving rates of 40% or higher. The downstream effect is stated as a cost figure: many organizations aim to reduce cost per ticket by 10–15% after implementing an improved routing system.

The second pattern makes the model path itself efficient by spending capability only where it is needed. Where the outputs can be checked with tests or a verifier, the documented rule is to run everything at low effort and re-run failures at high; on the coding benchmark measured, the pass rate held at about half the cost. The same logic drives the two multi-model shapes: an executor that escalates hard decisions to an advisor, and an orchestrator that delegates bulk work to lower-cost workers, so that most tokens are billed at the lower rate.

An efficiency claim needs its precondition named. The advisor shape pays off only when the advisor is priced well above the executor and actually consulted, which is why the documentation tells you to price the advisor's model alone at low effort and measure the consult rate first. The orchestrator shape is for work that exceeds one context window. Neither is a general-purpose saving.

Sources623

6.The transformation pillar: work that would not have happened otherwise

The sources do not offer a transformation framework as such; they express transformation through one question and one arithmetic. The question is what the work would have cost without AI, whether in resources, time, or never attempting the project at all. That last clause is the transformation pillar in a single phrase — value created where there was previously no project, not a percentage saved on an existing one. The documentation is explicit that this side is yours to size: the answer is specific to your business and needs, and no vendor can measure it for you.

The arithmetic makes that sizing concrete at the level of a repeatable workflow. Each skill represents a repeatable workflow, so its cost can be weighed directly against what that workflow is worth. You assign a value per run to each skill — an estimate of the employee time it replaces — and compute the net value each skill has generated from the cost per use and total uses reported in analytics. Even rough estimates carry the argument: a call-prep skill costing $0.90 per run against $20 of value returns 20x on every use.

That is the whole of what these sources support on transformation, and it is worth saying plainly rather than padding: the documented treatment is a cost-per-outcome comparison against the no-AI baseline, plus per-workflow ROI from usage analytics. Anything broader — process redesign, new product lines — is not asserted here.

Sources17

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.A cheaper model always improves the cost pillar, so pushing complex reasoning down to Haiku is a saving.Why is that wrong?

   Underpowered models burn tokens on retries and need human correction, which raises the cost of the finished task even though the per-token price fell.

   Covered in The frame: business value is measured per outcome, not per token

2. 2.Model selection is the biggest cost decision in a Claude architecture, so the design review should start there.Why is that wrong?

   In Anthropic's measurements caching was the largest lever and cache reads are routinely the largest single component of task cost, outweighing most model-choice decisions.

   Covered in The cost pillar: separate the free wins from the trades

3. 3.Fast mode is a higher-capability configuration, so buying it improves quality as well as latency.Why is that wrong?

   Fast mode is the same model weights and behaviour with a faster inference configuration; only output speed changes, and you pay a premium for it.

   Covered in The performance SLA pillar: latency is bought, not wished for

4. 4.Batch processing is a free win, so any workload can be moved there to cut the bill in half.Why is that wrong?

   The discount is paid for in latency — batch work can wait up to 24 hours — so a workload under a latency SLA cannot use it.

   Covered in The performance SLA pillar: latency is bought, not wished for

5. 5.Adding a frontier advisor above a cheaper executor is a general efficiency win.Why is that wrong?

   It only pays when the advisor's model is priced well above the executor's and is actually consulted, which you establish by pricing it alone and measuring the consult rate.

   Covered in The efficiency pillar: less work per unit of outcome

6. 6.A published Anthropic benchmark result is enough evidence for the productivity and cost pillars in your own business case.Why is that wrong?

   The measurements are Anthropic-internal and directional rather than guarantees; the documentation tells you to measure the same levers on your own workload.

   Covered in The cost pillar: separate the free wins from the trades

Practise it for real

Turn the cost and SLA pillars into two numbers for one real request, by running it at different effort levels and comparing cost per completed task rather than cost per token.

1. 1.Send your representative request with output_config={"effort": "medium"} on claude-opus-5-5, exactly as in the sample above, and record output tokens, wall-clock time and whether the answer was acceptable.

   Why: Medium is the default on Claude Opus 5.5, so this is your baseline rather than an intervention.

   You should see: One usable answer plus a baseline row: tokens, seconds, pass or fail.

2. 2.Re-send the identical request with effort set to low.

   Why: Low is the most efficient level, giving significant token savings with some capability reduction — this measures the size of both on your workload.

   You should see: Fewer output tokens and a faster response; the answer may or may not still pass.

3. 3.For any low-effort attempt that failed your check, re-run only that attempt at high effort.

   Why: This is the documented run-cheap-then-retry pattern: run everything at low effort and re-run failures at high.

   You should see: The failures recover, and only the failing subset pays the higher token bill.

4. 4.Compute total spend across the whole set divided by the number of acceptable answers, at each configuration, using the per-MTok prices in the pricing table above.

   Why: This is the pillar metric: compare on cost per completed task, not per token.

   You should see: A single figure per configuration, and often a low-plus-retry figure below the all-medium one.

5. 5.If a latency SLA applies, repeat the winning configuration with speed="fast" and the fast-mode beta header, and price it at the fast-mode rates.

   Why: Fast mode buys output tokens per second at a premium with no capability change, so the only question it raises is whether the SLA is worth the multiplier.

   You should see: Higher output tokens per second, an unchanged pass rate, and a cost per completed task you can set against the SLA's business value.