CCAR-P 1.1 — From business problem to solution

From request to Claude solution

Restate the problemwho, what work, what outcome today
Find the task shapeclassify, extract, draft, answer, act
Set success criteriameasurable, with a baseline
Simplest solutionsingle call → workflow → agent
Pilot and evaluateagainst the criteria, on real cases

Misses the targets → revisit the task shape before adding complexity

The technology choice is the fourth step, not the first. If the evaluation misses the targets, go back and rethink the task shape before adding complexity.

Restate the request as a problem

Requests arrive as solutions: “build us an agent”, “put AI search on our intranet”, “automate claims”. Before anything else, rewrite the request as a problem statement a finance director could agree with. It has four parts: who does the work today, what the work is (the actual inputs and outputs), what it costs now (time, money, errors, missed deadlines), and what better looks like in a number. Structured discovery itself is covered in 6.1; here the point is that the architecture follows from this statement and not from the request.

The same request, restated

Stakeholder request

We want an AI chatbot for our
complaints team.

It should be smart and save time.

Problem statement

Complaints handlers (40 FTE) read
~3,000 emails a week and route each
to one of 14 teams by hand.

Today: median 2 days to assign;
18% are re-routed at least once;
regulatory deadlines are missed.

Target: assign within 1 hour,
re-routing under 5%, no drop in
complaint-handling quality.

The restated version names the users, the unit of work, the baseline and the target. Every design decision after this can be tested against it.

Is this a job for Claude at all?

Language models are strongest where the input is unstructured and the judgement is semantic: reading an email and deciding what it is about, pulling fields out of an inconsistent PDF, summarising a long record, drafting a reply from policy, answering questions over a document set. They are the wrong primary tool for exact arithmetic, deterministic rule execution or looking up a value by key — conventional code does those more cheaply, more predictably and more auditably. Most good enterprise designs use both: code for the deterministic parts, Claude for the reading and judgement in between.

Anthropic’s ticket-routing guide gives a useful test for when Claude beats a traditionally trained classifier: little labelled training data, categories that change over time, complex unstructured text, rules that need semantic understanding, a need for interpretable reasoning, frequent edge cases, and multilingual input without a model per language. The more of those that apply, the stronger the case.

Task shape in the business problem	What Claude does	Typical building blocks
Sort incoming work (emails, tickets, claims)	Classification with a stated reason	Single call, structured output, routing code
Get data out of messy documents	Extraction to a fixed schema	Document input, schema validation, human spot-check
Answer questions over policies or records	Grounded answering with citations	Retrieval, citations, refusal when not found
Produce a first draft for a person	Drafting from sources and templates	Retrieval, template, human approval
Complete a multi-step task in systems	Deciding and acting through tools	Tools, permissions, workflow or agent loop

Where does the work belong?

What does the core step need?

Exact rules, maths or lookups
Conventional codeno model in this step
Read, judge or write once
One Claude callplus retrieval and tools as needed
Several known steps
Workflowfixed code path, Claude per step
Steps unknown in advance
Agentmodel chooses tools in a loop

Start at the top branch that fits. Workflows and agents are for when a single call genuinely cannot do the job; pattern choice is covered in 1.3.

Turn “better” into success criteria

A solution is only as good as the definition of success it was designed against. Claude’s documentation asks for criteria that are specific, measurable, achievable and relevant, and warns that most use cases need several dimensions at once. “Safe outputs” is not a criterion; “fewer than 0.1% of outputs in 10,000 trials flagged by the content filter” is. For a routing solution the guide’s example targets are 95% routing accuracy and a 50% cut in cost per classification, measured alongside operational metrics such as time-to-assignment and re-routing rate.

Task fidelity — how often the core output is right (routing accuracy, extraction field accuracy).
Consistency — the same kind of input gets the same kind of answer.
Latency — how fast, stated against the business process (a live chat is not a nightly batch).
Cost — per unit of work, compared with today’s cost per unit.
Safety and privacy — what must never appear in an output, and how often you check.
Business outcome — the number the sponsor cares about: backlog, deadlines met, handle time, satisfaction.

Write the business outcome down with a baseline. Without “today it takes two days” you cannot claim “now it takes an hour”, and the value case in 1.6 has nothing to stand on. Metric design and evaluation datasets are covered in 4.1 and 4.2.

Worked example · A regional bank’s “complaints chatbot”

The head of customer operations at a regional bank asks for a chatbot that talks to complaining customers. Complaints arrive by email and web form; regulated response deadlines are being missed.

Restate. Discovery shows the delay is not in writing replies but in triage: handlers read every complaint to decide which of 14 teams owns it, and 18% bounce between teams. A customer-facing chatbot would not touch that queue.
Task shape. The core step is classification of unstructured text, plus extracting a few fields (account type, product, whether the customer mentions vulnerability). Categories change when products change, and there is little labelled history — both point to Claude over a trained classifier.
Criteria. Routing accuracy of at least 95% on a held-out set of past complaints; time-to-assignment under one hour; every complaint flagged as possibly involving a vulnerable customer goes to a person, whatever the model says.
Simplest solution. One Claude call per complaint returns a team, the extracted fields and a short reason, validated against a schema. Routing code does the rest. The routing guide suggests starting with the fastest, lowest-cost Haiku-class model and moving up to Sonnet only if categories grow large or need deep expertise.
Pilot. Run it in parallel with the human triage for four weeks, compare decisions, then switch over team by team.

Takeaway: The sponsor asked for a chatbot; the problem was a classification queue. The solution is smaller, cheaper, easier to govern and aimed at the number that was actually hurting — missed deadlines.

Choose the first use case carefully

Enterprises usually bring a list of ideas, not one. Anthropic’s enterprise guide advises against starting with the biggest opportunity. A good first use case plays to LLM strengths (unstructured data, classification, transformation), has a measurable business impact and a visible return, carries low operational and security risk, has abundant accessible data with the right to use it, can run alongside the existing process without disruption, and can be repeated elsewhere once it works.

Screening a candidate: hospital discharge letters

Passes: Plays to LLM strengthssummarising long clinical notes
Passes: Measurable impactclinician minutes per discharge
Missing: Baseline recordedtime today not yet measured
Check: Low risk if wrongclinical content — needs sign-off
Passes: Data accessible and permittedEHR notes, approved for this use
Passes: Runs beside current processdraft only; doctor still signs

A strong candidate with one gap and one risk to design for. “Missing” items are the questions to take back to the sponsor, not reasons to stop.

Worked example · A hospital network wants to “reduce paperwork”

A hospital network’s chief medical officer says doctors spend too long on paperwork and asks what Claude can do. There are a dozen candidate ideas, from coding diagnoses for billing to an autonomous scheduling agent.

Narrow. Shadowing two wards shows discharge letters take the most clinician time and are written from notes that already exist in the record. That is a summarisation task — a core LLM strength.
Frame the risk honestly. A wrong discharge letter can harm a patient, so the design keeps the doctor as the author: Claude drafts, the doctor edits and signs. Human-in-the-loop design is covered in 5.3; regulatory obligations such as HIPAA in 5.4.
Criteria. Minutes per letter (baseline to be measured first), the share of drafts signed with only minor edits, zero drafts containing facts not present in the source notes on a reviewed sample, and doctor satisfaction.
Solution. One Claude call per discharge, given the relevant notes and the hospital’s letter template, instructed to use only the supplied notes. No tools, no agent: the inputs are known and the output is a single document.
Defer. The scheduling agent is parked. It touches many systems, acts on its own and has no baseline — a poor first project, even if it is a good third one.

Takeaway: Pick the use case where the task suits Claude, the value is measurable and a person still owns the outcome. Ambition comes after the first proven win.

Real deployments tend to look like this — several narrow, well-defined workflows rather than one general assistant. Newfront, an insurance brokerage, describes using Claude for three separate jobs: an employee benefits assistant, contract review, and extracting structured data from inconsistent loss-run PDFs. It reports a 60% cost reduction in document processing. Each is a clear task shape with its own measure of success.

Traps the wrong answers are built from

Tempting but wrong	Do this instead
Building the solution the stakeholder named (“a chatbot”) without restating the problem	Rewrite the request as who, what work, what it costs today and what better looks like.
Using Claude for exact calculation, rule execution or key lookups	Keep deterministic steps in code and use Claude for the reading and judgement between them.
Starting with an autonomous or multi-agent design	Start with the simplest solution — often one call with retrieval — and add complexity only when measurements justify it.
Success defined as “better” or “smarter”	Set specific, measurable criteria across accuracy, latency, cost, safety and the business outcome, with a baseline.
Choosing the biggest, riskiest idea as the first project	Pilot a contained, measurable, low-risk use case that can run beside the current process.

You should now be able to

Restate a stakeholder’s solution request as a problem statement with users, unit of work, baseline and target.
Judge whether a task suits a language model, conventional code or a mix of both.
Map a business task to a Claude task shape — classify, extract, answer, draft or act — and its building blocks.
Write multidimensional, measurable success criteria that include the business outcome.
Screen and rank candidate use cases for a first pilot.

From business problem to solution