Workflow Integration and Solution Design · Lesson 3 of 6

4.3 — Process Optimisation: Augment vs. Redesign

Decide whether to bolt Claude onto an existing process as one extra step, or redesign the process around what Claude actually makes possible.

Once you've confirmed a task is a good fit for Claude (lesson 4.1), there's a second design decision that's easy to skip: do you insert Claude into the process as it already exists, or do you rethink the process itself now that a capability like Claude is available? These are genuinely different moves with different costs, different payoffs, and different amounts of organizational disruption — and the exam expects you to recognize which one a given scenario calls for.

Augment: Bolt Claude onto the Existing Process

Augmenting means adding Claude as one additional step inside a process that otherwise stays the same — same handoffs, same owners, same approval chain. A marketing team that already writes social captions by hand might add a step where Claude drafts a first version before the same human editor reviews and posts it, exactly where the "write the caption" step always lived. The appeal is real: it's fast to pilot, low-risk, easy to roll back if it doesn't work, and doesn't require retraining anyone on a new process. The limitation is equally real: augmenting only ever saves time on the one step you inserted Claude into. If the bottleneck was actually somewhere else in the process — approval delays, unclear requirements upstream, a slow handoff between teams — augmenting one step won't touch it.

Redesign: Rebuild the Process Around What's Now Possible

Redesigning means rethinking the process itself, because Claude makes a fundamentally different shape of workflow possible, not just a faster version of the old one. Take that same social media team: instead of one person writing every caption, a redesign might have Claude generate a full week's draft slate from a shared campaign brief in a Project, with the human role shifting from "write captions" to "review, adjust brand voice, and approve a batch" — a genuinely different job, not a faster version of the old one. The payoff is bigger: this can unlock throughput or consistency that augmenting one step never would. The cost is bigger too — it requires actual change management (people's roles and daily habits change), more up-front design work, and more risk if the new process doesn't hold up under real volume.

Choosing Between Them

Augment when you need a fast, low-risk pilot, when the process is already reasonably efficient and just needs one slow step sped up, or when you don't yet have confidence Claude will handle the task well enough to redesign around it. Redesign when the current process's bottleneck is structural — too many manual handoffs, a step that only exists because a human had to do the slow part by hand — and when there's organizational appetite for change management. A sensible sequence in practice is often to augment first as a low-risk pilot, build confidence and evidence from real output, and only then consider redesigning once you know Claude reliably handles the task (see lesson 4.4 on iterating across real runs before scaling up).

Key Concept

Augmenting inserts Claude into an existing process as one step, keeping everything else the same — fast to pilot, low disruption, limited to the gains of that one step. Redesigning rebuilds the process around what Claude makes newly possible — bigger potential payoff, more change management, and more up-front design and risk.

Common Exam Distractor

Watch for a scenario where the real bottleneck is structural (e.g. multiple slow handoffs between teams) but the proposed fix is only to augment a single step with Claude. Augmenting a step that isn't the bottleneck won't meaningfully speed up the overall process — that's a signal the scenario is actually calling for a redesign, or for augmenting a different, better-chosen step.

Exam traps

Assuming redesign is always the 'more advanced' and therefore better choice

Redesign carries real cost — change management, up-front design work, and risk. Augmenting is often the right call for a fast, low-risk pilot or when the rest of the process is already efficient.
Augmenting a step that isn't actually the process bottleneck

If the slow part of a process is elsewhere (e.g. approval delays or handoffs), speeding up an unrelated step with Claude won't meaningfully improve overall throughput.
Treating augment and redesign as a one-time, permanent choice rather than a sequence

A common and sensible pattern is to augment first to build confidence and evidence, then consider redesigning later once real output has been reviewed across multiple runs.

Practice question

A finance team's monthly reporting process has five steps: pull data from three systems, reconcile the numbers by hand, write a narrative summary, route it through two levels of manual approval, and distribute it. The team wants to introduce Claude. The narrative-writing step alone currently takes about 30 minutes each month, while the two-step manual approval routing regularly adds several days of delay. Someone proposes having Claude draft the narrative summary, keeping every other step exactly as is. What's the most accurate assessment?

A This is a good redesign because it changes what the finance team does each month
This is augmenting, not redesigning — one step is replaced with a Claude-assisted version while the rest of the process, including handoffs and approvals, stays exactly the same.
B This is a reasonable augmentation to pilot, but it won't address the process's actual bottleneck, which is the multi-day approval routing, not the 30-minute narrative step Correct
This correctly identifies the proposal as augmenting (low-risk, one step changed) while also recognizing that the real delay in the process is elsewhere — augmenting the narrative step won't fix the approval bottleneck.
C This proposal should be rejected outright because augmenting without redesigning the whole process wastes the opportunity
Augmenting isn't a wasted opportunity — it's often the right first move, especially as a low-risk pilot. The issue here is specifically that this particular step isn't the bottleneck, not that augmenting itself is wrong.
D This is a poor use case for Claude entirely, since the process involves reconciling numbers from three systems
The narrative-writing step itself is a reasonable Claude use case (drafting from data that's already been reconciled) — the critique is about which step was chosen and its impact on the overall bottleneck, not about fit.

Build exercise: Map Augment vs. Redesign for a Real Process

Intermediate · 25 minutes

You'll practice:

Distinguish an augment move from a redesign move using a real or realistic process
Identify a process's actual bottleneck before choosing where to apply Claude
Draft both an augment version and a redesign version of the same process

Pick a real recurring process from your own work (or invent a realistic one) with at least 4 distinct steps and named owners for each step. In a claude.ai conversation, describe the process to Claude step by step and ask it to identify which step is most likely the actual bottleneck, and why, based on where delay or manual effort concentrates.

This grounds the augment-vs-redesign decision in an actual bottleneck analysis rather than picking a step to improve just because it's the most visible or the most tedious.

You should see: Claude naming a specific step as the likely bottleneck with a reason tied to delay, handoffs, or manual effort — not simply the step that seems most 'AI-shaped.'
Hints
1. ```
Include realistic detail about how long each step takes and who owns it — vague steps make bottleneck analysis harder.
```
2. ```
If Claude picks the step you expected, ask it to explain why a different step isn't the bottleneck, to pressure-test the reasoning.
```
3. ```
A bottleneck is often a handoff or approval wait, not the step that looks the most effortful.
```
Ask Claude to draft two distinct proposals for the same process: (1) an augment version that inserts Claude into exactly one existing step with no other changes, and (2) a redesign version that restructures the process around what Claude makes newly possible, including how roles or handoffs would change.

This practices producing both moves side by side so you can see concretely how they differ in scope, disruption, and payoff — the core distinction this lesson tests.

You should see: Two visibly different proposals — the augment version touching only one step, the redesign version describing changed roles, a different sequence of handoffs, or a new shared artifact like a Project.
Hints
1. ```
Push Claude to be concrete about what changes for people in the redesign version — new responsibilities, not just 'Claude does more.'
```
2. ```
Check that the augment version genuinely leaves every other step untouched.
```
3. ```
If the two proposals look too similar, ask Claude to make the redesign version more structurally different.
```
Decide which of the two proposals you'd actually recommend piloting first, and write two or three sentences justifying the choice using the bottleneck analysis from step 1.

This closes the loop between bottleneck identification and the augment/redesign decision, which is exactly the judgment call the exam scenario tests.

You should see: A short written justification that explicitly references whether the proposed change addresses the actual bottleneck you identified, not just whichever proposal sounds more impressive.
Hints
1. ```
If the augment version doesn't touch the bottleneck step, that's worth stating directly in your justification.
```
2. ```
It's fine to recommend augmenting as a first pilot even if redesign has the bigger long-term payoff — say why.
```
3. ```
Reference lesson 4.4's idea of piloting and iterating before committing to a bigger redesign.
```

Sources

Written fresh — no CCAR-F equivalent
Anthropic — Claude for Business / workflow use case documentation