Home › Study guides › CCAR-P › Domain 1 › Lesson 1.6

CCAR-P · Domain 1 · 17% of the exam · Lesson 1.6 · 21 min read

Aligning a Claude solution to business value pillars

How to map a Claude solution to efficiency, transformation, productivity, cost and SLA pillars, with baselines, cost per outcome and stop rules.

Written against objective 1.6 of the official CCAR-P exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.

1.6.1 Why a working assistant is not yet a business case

Merrow Vale University's student-recruitment office answers about 52,000 enquiries in each admissions cycle: entry requirements, fees, deadlines, visas, accommodation. Fourteen advisers handle them by email and phone. In the weeks after offers go out, the inbox backs up and the median email reply stretches from one day to three. Four in ten enquiries arrive outside office hours, many from applicants abroad who wait overnight for an answer an adviser could give in two minutes. Fintan, the director of student recruitment, asks for "an AI assistant for enquiries".

Lucinda, the solution architect, knows the prototype is the easy part: given the prospectus and fees pages, Claude answers questions about them well. The hard question comes six months later, when the university's leadership asks what the assistant delivered. A pilot dashboard showing 200,000 messages and a monthly API bill does not answer it. Nobody wrote down what the assistant was meant to change, from what starting point, or what a good result should cost.

Answering that question is architecture work, and it starts before the design. Business value pillars are the kinds of outcome a solution is judged on: efficiency, transformation, productivity, cost, and performance commitments written as service level agreements (SLAs). Every benefit the assistant claims belongs to a pillar, and it needs a key performance indicator (KPI), a baseline (where that number stands today) and a target.

1.6.2 Five pillars, five different promises

Here is the question that trips people up: are efficiency and productivity not the same thing, and is cost not efficiency in dollars? They are related, but each promises something different. A business case that blurs them ends up counting one saved hour three times, and the first sceptical reviewer finds it.

Memorise the five promises in the middle column; the KPIs only show how one solution turns each promise into a number.

Efficiency takes effort OUT of a fixed amount of work. Productivity puts the freed capacity INTO more output that matters. Think of a dishwasher: it makes the washing-up efficient, but whether the household eats better depends on what the freed half hour is spent on. If Merrow Vale's advisers save ten hours a week and spend them on the same backlog, that is efficiency. If they spend them calling offer holders, it is productivity, and only that version moves enrolments.

Transformation is different again, because its baseline is often zero: nobody at Merrow Vale answers enquiries at 3 a.m. today, in any language. Anthropic's customer support guide gives round-the-clock availability and conversation in many languages as reasons to use Claude for support. For Merrow Vale those are transformation claims. You measure them in two steps: first whether the new service is used, then whether it produced the outcome it was built for, such as applications from enquirers abroad.

Performance SLAs are commitments rather than improvements: a line anyone can check, stated as a percentile over a window, such as "95% of first answers within 60 seconds each week". Anthropic's guidance on success criteria lists response time and uptime among its operational metrics. Put quality in the SLA, not only speed. An assistant that answers in two seconds with the wrong deadline has kept the promise that mattered least.

1.6.3 One primary pillar, and a baseline for every KPI

A business case that claims all five pillars with equal weight cannot settle an argument. Suppose the finance partner wants the cheapest model and Fintan wants more enquiries resolved. Which one wins? The fix is to name a primary pillar: the outcome the solution exists to move, and the tiebreaker when pillars conflict. Secondary pillars are measured and reported. Guardrails are limits the solution must stay within, such as a cost ceiling or a complaint rate no worse than today's.

Lucinda asks Fintan what would make the assistant worth building if nothing else improved. His answer: advisers spending the peak weeks calling offer holders instead of retyping deadline answers. So productivity is primary, and that has design consequences. Say a more capable model raises token spend but resolves more enquiries without an adviser. It wins, as long as cost per resolved enquiry stays under its ceiling; if cost were primary, the same evidence could point the other way. That is how an architect justifies a choice: it moves the primary pillar and stays within every guardrail.

Every KPI then needs a baseline measured before launch, and a target. Anthropic's success-criteria guidance asks for criteria that are specific, measurable, achievable and relevant, and its worked example states the target as an improvement over the current baseline. Where last cycle's data is missing, measure before launch: Merrow Vale ran a two-week sample of how advisers spend their time. Compare like with like, too. Admissions is seasonal, so the baseline for the post-offer peak is last year's post-offer peak, not a quiet week in summer. Lucinda's value map puts it on one page; note the label on each line and the source of each baseline.

PRIMARY, Productivity: offer-holder calls per adviser per week in the six post-offer weeks. Baseline 20 (call logs, last cycle). Target 45. Leading indicator: share of adviser time on routine enquiries, baseline 61% (two-week time sample), target 25%.
SECONDARY, Performance SLA: chat available 99.5% of each month, with an adviser contact form when it is not. 95% of first chat answers within 60 seconds. Fee and deadline answers correct in 99% of a weekly sample of 200 conversations. Baseline: median first email reply 26 hours.
SECONDARY, Transformation: 80% of out-of-hours enquiries answered the same night, in the enquirer's language. Baseline 0%. Outcome check: application rate of out-of-hours enquirers against last cycle.
SECONDARY, Efficiency: adviser minutes per escalated enquiry. Baseline 9. Target 5, using the assistant's handoff summary.
GUARDRAIL, Cost: cost per resolved enquiry below $2.00, against $6.30 for an adviser-handled enquiry last cycle.
GUARDRAIL, Quality: complaints about wrong information no higher than last cycle's 14.

The easiest numbers to collect are vanity metrics that count activity: messages handled, conversations started, active users. They rise whether the assistant helps or not; a student who asks the same question four times because the answers were vague produces four messages. "Hours saved" estimates are the subtle version: conversations multiplied by an adviser's minutes per enquiry assume that every chat replaced an adviser's work, failed chats included.

Outcome metrics count results: enquiries resolved without an adviser, adviser hours moved to calls, applications from out-of-hours enquirers. Anthropic's support guide counts a deflection only when the chatbot handled the enquiry successfully without human intervention, so a student who gave up is not one. Merrow Vale defines resolved precisely: the enquiry never reached an adviser, and the same person did not raise the same topic within seven days.

1.6.4 Cost per resolved enquiry, not per call

Then comes the question every finance office asks: what does the assistant cost? The tempting answer is the token bill, because it is the number Anthropic sends. The pricing page even works an example: about $37 to process 10,000 support tickets on Claude Haiku 4.5. That is a real token figure, and it leaves out most of what the solution costs.

A per-outcome cost has three kinds of input. Tokens and platform charges come first. Input and output tokens are billed per million at different rates, and everything the model reads counts as input: the conversation history resent each turn, the retrieved pages, the tool definitions. Server-side tools add their own charges; web search, for example, is billed per search. Build and run costs follow: the integration with the enquiry system and the content store, hosting, logging, monitoring and test-suite upkeep. Human time is the line most often forgotten: updating fee and deadline content, reviewing sampled transcripts, and correcting what the assistant got wrong.

Then divide by successful outcomes, not by calls. A conversation that failed still billed its tokens, and then an adviser handled it anyway. Anthropic's cost guide makes the same point about comparing models: a failed task bills its tokens, then the retry, then whatever the failure costs downstream. Anthropic's article on building agents even notes companies that charge for support agents only per successful resolution. Here is Lucinda's projection for a peak month.

Admissions-enquiry assistant, one peak month (projected from the pilot).
Volume: 9,000 conversations, 36,000 model calls, 6,300 resolved without an adviser (70%).
Tokens for all 9,000 conversations, including the 2,700 that reached an adviser: $560.
Integration build of $48,000 spread over 24 months: $2,000. Hosting, logging and monitoring: $600.
Content upkeep, 20 adviser hours at $42: $840. Transcript review and corrections, 10 hours at $42: $420.
Total $4,420. Tokens per model call: $0.016. Total per resolved enquiry: $0.70.
Baseline: an adviser-handled enquiry, 9 minutes at $42 an hour: $6.30.

The per-call figure is more than 40 times smaller than the per-outcome one, and it is the wrong one to put in a business case. Tokens are about an eighth of the total here; the rest is people and plumbing. The definition of success moves the answer as well. If the seven-day repeat-contact check cut the resolved share from 70% to 55%, the cost per resolved enquiry would rise to $0.89 with no change to the bill.

1.6.5 Which use case first: value against feasibility

Once the enquiry assistant has a business case, other ideas arrive. Fintan's team now has five candidates, the assistant among them, and budget for one or two. The tempting ways to choose are by enthusiasm or by the most impressive design, and both pick badly. Rank candidates on two axes instead. Value is which pillar moves, by how much and at what volume, tied to a goal the organisation already has. Feasibility asks four questions. Does the content or data exist? How hard is the integration? Can you tell a right answer from a wrong one? And what does an error cost?

Notice the last row: the most sophisticated design scored lowest. Anthropic's advice on building agents is to find the simplest solution possible and add complexity only when needed, because agentic systems often trade latency and cost for better task performance. A use case with no pillar and no measurable KPI is a technology looking for a problem.

Checkability links feasibility to value. If you cannot say what a correct output looks like, you cannot build an eval: a set of test inputs with known good answers that you score the solution against. Without one you cannot measure a quality KPI either, so you can never show the value you claimed. That is why the enquiry assistant goes first and scholarship ranking waits.

1.6.6 After launch: continue, fix, pivot or stop

A business case is a forecast, and the first intake tests it. Two failures are common: nobody looks again, so the use case keeps its budget by momentum, or someone kills it on the first week's noisy data, before the peak. The remedy for both is to agree before launch when the review happens, which numbers it reads, and what each result triggers.

The numbers come from two places. Token spend comes from the Usage and Cost pages in the Claude Console, or from the Usage and Cost Admin API. Give each use case its own workspace (the Console's way of separating one project's API keys, usage and spend), and the cost report can split daily spend by workspace. Outcome data (resolved, escalated, repeat contact) come from your own conversation logs and enquiry system; Anthropic's reports know tokens and dollars, not whether a student got an answer. Add the build, run and people costs, divide by the week's resolutions, and you have a current cost per resolved enquiry.

Merrow Vale's review after the first intake reads the value map line by line. Offer-holder calls rose from 20 to 34 per adviser per week, short of 45 but moving, as the routine share of adviser time fell from 61% to 38%. The speed, availability and out-of-hours targets were met, and cost per resolved enquiry came to $0.82. The miss was quality: fee and deadline answers were right in 98.2% of sampled conversations, against 99%. Most errors traced to a scholarship fee that changed mid-cycle and never reached the assistant's content.

Merrow Vale's result is a fix, not a stop. The primary pillar is moving, and the quality miss has a diagnosable cause: there was no process for pushing fee changes into the assistant's content. Lucinda adds that process, routes scholarship-fee questions to advisers until the weekly sample is back above 99%, and sets a re-review date. Had self-service resolution stalled at 30% while advisers praised its handoff summaries, the right call would have been a pivot: an adviser-assist tool, re-baselined and measured under efficiency and productivity.

1.6.7 The exam traps

• ✗ Reporting activity such as messages handled or conversations started as value. ✓ Report outcomes tied to a pillar, such as resolved enquiries. Activity rises even when answers fail.
• ✗ Setting targets without a baseline ("cut response times"). ✓ Measure a baseline from a comparable period first, and state the target against it; without one, nothing can be shown to improve.
• ✗ Presenting the cost per token or per API call. ✓ Present cost per successful outcome, counting failed attempts, build and run costs, and human review time.
• ✗ Claiming every pillar with equal weight. ✓ Name one primary pillar to settle trade-offs, report the secondary pillars, and set guardrails such as a cost ceiling.
• ✗ Choosing the first use case by ambition, such as a multi-agent system with no KPI. ✓ Rank candidates on value and feasibility, checkability included, and start with the simplest design that meets the need.
• ✗ Keeping a use case alive by momentum, or killing it on a week of early data. ✓ Agree the review date, the numbers and the continue, fix, pivot or stop rules before launch.

1.6.8 Put it together: build the business case for one use case

You now have every piece of a business case: pillars, KPIs with baselines and targets, cost per outcome, use-case ranking and the post-launch review. The quickest way to make it stick is to build a small one, run realistic enquiries through Claude, and watch one broken ingredient move the numbers.

This business case feeds the rest of the lifecycle. Defining evaluation metrics (4.1) turns the quality lines of your value map into tests. Token cost optimisation (4.5) is how you shrink the token line of the cost per resolved enquiry. Managing stakeholder expectations, SLAs included (6.3), is how the SLA line becomes a commitment everyone agrees to. Supporting lifecycle phases (6.5) turns the continue, fix, pivot or stop review into a routine.

Key takeaways

• ✓ A Claude solution is worth what it measurably changes: a pillar, a KPI with a baseline and target, a cost per outcome and a review agreed before launch.
• ✓ The five pillars are distinct promises: less effort, more output per person, a new capability, a lower unit cost, and committed speed, availability and quality.
• ✓ One primary pillar settles trade-offs, secondary pillars are reported, and guardrails set limits the solution must stay within.
• ✓ Every KPI counts outcomes, not activity, against a baseline from a comparable period before launch.
• ✓ Cost is measured per successful outcome: tokens for every attempt, build and run costs and human time, divided by what the business counts as success.
• ✓ Use cases are ranked on value and feasibility, and one without a pillar or a checkable KPI waits, however advanced its design.
• ✓ After launch, rules agreed in advance decide whether to continue, fix, pivot or stop.

Check your understanding

4 questions written for this lesson, then one from the CCAR-P question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.

Sources

• Define success criteria and build evaluations
• Customer support agent
• Pricing
• Optimizing for cost and intelligence
• Usage and Cost API
• Building effective agents
• The CCAR-P exam guide, summarised