Lab 4 · Domain 4 · 16%

Workflow Integration & Solution Design

Most AI initiatives fail for a reason that has nothing to do with the model: they automate a task nobody needed done. This lab is about the work that happens before you open a chat window: finding where Claude genuinely helps, mapping the process you actually have, deciding whether to augment a step or reshape the whole thing, and then telling stakeholders the truth about both the value and the limits. Getting a good answer out of Claude is Lab 1. Knowing whether the problem was worth solving, and being honest about what you've built, is this one.

Exam objectives covered

Apply Claude to analyze requirements and use cases
Leverage Claude for research, planning, and process optimization
Use Claude to support solution design, development, and iteration
Integrate Claude into existing workflows to augment or redesign them
Communicate Claude's value and limitations to stakeholders

What you need: a Claude account (claude.ai), about 45 minutes, and one real process from your own job that you understand end to end. No installation, no code.

1. Finding the Real Use Case

The failure mode is seductive: a task is annoying, Claude can clearly do it, so you point Claude at it. But "Claude can do this" is not the same as "this is worth doing with Claude." The question is not capability. It is fit, and fit is a function of three things.

Volume. How often does this happen? High-volume tasks amortize the cost of designing a good prompt and a review step. A once-a-quarter task rarely earns that setup.
Consequence per item. If one output is wrong, how bad is it, and how reversible? A mis-tagged support ticket is cheap and fixable. A mis-stated figure in a regulatory filing is neither.
Checkability. Can a human verify the output faster than they could have produced it? Claude's judgment is only safe where a person can confirm it at a glance.

Put them together and a rule emerges. High-volume, low-consequence-per-item, judgment that can be checked is the sweet spot: that is where Claude removes real drudgery without introducing real risk. Low-volume, high-consequence, irreversible is the opposite: a poor fit, or a fit only when a human owns the final decision and Claude merely drafts an input to it.

Volume	Consequence per item	Checkable?	Verdict
High	Low	Yes	Strong fit. Claude drafts; light human review. Best ROI.
High	Medium	Yes	Good fit with review. Claude drafts every item; a human approves before it lands.
Low	Low	Yes	Weak fit. It works, but the setup rarely pays back. Do it by hand.
Any	High	Hard to check	Poor fit. Claude may assist research, but a human owns the output entirely.
Any	High	Irreversible action	Do not automate. Claude informs the decision; it never makes it.

The best use case is often unglamorous. Teams reach for the flashy, high-stakes problem because it feels important. The high-value use case is usually the boring, high-frequency one nobody brags about: triaging inbound requests, first-pass drafting, reformatting the same report every week. Volume is what turns a small per-item saving into a real one.

2. Analyzing the Requirement

Business requirements arrive vague: "We want to use AI to speed up onboarding." Before you design anything, use Claude to interrogate the requirement itself. This is the "analyze requirements and use cases" objective, and the skill is resisting the urge to build before you understand.

Paste the raw request into Claude and ask it to play skeptic: what does "speed up onboarding" actually mean, what is being assumed, who is affected, and how would anyone know it worked? A good interrogation surfaces four things the original request hid.

Hidden assumptions. "Speed up" assumes the bottleneck is time, not quality or consistency. Is it?
Edge cases. What about the onboarding of a regulated-industry client, or a non-English speaker, or someone re-joining? The request implied a typical case that may not be typical.
Stakeholders. Who touches this process today, and who would be affected by changing it, including people who never asked for the change?
Success criteria. What measurable thing must move? Days-to-productive? Support tickets in week one? If no one can name it, the project has no finish line.

Try it in Claude

Take a real, vaguely-worded request you've received, something like "can we use Claude to help with reporting?"
Paste it and prompt: "Before I design anything, interrogate this request. List the assumptions it makes, the edge cases it ignores, every stakeholder who would be affected, and the specific measurable outcomes that would tell us it succeeded. Ask me the questions you can't answer from the request alone."
Answer Claude's questions. Notice how the requirement changes shape as you do. Often the real need is narrower, or entirely different, from what was asked.
Save the sharpened requirement. It becomes the brief for everything that follows.

3. Mapping the Existing Process

You cannot redesign a process you haven't described. Before Claude touches anything, document the current workflow as it truly runs, not the idealized version in the SOP. For each step, capture the inputs, the outputs, the handoffs between people, the decision points, and who owns it.

Then classify every step into one of three kinds. This classification is the heart of the domain, because it tells you exactly where Claude belongs.

Step type	What it looks like	Claude's role
(a) Mechanical transformation	Reformatting, extracting fields, summarizing, translating tone, sorting by a stated rule. The "right" answer is largely determined by the input.	Claude helps most. Low judgment, high volume, easy to check. Hand it over with light review.
(b) Judgment under clear criteria	Classifying a ticket by severity, flagging a clause as non-standard, prioritizing a list, where the criteria are written down and defensible.	Claude helps under review. It applies the criteria at scale; a human spot-checks and owns the edge cases.
(c) Judgment requiring accountability	Approving a refund, signing off a filing, making a hiring call, committing the company to a position. Someone must be answerable for it.	Claude should not own this. It can gather and draft inputs, but a named person makes and owns the decision.

The discipline is refusing to blur (b) and (c). A step where clear criteria exist but someone still has to answer for the outcome is an accountability step, not a criteria step; the presence of a rulebook does not remove the need for a human signature. Get this wrong and you have designed a governance problem, not a workflow.

Try it in Claude

Pick a process you own that has at least five steps. Describe it to Claude exactly as it happens today: inputs, outputs, who does what, where the decisions are.
Prompt: "For each step, classify it as (a) mechanical transformation, (b) judgment under clear criteria, or (c) judgment requiring accountability. For any (c) step, name why a human must remain accountable. Then tell me which steps Claude could take on and which it should only assist."
Challenge Claude's classification where you disagree; you know the accountability landscape it can't see. The goal is a map you'd defend to your manager, not one Claude produced alone.

4. Augment vs. Redesign

Once the map exists, you face a choice that the exam names directly: do you augment the workflow or redesign it?

Augmenting drops Claude into an existing step and leaves the surrounding process intact. The shape stays the same; one box gets faster or better.
Redesigning changes the shape of the process, because the constraint that produced the old shape no longer exists. When something that used to be slow or expensive becomes cheap, the workflow that was built to ration it is now the wrong workflow.

Most people only augment, because it's safe and obvious. The higher-value move (and the harder judgment) is spotting when a constraint has dissolved and the whole process should be re-thought.

Augment, worked example. A support queue has a step where an agent writes the first response to each ticket. Drop Claude in to draft that first-pass response from the ticket text; the agent edits and sends. Same queue, same routing, same ownership; one step got faster. Nothing else moves.

Redesign, worked example. Weekly reporting exists as a batched, manual roll-up every Friday because summarizing a week of activity by hand is expensive, so you do it once a week in a big push. Once summarizing is cheap, that constraint is gone. The redesign isn't "Claude writes the Friday report faster"; it's that reporting shifts from a weekly batch to continuous synthesis: a running summary that's always current, with the Friday artifact becoming a snapshot rather than an event. The batch existed only to amortize a cost that no longer exists.

Ask what the constraint was. For any process you're tempted to just speed up, ask: "Why is it shaped this way?" If the answer is "because a step used to be slow, costly, or scarce" (and Claude removes that scarcity), you're looking at a redesign, not an augmentation. Batching, gatekeeping, and once-a-period rituals are the fingerprints of a constraint worth re-examining.

5. Iterating on the Solution

You have a use case, a map, and a design. Do not roll it out. Solution design is iterative, and the exam expects you to pilot before you scale.

Define the baseline first. Before you change anything, measure how the process performs today: hours spent, cycle time, error rate, whatever the success criterion named in step 2 was. A baseline defined after you start is a story, not a measurement.
Pilot narrow. Run the new design on one slice (one team, one ticket category, one week), not the whole operation. A narrow pilot fails cheaply and teaches quickly.
Measure against the baseline. Did the number you chose actually move? Not "does it feel faster": did cycle time drop, did error rate hold or improve?
Expand only if the measure moved. If it did, widen the slice. If it didn't, you've spent a week, not a quarter, and you learned something about the use case rather than the model.

When to escalate. Everything in this lab happens inside the Claude product with a human in the loop. The moment your redesign requires connecting Claude to internal systems, firing on automated triggers, integrating with other software, or running without a person reviewing each output, you have crossed out of Associate territory. That is design and build work for a Claude Architect or Developer. Recognizing that line (and handing off rather than improvising past it) is itself part of solution design.

6. Communicating Value AND Limitations

This is an explicit objective, it is heavily under-practiced, and it is where associates most often create problems they don't see coming. A solution you can't explain honestly is a liability, however well it works.

Quantify value in the stakeholder's units

Stakeholders do not care that something is "AI-powered." They care about the number they're measured on. Translate value into their units: hours returned per week, cycle time from three days to one, error rate from 8% to 2%. "We automated X with AI" is a feature. "This gives your team back six hours a week and cuts turnaround by half" is a benefit, and it's checkable, which is exactly why it lands.

State the limitations plainly

Every honest brief names the limits in the same breath as the value. There are three you almost always must state:

It can be confidently wrong. Claude can generate plausible, well-worded output that is factually incorrect. This is why a review step exists.
It needs human review. Say exactly where the human checkpoint is and who owns it. A design with no named reviewer is not a finished design.
Data sensitivity constrains it. What can and cannot be put into the tool is a real boundary, and stakeholders need to hear it from you before they hear it from compliance.

Above all, never oversell autonomy. An associate who promises an unreviewed, hands-off pipeline hasn't delivered a solution. They've committed the organization to a governance risk it didn't agree to take. Under-promise autonomy and over-deliver reliability, never the reverse.

The two stakeholders who need managing

Two archetypes will derail a rollout, and they pull in opposite directions.

The skeptic assumes it can't be trusted. Don't counter with enthusiasm; counter with the review step and the baseline measurement. Show them exactly where a human stays in control and hand them the number that moved. Skeptics are reassured by limits, not by promises.
The enthusiast wants to point Claude at everything tomorrow, unreviewed. This one is the more dangerous of the two, because their momentum can push a design past the accountability line before anyone notices. Slow them down with the fit matrix and the (c)-step rule: show them which steps genuinely shouldn't be automated and why.

Naming a limitation builds trust; hiding one destroys it. Counter-intuitively, the stakeholder brief that states risks plainly is the one that gets approved, because decision-makers have seen oversold tools before and they're listening for what you're not telling them. The limitation you volunteer is credibility. The one they discover later is a broken promise.

Try it in Claude

Take the pilot design you've been building through this lab. Ask Claude: "Draft a one-page brief for a stakeholder who owns this process. State the value in their units: hours, cycle time, or error rate. Then state the limitations plainly: where Claude can be wrong, where the human review step sits and who owns it, and any data-sensitivity constraint. Do not oversell autonomy."
Read it as the skeptic would. Does it show them where they stay in control? If not, prompt Claude to make the review checkpoint explicit.
Read it again as the enthusiast would. Does it clearly mark which steps must not be automated? If not, add the reasoning.
Cut every phrase that sells the technology rather than the outcome. "AI-powered," "cutting-edge," "fully automated": delete them. The brief should survive a hostile finance director reading it line by line.

7. Lab Exercise: Take a Real Process End to End

Objective: run one process from your own job through the full solution-design arc (map, classify, find the fit, design a pilot, and write the honest stakeholder brief) and come away able to defend every decision.

Map. Choose a real process you own with at least five steps. Describe it to Claude as it actually runs today: inputs, outputs, handoffs, decision points, owners.
Classify. Label each step (a) mechanical, (b) judgment under criteria, or (c) accountable judgment. Defend every (c): name who must stay answerable and why.
Identify the fit. Run the candidate steps through the volume × consequence × checkability matrix. Which step is the strongest fit? Is anything a poor fit you were tempted to automate anyway?
Decide augment or redesign. For your chosen step, ask what constraint gave the process its current shape. If Claude removes that constraint, sketch the redesign. If not, sketch the augmentation.
Design the pilot. Define the baseline metric now, before any change. Choose the narrow slice you'll pilot on and the single number that would tell you it worked.
Write the stakeholder brief. One page: value in their units, limitations stated plainly, the human review checkpoint named, autonomy not oversold. Stress-test it against both the skeptic and the enthusiast.

Step 5 is the one people skip, and it's the one that separates a solution from a hunch. If you cannot name the baseline and the number that must move, you don't yet have a use case; you have an enthusiasm. Turn it into a measurement before you build.

Check Yourself

Exam-style items. Commit to an answer before expanding.

A compliance manager asks an associate to build a workflow where Claude automatically reviews and approves expense reports against policy, with no human sign-off, to save time. The criteria are well documented. What should the associate recommend?

A. Build it as requested: the criteria are documented, so the judgment is fully defined.
B. Have Claude draft a policy-compliance assessment for each report and flag exceptions, but keep a named human as the approver who owns the sign-off.
C. Refuse the use case entirely; expense approval is not something Claude can assist with.
D. Build it, but add a note in the brief that outputs are "AI-generated" to cover the risk.

Correct: B. Approving an expense is a step that requires accountability, not merely criteria. Documented rules make it a judgment-under-criteria task Claude can apply at scale, but because someone must remain answerable for each approval (to auditors, to finance), the sign-off stays with a named human. Claude assesses and flags; the person approves and owns it.

A blurs the (b)/(c) distinction that the domain is built on; a rulebook doesn't remove the need for a signature. C over-corrects; Claude clearly can assist by drafting the assessment. D is the worst answer: a disclaimer is not a control, and shipping an unreviewed approval pipeline on a compliance-sensitive step is exactly the governance problem the associate is supposed to prevent.

An associate has four candidate processes to pilot Claude on. Which should they choose first? (1) Drafting first-pass replies to a high-volume support queue, easily reviewed. (2) Approving legal settlements over $1M. (3) Reformatting one quarterly board report. (4) Writing the CEO's annual letter to shareholders.

A. Process 1: high volume, low consequence per item, output easily checked.
B. Process 2: the highest-value decisions deserve the most help.
C. Process 3: it's simple and low-risk.
D. Process 4: the most visible output makes the best showcase.

Correct: A. The support queue hits all three fit criteria: high volume amortizes the setup, low consequence per item makes mistakes cheap and reversible, and easy checkability keeps a human safely in control. That combination gives the strongest, fastest-proving pilot.

B is a high-consequence, low-volume, hard-to-reverse decision, a poor fit that should stay human-owned. C is low-consequence but so low-volume that the setup won't pay back; do it by hand. D is high-stakes, low-volume, and irreversible in reputation terms: a showcase that fails publicly, which is the opposite of what a first pilot should risk.

An associate is presenting a Claude pilot to a skeptical finance director who has been burned by over-hyped tools before. What is the most effective way to present the value?

A. Emphasize that the solution is cutting-edge and AI-powered, and that competitors are already adopting it.
B. State the measured result in the director's units (hours saved, cycle time cut) and show exactly where the human review step keeps a person in control.
C. Downplay the limitations so the director doesn't lose confidence in the pilot.
D. Promise that once expanded, the workflow will run fully automatically with no ongoing oversight cost.

Correct: B. Skeptics are convinced by control and evidence, not enthusiasm. A concrete number in their own units is checkable, and showing where the human checkpoint sits directly answers the fear a burned skeptic actually has: that the tool will run unchecked. Value plus visible limits is what earns their trust.

A leads with exactly the hype that made them skeptical. C is dishonest and self-defeating; a discovered, hidden limitation is a broken promise that ends the relationship. D oversells autonomy, creating a governance risk and handing the skeptic the exact objection they were waiting for.

Key Takeaways

Fit, not capability, decides the use case. High-volume, low-consequence-per-item, checkable judgment is the sweet spot. Low-volume, high-consequence, irreversible is a poor fit, or a fit only with a human owning the decision.
Analyze the requirement before you build. Use Claude to surface hidden assumptions, edge cases, stakeholders, and the success criterion that must measurably move.
Map, then classify every step: mechanical transformation (Claude helps most), judgment under clear criteria (Claude helps under review), accountable judgment (Claude never owns it).
Augment a step, or redesign the process when the constraint that gave it its shape (scarcity, cost, batching) has dissolved.
Pilot narrow against a baseline defined first, and expand only if the number actually moved.
Communicate value in the stakeholder's units and state the limits plainly. Never oversell autonomy. Reassure the skeptic with control; slow the enthusiast at the accountability line.