Champion capstone: pilot a real process and measure the impact

What a capstone is for

Everything before this taught individual skills. This lesson asks you to combine them on a real problem and produce evidence a manager would take seriously. The deliverable is not "I tried some AI"; it's "I took a process that took X, changed it, and now it takes Y: here's how, and here's what it scales to." That sentence is what makes you a champion rather than an enthusiast.

The heart of it is measurement. AI work is easy to feel good about and hard to prove. A capstone that ends with "it felt faster" has failed; one that ends with "45 minutes down to 12, roughly 30 hours a year across the team" has succeeded, even if the numbers are modest or rough, because honest small numbers beat vague big claims.

Choosing a process worth piloting

Not every task is a good candidate. The best pilots share four features:

• Repeated. You or your team do it regularly, weekly at least. A one-off has no baseline and no payback.
• Measurable. You can time it or count it. "Tidying the weekly notes" is measurable; "thinking about strategy" isn't.
• Low-risk to pilot. Getting it wrong during the pilot won't hurt anyone. Avoid anything that sends externally or touches confidential data until the approach is proven.
• Yours to change. You have the standing to actually alter how it's done, so the pilot can become real practice.

Then pick the tool from what you've learned, on fit, not novelty. A repeated writing task with a house style points to a custom assistant or a Project. A multi-stage job (research, then rewrite, then slides) points to a cross-tool chain. A trigger-and-action task with no judgement (filing, logging, alerting) points to an automation (flow, Zap or scenario). The right answer is often the simplest one that does the job.

The project brief

The one-page write-up template

Copy this and fill it in. It's deliberately one page: a champion communicates impact briefly.

Capstone write-up

• Process: the task, in one line
• Who does it / how often: e.g. Maya, weekly
• The problem with the old way: slow, inconsistent, error-prone; be specific
• Baseline: time and/or quality before, measured once; e.g. 45 min, actions often missed
• Tool(s) chosen and why: name them, and the fit reason: where the data lives, what it's best at
• What I built: the assistant / chain / automation, in two or three lines
• New per-task result: time and/or quality after; e.g. 12 min, actions captured every time
• Saving per task: baseline minus new; e.g. ~33 min
• What it scales to: per week / per year / across the team; e.g. ~28 hours a year for the team
• Where a human still checks: the load-bearing step you kept for yourself
• Limits and risks: what could go wrong, what you'd watch
• Next step: make it real, widen it, or park it, and why

Suggested approach

A pilot that works tends to follow the same shape. Start with the baseline before you touch anything. It's tempting to build first, but without the "before" number you can never prove the "after". Build the smallest version that does the job, run it a few times, and resist widening the scope mid-pilot. When you measure, be honest about setup time too: a saving of 30 minutes a week that took three hours to build still pays back inside a couple of months, and saying so is more credible than pretending it was free.

Above all, keep a human on the step that matters. The strongest capstones don't hand everything to the tool; they automate the mechanical part and keep judgement (the final check, the confidential detail, the customer-facing send) with a person. That's not a weakness in the pilot; it's the design working as it should.

Self-assessment rubric

Score your capstone honestly against each level. Aim to be able to point at evidence for your score.

• Basic. You used an AI tool on a real task and it helped. You can describe what you did, but the impact is stated as a feeling ("it felt quicker") rather than measured, or there's no baseline to compare against.
• Good. You set a baseline, built a sensible pilot on a well-chosen tool, ran it more than once, and measured a real saving per task. Your write-up is clear and you've named where a human still checks.
• Excellent. All of "good", plus: you justified the tool choice against alternatives, measured both time and quality, scaled the saving to a credible team or annual figure with your working shown, were honest about setup cost and limits, and identified a concrete next step to make it real. Someone reading your one-pager could act on it.

The gap between "good" and "excellent" is almost entirely about honest measurement and communication, not about a fancier tool.

Evidence note

Common mistakes

• Building before measuring. Without a baseline recorded first, you can never prove the improvement. You're left with "it felt faster", which is a basic-level result at best.
• Piloting once and calling it proven. A single run can flatter or mislead. Run the new way a few times before you trust the number.
• Scaling with fantasy figures. "This will save the company hundreds of hours" with no working behind it reads as hype. A small, shown calculation is far more credible than a big unsupported one.
• Over-scoping the pilot. Trying to reinvent a whole process at once usually stalls. One clear improvement, measured, beats an ambitious rebuild that never ships.
• Over-trusting the pilot and removing the human too soon. The most damaging mistake: a pilot goes well a few times, so you let the tool run unchecked on the real thing, and it confidently gets something wrong when no one's looking. A successful pilot earns a wider trial, not the removal of the human check. Keep a person on the irreversible and the load-bearing steps, and say so in your write-up; that judgement is part of what makes the work champion-grade.

Keeping current

The capstone method (find a process, baseline it, pilot, measure, write up) is durable and will outlast every specific tool you used in it. As the tools change, the honest habit of proving impact with a baseline and a number is what keeps your AI work credible. When you revisit a pilot, re-check the tool you built it on against its current features and pricing via the vendor's own pages, since capability and limits move. Accurate as of 13 July 2026.