The problem
What the customer needs
- A workflow that survives someone being out sick or leaving the engagement, not one that lives in a single analyst's head.
- Clear handoff points so a piece of work moves cleanly from Claude-assisted draft to human review to client-ready output.
- Review gates placed where the actual risk is, not sprinkled evenly regardless of stakes.
Why naive approaches fail
- One team member becomes the unofficial "Claude person" and everyone else's work quietly depends on them.
- Team knowledge, client context, prior decisions, style preferences, lives in that one person's chat history instead of somewhere the team can reach.
- Review happens (or doesn't) inconsistently, some outputs get scrutinized heavily, others sail through with no gate at all, with no relationship to actual stakes.
- Shared team knowledge (client context, style, prior decisions) lives in a Project the whole team can reach, not one person's history
- Every handoff point in the delivery process has a clear owner and a clear next step
- Review gates are placed at the highest-stakes steps, not applied evenly regardless of risk
- A new team member could pick up the workflow from documentation, without shadowing one specific colleague
The system
What each part does
5 components, each owns a concept. Click any card to drill into the underlying primitive.
Current-State Map
how work actually moves today
Before changing anything, write down how a piece of work currently moves from intake to client delivery: who touches it, in what order, and where it currently stalls or breaks. This map is what you're integrating Claude into, not replacing wholesale.
Configuration
A simple sequence: intake → draft → internal review → client-ready → send. Note who owns each step today and where the current bottleneck actually is.
Shared Knowledge Base
team-reachable, not person-reachable
The client context, prior decisions, style guide, and recurring reference material live in a Project the whole team can access, not scattered across individual chat histories. This is what makes the workflow survive a team member being unavailable.
Configuration
One team Project per client engagement: source documents, a short style/tone note, and a running log of key prior decisions the team keeps referring back to.
Handoff Points
clear owner, clear next step
Each place work moves from one person (or from Claude-assisted draft to human) to the next has a named owner and an unambiguous definition of what "done" looks like at that step. Ambiguous handoffs are where work gets lost or duplicated.
Configuration
Draft owner hands a Claude-assisted draft to the reviewer with a one-line note on what was AI-assisted and what needs checking; reviewer hands the validated version to whoever sends it, with sign-off attached.
Review Gates
placed by stakes, not by habit
Not every output needs the same level of scrutiny. Review intensity is matched to what's actually at stake, an internal working note gets a light check, a client-facing deliverable with financial or reputational stakes gets a rigorous one.
Configuration
Two tiers: light review (internal, low-stakes, spot-check) and full review (client-facing, high-stakes, the validation-pass discipline from the deliverable-drafting scenario).
Onboarding Path
the reproducibility test
A short, written description of the workflow, enough that a new team member joining mid-engagement could follow it without shadowing one specific colleague for a week. If the workflow can only be taught by watching one person work, it isn't actually integrated yet.
Configuration
One page: where the Project lives, what the handoff points are, which review tier applies when. Reviewed and updated whenever the workflow changes.
Data flow
6 steps to production
Map how work currently moves, before touching anything
Write down the existing sequence from intake to client delivery: who owns each step today, and where things currently stall. Skipping this step and jumping straight to "add Claude everywhere" is how teams end up integrating Claude into a broken process instead of fixing the process.
↪ Concept: stakeholder-discovery-and-requirementsStand up one shared Project per client engagement
Move client context, style notes, and prior key decisions out of individual chat histories and into a team-reachable Project. This single move is what prevents the workflow from depending on one person's private setup.
↪ Concept: integrating-claude-into-existing-workflowsName an owner and a definition of done at each handoff point
For every place work moves between people (or from draft to review), write down who owns that step and what "done" looks like before it moves on. A one-line note attached to the handoff, what's AI-assisted, what still needs checking, prevents work from being silently dropped or redundantly redone.
Place review gates by stakes, not evenly
Sort the team's outputs into light-review (internal, low-stakes) and full-review (client-facing, high-stakes) tiers. Apply the rigorous validation discipline only where the stakes actually justify it, spreading it evenly everywhere either burns time on low-stakes work or under-scrutinizes the high-stakes work.
↪ Concept: architecture-documentation-and-handoffWrite the one-page onboarding path
Document where the shared Project lives, what the handoff points are, and which review tier applies when, concisely enough that a new team member could follow it. Test this by actually having someone new (or someone unfamiliar with the workflow) try to follow it.
↪ Concept: architecture-documentation-and-handoffRevisit the map as the engagement evolves
A delivery workflow that was right at project kickoff may not fit six months in, as the team grows or the client relationship matures. Revisit the current-state map and handoff points periodically rather than assuming the initial setup holds forever.
The four decisions
| Decision | Right answer | Wrong answer | Why |
|---|---|---|---|
| Where does client context and team knowledge live? | A shared team Project everyone can reach | Scattered across individual team members' personal chat histories | Personal chat history disappears the moment that person is out or leaves. Shared, configured knowledge survives team changes. |
| How much review does an output get? | Matched to actual stakes, tiered light vs. full | The same level of scrutiny applied evenly to everything | Even scrutiny either wastes time on low-stakes work or under-protects the genuinely high-stakes deliverables. Tiering matches effort to risk. |
| Who can reproduce the workflow? | Any team member, from a written one-page description | Only the person who originally set it up | A workflow that only one person can run isn't integrated into the team, it's a personal habit with a team-shaped label on it. |
| When do you revisit the workflow? | Periodically, as the engagement or team changes | Never, once it's set up at kickoff | Delivery engagements evolve. A workflow frozen at kickoff stops fitting the actual work within a few months. |
Where it breaks
4 failure pairs. Each maps to an exam-style question - the naive move on the left, the disciplined fix on the right.
One analyst becomes the only person who knows how to get good results from Claude, and the team quietly routes everything through them.
AP-CCAOF-D4-01Move the working knowledge (prompts, structure, source documents) into a shared Project so any team member can reproduce the workflow.
Client context and prior decisions exist only in one person's private claude.ai chat log.
AP-CCAOF-D5-02Consolidate that context into a team-reachable Project as a standing practice, not a one-time cleanup.
A low-stakes internal note gets the same heavy review as a high-stakes client deliverable, burning time without improving outcomes.
AP-CCAOF-D6-03Tier review effort by actual stakes: light for internal/low-stakes, full for client-facing/high-stakes.
A draft moves from one team member to another with no note on what was AI-assisted, and the reviewer has to reverse-engineer what to check.
AP-CCAOF-D4-04Attach a one-line note at every handoff: what's AI-assisted, what still needs checking, and who owns the next step.
Cost & latency
Mapping the current state and standing up the shared Project is a modest one-time cost relative to the engagement's duration.
The entire point of the shared-knowledge and documented-handoff discipline is that the team's delivery capability doesn't depend on any one person's availability.
A written, reproducible workflow lets a new hire or a mid-engagement addition follow documentation instead of shadowing a colleague for an extended period.
Tiered review avoids both wasted effort on low-stakes work and under-scrutiny on high-stakes deliverables, the worst outcome in either direction.
Ship checklist
Two passes. Build-time gates verify the code; run-time gates verify the system in production.
Build-time
- Current-state handoff map written down before any workflow changes↗ stakeholder-discovery-and-requirements
- One shared Project per client engagement, reachable by the whole team↗ integrating-claude-into-existing-workflows
- Every handoff point has a named owner and a definition of done
- Review gates tiered by stakes (light vs. full), not applied evenly
- One-page onboarding description exists and has been tested by someone new↗ architecture-documentation-and-handoff
- Workflow map revisited periodically as the engagement evolves
Run-time
- Shared Project exists and is actively kept current, not a one-time setup
- Every handoff point has a named owner and a written definition of done
- Review tiers are documented and consistently applied by stakes
- One-page onboarding description has been tested by an actual new team member
- Workflow map has an owner responsible for revisiting it periodically