Workflow Integration & Solution Design

Workflow Integration and Solution Design is 16 percent of the exam, about ten of the sixty items, and the second-heaviest domain. It tests whether you can look at a process a team already runs and say precisely where Claude belongs in it, and where it does not.

The questions rarely ask what Claude can do. They ask what you should change. A scenario hands you a team, a process with several steps, a complaint about time or quality, and four plausible interventions. The credited answer nearly always targets one high-volume, low-judgment step, keeps a named person accountable for the decision at the end, and can be compared against how the work performed before the change. Options that sound ambitious — automate the whole process, remove the review gate, train everyone at once — are the distractors.

The idea that unlocks the domain: you are redesigning a handoff, not installing a tool. Claude produces a first version; a person owns the outcome. Design the point where that handoff happens, prove the saving, then spread it.

• Map the process as it actually runs before proposing anything. The step people complain about loudest is rarely the step that consumes the most hours.

• Best candidates: high volume, repetitive, text in and text out, tolerant of a rough first draft, cheap to check. Summarizing, drafting, reformatting, classifying, first-pass research.

• Worst candidates: rare one-offs, relationship and negotiation work, legally binding decisions, and anything that depends on context living only in someone's head.

• Automate the drafting, never the deciding. Claude gets the team to a first version; a named person signs the final one.

• Put the handoff at the last point where a mistake is still cheap — before the thing is sent, filed, paid, or published.

• Reversibility test: if the output goes straight to a customer, a regulator, or a ledger, a human review gate is mandatory, not optional.

• Sequence multi-step work in stages with a checkable output at each stage, rather than one instruction that is supposed to produce the finished artifact.

• One step, one team, real inputs. Pilot narrow and run alongside the existing process until the results hold.

• Take a baseline first: how long the step takes today, how often it is reworked, how many errors escape. No baseline, no provable saving.

• Measure the full cycle, including review and rework — not the time to generate the draft.

• Write the workflow down with the standing instruction and example inputs and outputs. A workflow that lives in one person's chat history is not a workflow.

• Name an owner and a re-test trigger. When the input format, the template, the policy, or the people change, the workflow gets re-checked.

• Tempting: automate the process end to end. Credited: automate one step and keep the review gate. Whole-process automation is the classic distractor.

• Aiming at the complaint, not the cost. The noisy step and the expensive step are usually different ones. Follow the hours.

• Piloting with the enthusiast. Results produced by the person who designed the prompt do not survive being handed to a colleague. Re-run with a typical user before you claim success.

• No baseline. If nobody timed the old way, every claimed saving is an opinion.

• Counting drafting time only. A draft produced in one minute that takes thirty to fix saved nothing. Review and rework are part of the number.

• Review theater. An approval step nobody has time to do properly is not a control. If reviewing takes as long as doing, narrow what Claude does or move the handoff.

• Treating rollout as training. Adoption comes from putting the workflow where the work already happens, with a written instruction and an owner — not from a one-hour session.

• Leaving it undocumented, so the workflow dies the week its author changes role.

• Prompting harder at a broken process. If the input is not written down anywhere, the rule is contested, or nobody can verify the output, Claude is the wrong tool and the honest answer is to say so.

• Ignoring drift. New form, new template, new policy, new team member — the workflow that worked in March quietly stops working in September.

• Tracking speed but not quality. Report error and rework rate next to time saved, or you will optimize the process into worse output.

• Designing for the power user. Build for the median person on the team; the workflow has to be shorter than the manual way on their first attempt.

ADOPTS — the order in which you design a workflow people will actually use.

• A — Anchor. Map the process as it runs today, step by step, before you change anything.

• D — Diagnose. Find the step that is high volume, text-based, and low judgment. Follow the hours, not the complaints.

• O — Own. Set the split: what Claude drafts, what a person decides, and exactly where the handoff sits.

• P — Pilot. One step, one team, real inputs, running beside the existing process — with a typical user, not the enthusiast.

• T — Track. Compare full cycle time, rework, and error rate against the baseline you took before you started.

• S — Sustain. Write it down, name an owner, and re-test when the inputs, templates, policy, or people change.

If you cannot complete a letter, that is your answer: no anchor means you are guessing at the bottleneck, no track means you cannot prove the saving, and no sustain means you have built something that expires.