Prepare Your Department Workflow

The functional tracks run on your real work, and that makes preparation the highest-leverage hour of the whole program. Teams that arrive with a bounded workflow and real materials leave their track with a working prototype. Teams that arrive with "let's see what AI can do" leave with a demo they never use again.

Choose a strong candidate

Prioritize work that is:

• Frequent enough that improving it actually matters
• Heavy on searching, comparing, drafting, classifying, or reformatting
• Supported by accessible, approved source material
• Easy to judge — a good result is recognizable when you see it
• Narrow enough to test within a 4–6 hour track session

Two traps catch ambitious teams. The first is picking the most sensitive process — contract redlines, compensation decisions — where every test tangles with approvals and nerves. The second is picking the broadest one — "improve our whole planning cycle" — which cannot be tested at all. At Northstar, the support team skipped both and chose "first-response drafts for the top three ticket categories": frequent, well-documented, easy to score. That is the profile of a good first workflow. The sensitive and strategic ones come later, once the method is proven.

Placeholder: replace with a two-axis map of expected value and implementation risk.

Bring a workflow packet

Each item below removes a stall you would otherwise hit mid-session. Remove or anonymize sensitive information unless its use is approved.

1. A current example of the input — real work, not an idealized version
2. A strong example of the desired output — this becomes Claude's target and your test answer key
3. The policy, playbook, or criteria used to do the work — the knowledge a Project will hold
4. A simple map of steps, handoffs, and approvals — so you automate the step, not the accountability
5. A baseline number — time, volume, rework, delay, or error rate; without it you cannot prove improvement
6. System and permission constraints — what the workflow may touch, and what it may not

Write the target

For [user], improve [workflow] from [current baseline] to [target outcome] while preserving [quality or control].

Northstar support's version: "For tier-1 agents, improve first-response drafting from 25 minutes per ticket to under 10, while preserving policy accuracy and the escalation rate." Notice it describes a business change with a number in it — not an AI feature. If your target sentence would still make sense with "AI" deleted, it is a good target.

Define the test before you build

Choose three representative cases — one typical, one messy, one that should escalate — and decide how you will score results: completeness, factual accuracy, tone, correct classification, review time, exception handling. Deciding this before building keeps the session honest; it is very easy to grade a demo generously after the fact.

Track deliverable

Every department leaves its session with a tested workflow design, reusable instructions or a working prototype, a named owner, and a short list of issues to resolve before the capstone. The packet you bring is the raw material for all four.