Designing a Claude-Assisted Workflow

Using Claude for a task once is prompting. Using it for the same task every week, by several people, with predictable quality, is a workflow. The difference is design: deciding what Claude does, what a person does, where the handoffs are and how you know it is working. This lesson gives a method that the exam expects you to apply to scenarios, and that works just as well in practice.

Three levels of involvement

Most workflows sit at one of three levels, and choosing the level is the first design decision.

Assist. A person does the task; Claude helps with parts of it on request (explain this clause, suggest a subject line). Lowest risk, lowest gain. Good for one-off or highly varied work.

Draft and review. Claude produces the first version; a person reviews, corrects and approves. This is the workhorse pattern for business documents, analysis and summaries. The person stays accountable and the time saving is large.

Execute with checkpoints. Claude carries out multi-step work (gathering from connectors, processing files, filling forms) and pauses at defined points for confirmation. Highest gain, and appropriate only where the steps are well defined, errors are recoverable and the checkpoints are real.

Moving up a level should be earned by evidence from the level below.

The six-step method

1. Pick a task worth automating. Recurring, time-consuming, well understood, with clear inputs and a clear definition of done. First candidates: weekly reports, meeting follow-ups, first-draft responses, document triage, data tidying.

2. Map the current steps. Write down what happens now, who does it, where inputs come from and where the output goes. Mark each step as judgement-heavy or mechanical.

3. Assign steps. Mechanical steps go to Claude. Judgement-heavy steps stay with people, or become draft-and-review. Any step with legal, financial or reputational consequence gets a human checkpoint regardless.

4. Choose the features. A Project for the standing instructions and reference material; connectors for inputs that live in systems; a Style for tone; a Skill (Domain 5) if the process is complex enough to need its own procedure; the right model for the hardest step.

5. Define the checks. For every Claude step, write the rubric and the verification tier. Decide what "stop and ask a human" looks like: missing data, a confidence flag, an unusual value.

6. Pilot, measure, document. Run it with one or two people for a few cycles. Measure time saved, error rate and reviewer effort. Fix the instructions. Then write a one-page guide and hand it over.

Designing for failure

A good workflow assumes Claude will sometimes be wrong and makes that cheap. Techniques:

• Placeholders over guesses. Instruct Claude to write [NEEDS INPUT] rather than invent a missing figure.
• Explicit uncertainty. "If you are not sure which contract applies, say so and stop."
• Structured output. Fixed headings and tables make omissions visible at a glance.
• Self-check sections. The rubric self-assessment from Domain 2 becomes a standard footer.
• Reversible actions first. Drafts rather than sends; staging rather than publishing.
• Sampling. For high-volume work, a person checks a random sample every cycle and the sample size rises if errors are found.

Scenario: inbound enquiry triage

A small consultancy receives thirty web enquiries a week. Today a partner reads each, decides whether it is a fit, and drafts a reply. Mapping shows three steps: classify fit (judgement, but with clear criteria), draft reply (mechanical given the classification), send (consequential).

Design: a Project holds the fit criteria, three example enquiries per category and reply templates as knowledge; instructions define the classification rubric and the reply format. An email connector lets Claude read new enquiries. Each morning the partner asks for the triage; Claude returns a table of enquiries with proposed category, confidence, and a draft reply for each. Rules: any "low confidence" row and any enquiry mentioning a budget above a threshold are flagged for the partner to classify personally; Claude never sends. The partner reviews the table in ten minutes, adjusts two or three, and sends.

Measured over a month: partner time down from four hours a week to one; two misclassifications, both caught at review; one template improved as a result. The workflow earned its place, and the partner is now considering a checkpointed send step for the "clear decline" category only.

Documenting a workflow

A one-page description should state: purpose, owner, inputs and where they come from, the Project and connectors used, each step and who performs it, the checks and checkpoints, known failure modes, and how to raise a problem. This document is what lets a colleague cover for you and what an auditor will ask for.

Exam focus

• Choose the involvement level (assist, draft-and-review, execute with checkpoints) based on how well defined the task is and how recoverable errors are.
• Map current steps, give mechanical steps to Claude, keep judgement and consequential steps with people or behind checkpoints.
• Design for failure with placeholders, explicit uncertainty, structured output, self-checks, reversible actions and sampling.
• Pilot with a few people, measure time saved and error rate, refine instructions, then document and hand over.
• A workflow document names purpose, owner, inputs, features used, steps, checks, failure modes and escalation.