Skip to lesson

AnthropicClaude Certified Architect – Professional2026-101.6 Align solutions to business value pillars (efficiency, transformation, productivity, cost, performance SLAs)

Prove each value pillar with its own metric

Completed by the knowledge check

Learning objective

Map a solution to the value pillars it serves and to the metrics that prove each one.

Core idea

A Claude solution can generate useful responses without proving that the organization benefits. The architect must connect each claimed benefit to an observable change in the business workflow. The five value pillars in the exam guide describe different claims: efficiency, transformation, productivity, cost, and performance SLAs.

Build a value map before choosing which improvement to optimize. Each row names a pillar, the outcome it serves, a metric, its baseline and target, its measurement window, and an accountable owner. This is an architecture artifact: it settles whether an extra model call, a human gate, or a slower but more accurate path earns its cost. It adds business attribution to the acceptance requirements in 1.1.2.

How it works

Separate the five claims

Use the pillars as lenses into one workflow, rather than five scores that must all improve equally. The following distinctions are working definitions for the value map, not Claude API categories:

PillarClaim you must proveExample metric
EfficiencyDeliver the same accepted work with less effort or elapsed timeStaff minutes per completed case, including corrections
TransformationEnable a service or capability the baseline process cannot provideShare of eligible out-of-hours cases completed successfully
ProductivityProduce more useful output from the available staff capacityAccepted cases per staffed hour
CostReduce the resources spent on an accepted outcomeTotal workflow cost per completed case
Performance SLAsMeet agreed service levels whose misses carry consequencesFraction of eligible journeys meeting the agreed response deadline and quality criteria

Efficiency measures the effort removed from a defined task. Productivity measures useful output from the capacity available. Saving a reviewer ten minutes proves neither additional completed work nor a cash reduction by itself. To claim productivity, identify what the released capacity produces. To claim financial savings, identify which expense actually falls. Otherwise, report released capacity separately from realized savings.

Transformation needs a capability measure and an outcome measure. Offering support outside office hours is a capability; completing eligible requests during those hours is an outcome. Availability of the feature does not establish that people use it or benefit. If the baseline capability is absent, record that fact without dividing by zero to claim an infinite percentage improvement.

A performance commitment constrains the value the other pillars can deliver. A fast incorrect response does not improve the service promised to the user. See 1.6.3 for deriving service indicators and distinguishing a service level objective from an agreement with consequences.

Define evidence that can settle a decision

Anthropic’s success-criteria guidance calls for specific, measurable, achievable, and relevant criteria, with multidimensional evaluation when several properties matter. It names task completion, baseline comparison, response time, and uptime among its measurement approaches. Apply those principles to the business outcome, not only the model response.

Define an accepted case using observable workflow evidence. For a policy-answering service, that might require an answer supported by the approved policy, no correction by a specialist, and no repeat contact about the same unresolved issue within a stated follow-up window. These are your business definitions. A fluent answer or a successful API response is insufficient evidence for them.

For every metric, state the numerator, denominator, population, and time window. “Resolution improved to 80%” is ambiguous until you know whether the denominator includes abandoned sessions, escalations, and unsupported request categories. Keep those terminal outcomes visible; removing difficult cases after launch can manufacture an improvement.

Measure a baseline on comparable work. Match season, case complexity, operating hours, and staffing where they affect the result. Anthropic documents A/B testing against a baseline model or earlier version; apply the same discipline to the business baseline. For a pilot, use a comparable control group or state the limits of a before-and-after comparison. A coincident staffing increase can explain faster service independently of Claude.

Give trade-offs an owner

Select a primary outcome and record secondary outcomes and constraints. This prioritization is your decision convention, not a vendor requirement. The business sponsor owns the outcome target; the workflow owner validates the operational definition; finance validates the cost baseline; the evaluation owner validates the quality rubric. Each row needs a named source of evidence rather than “the dashboard.”

NIST AI RMF 1.0 provides a basis for this artifact: MAP 1.3 documents organizational goals, MAP 1.4 defines business value, and MAP 3.1 documents potential benefits. MAP 3.2 also asks for potential costs, including non-monetary costs connected to risk tolerance. The value map therefore includes constraints that a favorable average benefit must not override.

Key distinctions and trade-offs

Activity versus outcome: Messages, tokens, and sessions measure workload. They help explain capacity and spend, but an unresolved issue can produce many of them. Count accepted outcomes separately.

Capacity versus savings: Freed staff time can improve backlog clearance or service coverage without reducing payroll. A business case can defend that benefit without labeling it a cash saving.

Leading versus realized evidence: Faster draft creation can predict productivity. Accepted work per staffed hour verifies whether the prediction survives review, corrections, and user behavior.

The pillars can share evidence without sharing financial credit. A reduction in handling time can support an efficiency claim and explain productivity growth. Do not add both as independent monetary benefits when they describe the same released hours. Cost modeling belongs to 1.6.2.

Architecture / decision scenario

A retail operations team has twelve specialists answering store policy questions. It proposes a Claude assistant for a seasonal launch, with no additional headcount. All figures here are illustrative business targets.

The sponsor selects productivity as the primary outcome: increase completed store compliance reviews from twenty to thirty per week during the six-week launch period, using capacity released from policy questions at unchanged accepted-case volume. Efficiency is a supporting measure: reduce total specialist handling time from fifteen to ten minutes per accepted policy case, including review and corrections. The team reports that released time once and measures the additional reviews separately, without monetizing the same hours twice. Transformation is a separate outcome: complete 70% of eligible overnight policy requests before stores open, against a baseline process that waits for the morning shift.

Finance sets a total cost ceiling per accepted case, measured using the ledger in 1.6.2. The service owner defines a response deadline and a policy-correctness floor, using the journey method in 1.6.3. Store operations supplies closure and repeat-contact records; specialists grade a representative sample against approved policies.

A pilot doubles message volume and makes drafts faster, but completed compliance reviews stay at twenty per week because specialists rewrite the policy answers. The architect rejects the productivity claim and investigates the correction burden. A candidate that produces fewer drafts but releases enough capacity for thirty compliance reviews while maintaining policy-case volume, cost, and service constraints has stronger evidence. The choice follows the value map rather than enthusiasm about usage.

Common exam traps

  • Treating more conversations or tokens as proof of value.
  • Counting released staff capacity as a payroll saving without a spending change.
  • Adding efficiency and productivity benefits that monetize the same hours twice.
  • Claiming transformation because a feature exists without measuring successful use.
  • Comparing peak-season performance with an unrelated quiet-period baseline.
  • Accepting speed gains while dropping the quality constraint that makes the outcome useful.

What to remember

Give each pillar a distinct claim, an observable metric, a comparable baseline, and an owner. Select the outcome that decides trade-offs and retain the constraints that make it acceptable. Business value appears in accepted workflow outcomes; model activity explains how you produced them.

Knowledge check

References