Home › Study guides › CCAO-F › Domain 7 › Lesson 7.3

CCAO-F · Domain 7 · 10% of the exam · Lesson 7.3 · 19 min read

Optimising a Claude workflow: faster without losing quality

How to make a recurring Claude workflow faster and better: measure a baseline, stop repeating setup, fit each step, and keep the checks that matter.

Written against objective 7.3 of the official CCAO-F exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.

7.3.1 Why the report still takes two days

It's the third working day of the month, and Petra has just started the management report. She is a finance-operations analyst at a mid-size manufacturer of commercial boilers. Every month the report tells the leadership team how six product lines did against budget, with overheads, cash and two pages of commentary on what moved and why. She has used Claude for it for a year, on the company's Team plan, and it still takes her two full days.

Watch where the days go. She copies figures from three exports (the ledger, the sales system and the plants' production file) into a chat. She retypes the same long prompt from memory, a little differently each month, and explains again what the company counts as gross margin. When Rhys, the financial controller, posts a late adjustment, she redrafts the commentary. And every month Rhys finds two or three slips in percentages that Claude wrote into the text, which Petra fixes by hand.

Each draft is decent; the waste is in the workflow around it. The tempting fixes would get the report out a day early and make it worse: skip Rhys's review, or run everything on the fastest model. Optimising a workflow means improving two things together. Its efficiency is the time, effort and usage each run costs; its effectiveness is how good the result is. A real optimisation cuts the effort you repeat, never the checks that keep the result right.

7.3.2 Measure before you change anything

Most optimisation starts with the step that feels slowest. That's a poor guide. The step you dislike most is rarely the one that costs most, and without a starting figure you can't tell later whether a change helped. So the first move is a baseline: how the workflow performs today, recorded over a real run before you change anything.

Three measures cover both halves of the job. TIME per run, split by step, measures efficiency. ERRORS, the mistakes found at review and any that get past it, measure effectiveness. REWORK sits between the two: the follow-up messages, redrafts and hand fixes needed before a result is usable. Count usage as well if you often reach your plan's limits. Petra logs June's run as she works, step by step.

Read the last column as closely as the middle one. More than half of Petra's thirteen hours goes on work that repeats every month: copying, retyping, re-explaining and redrafting. And the error that reached leadership came from arithmetic written into prose, not from a weak prompt. Those two findings, not a hunch, decide where she starts. Memorise the three measures; Petra's figures only show them at work.

7.3.3 Stop rebuilding the same setup every month

The biggest block of Petra's time goes on putting Claude back where it was last month. The prompt, the definitions and the report layout never change, yet she supplies them from scratch, because each new chat starts knowing nothing about her company. Picture a cook who sharpens the knives and hunts for the pans again before every plate. The cooking is fine; the waste is the setup, which a real kitchen does once before service.

Claude offers four set-up-once tools, and each replaces a different kind of repeat. A Project is a workspace whose chats all start with the same standing instructions and the same uploaded reference files, called its knowledge. A prompt template is not an app feature but a fill-in-the-blanks request you keep yourself, in a document or a note; with the rules moved into the Project, it only needs the parts that change. A skill is a folder of instructions, sometimes with scripts, that Claude loads only when a task calls for it. A connector links Claude to another app your company uses, such as Google Drive, so it can read files there.

Projects are available on every plan. Their content is also cached: reused within a working session, it counts less against your usage limits than the same material sent fresh, though the cache expires after a period of inactivity. Anyone can write a simple skill as plain written instructions, with no coding, but skills need code execution, the setting that lets Claude run code, switched on.

A connector works through your own account, so Claude reaches only what you can already open there, and on Team and Enterprise plans an Owner must enable it for the organisation first. Two cautions apply. Put only approved, current material in the Project, because it shapes every run. And use only connectors your organisation has approved: ten minutes saved on copying never justifies an unapproved route for finance data.

7.3.4 Fit each step: the right model, feature and format

Here is the habit that drained Petra's usage: every step ran the same way. Because the report goes to leadership, she used the most capable model at the highest effort, the setting for how much thinking Claude puts into each reply. Web search and her Drive connector stayed on in every chat. She once used research mode, which is built for questions that need many outside sources, to find the month-end euro rate. It sat in the ledger export all along. Twice she reached her usage limit before the report was done.

A heavy setup is not a safe default; it is a removal lorry sent to deliver one letter. Research and web search add to what a request uses, higher effort uses more, and connected apps left on take up room in every conversation. So Anthropic's Help Center advises a lower effort level for routine tasks, and switching off the apps and web search a conversation doesn't need. The precise rule: give each step the lightest model, feature and setting that meets its quality bar, and save the heavy options for the steps that need them.

The same fit applies to how numbers are produced and what shape they come back in. Petra's slips came from arithmetic written into prose. Code execution, available on every plan, lets Claude write and run small programs on the files you upload. Having Claude analyse the data this way, instead of writing numbers as it goes, means every figure comes from a calculation run on the exports, one you can inspect and rerun next month. And when the figures go on to a spreadsheet, ask for one: a table with fixed columns or an Excel file, not figures woven into a paragraph that someone retypes.

Only one step earns the heavy setup: explaining an odd swing, such as margin falling while sales rose. Separating the figures from the words also fixes the late-adjustment problem. When Rhys posts a correction, Petra reruns the calculation and asks Claude to update only the commentary lines whose variances changed, instead of redrafting everything.

7.3.5 Ask once, with everything

Even with the setup in place, the commentary step leaked time through back-and-forth. Petra's usual message was "Write the commentary for these figures". The next eight messages supplied what it had left out: the budget column, the tone for leadership, a reason for every variance over 5%, and a shorter version. Each round cost minutes and usage, and risked breaking something that had been right.

Anthropic's usage guidance names the habits that close this gap. Plan the conversation before you start, and put the background and your checks in the first message. Batch similar requests into one message rather than sending them one by one. One request for all six product lines, under one set of rules, gives consistent commentary in a single round.

And start fresh. Petra had kept one chat going since January, carrying months of old figures into every request. Long conversations draw more on your usage, and the Help Center suggests starting a new conversation when a long chat nears your limit. A new topic gains nothing from an old chat's history either. Each month now begins with a new chat in the Project, which brings the standing context without last month's numbers.

Here is the request Petra now keeps as her monthly template. Look at step 2, the check that runs before any writing, and at step 4, where all six product lines go in one pass.

August report. The ledger, sales and production exports for August are attached.

1. Calculate with code: revenue, gross margin and overheads for each of the six product lines and for the company, against budget, using the definitions sheet in the Project.

2. Check before writing: confirm that company revenue matches the ledger export's total. If any line does not reconcile, list it and stop there.

3. Return the figures as an Excel file with one row per product line and columns for actual, budget and variance.

4. Then write the commentary for all six product lines in one pass, two or three sentences each, for the leadership team. Explain every variance over 5% using only the notes below; where no note explains one, write [ASK RHYS].

Notes for August: the northern plant closed for three days of planned maintenance; a large hotel order moved from July into August.

7.3.6 Change one thing, measure again, keep the gates

Petra made one change a month, each aimed at one finding from her baseline, and compared every run with June. When several changes land together, you can't tell which one helped and which hurt.

Look at the September row. The faster model saved half an hour, and the commentary came back too thin to explain the numbers to leadership. Time improved; the result got worse. Without the rework column, that change would have looked like a win. A change joins the standard setup only after it has held for a run or two, so what next month starts from has always been tested.

Now look at what happened to Rhys's review. It was never removed; it got faster, from two hours to forty minutes, because he now checks a reconciled Excel file against the ledger instead of hunting for percentages in paragraphs. That is how to treat a quality gate when you optimise: make the check quicker, never skip it. The report shapes decisions about budgets and jobs, and a calculation run as code can still be wrong if a column was mislabelled.

7.3.7 The exam traps

The wrong answers here buy speed with quality, or change something beside the point.

• ✗ Speeding up by skipping the review or the checks. ✓ Remove the repeated effort instead, and keep validation and approval where the stakes are high, made quicker to do.
• ✗ Changing the workflow on a hunch, with no baseline. ✓ Measure time, rework and errors first, then re-measure after each change.
• ✗ Re-pasting the same prompt, definitions and files every run. ✓ A Project with standing instructions and approved knowledge, a short prompt template, a skill for the procedure, and uploads or approved connectors.
• ✗ The most capable model and every feature switched on for every step. ✓ Fit each step; research, high effort and the top model go only where the step needs them.
• ✗ Letting Claude write figures into prose and fixing the slips by hand. ✓ Calculate with code, return a table or spreadsheet file, and check it against a known total.
• ✗ Sending corrections one message at a time in a months-long chat. ✓ Front-load the context and checks, batch similar items, and start a fresh chat for each cycle.

7.3.8 Put it together: optimise one workflow of your own

You now have the whole method. Measure a baseline, set up once what every run needs, fit each step, ask once with everything, and re-measure after each change while keeping the checks that matter. To make it stick, run it on a small recurring task, then take one piece of the setup away and watch the back-and-forth return.

Once the report runs faster, two other skills from this domain keep it healthy month after month. Each month's log is feedback, and adjusting your approach based on feedback and results (7.2) is how you act on what it shows. When a change makes an output worse, diagnosing poor outputs (7.1) finds the cause before you optimise further. And if Petra's leadership one day wants the report to build itself overnight from the ledger, that is an integration: work an Associate hands to Claude Architects and Developers.

Key takeaways

• ✓ Optimising means improving efficiency (time, effort, usage) and effectiveness (quality) together; never buy speed by removing the checks that matter.
• ✓ Measure a baseline before changing anything: time per run by step, rework, and the errors found at review and after it.
• ✓ Remove repeated effort with a Project holding standing instructions and approved knowledge, a short prompt template, skills for repeatable procedures, and uploads or approved connectors instead of copy-paste.
• ✓ Fit each step with the lightest model, feature and setting that meets its bar; calculate with code, and return structured output when a spreadsheet comes next.
• ✓ Front-load context and checks, batch similar items into one message, and start a fresh chat for each new cycle or topic.
• ✓ Re-measure after each change, one at a time, and keep human review on consequential outputs by making the check quicker, not by removing it.

Check your understanding

4 questions written for this lesson, then one from the CCAO-F question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.

Sources

• Usage limit best practices
• How do usage and length limits work?
• What are projects?
• What are skills?
• Use connectors to extend Claude's capabilities
• Create and edit files with Claude
• The CCAO-F exam guide, summarised