# Operations workshop

Map current processes, bottlenecks and opportunities for improvement.

**TL;DR**

Map how work actually moves, including the waiting, workarounds, and mysterious spreadsheet. Pick a bottleneck, give the change an owner, and decide how to tell whether it helped.

Status: Workshop method

## Before you start

For: Operators and team leads

Use when: Recurring work is slow, duplicated or dependent on one person.

Bring: Real examples from a normal week, the people doing the work and a decision owner.

Leave with: An owned backlog of process changes and automation candidates.

## Worked example (fictional)

A fictional studio copies approved filenames into an invoice sheet every Friday. Map who approves, what gets copied and where mistakes occur before choosing an integration.

## Check the result

Each fix has an owner, frequency, observed cost and a small first test.

## Limitations

Do not automate an unclear approval rule. Record it and resolve ownership first.

Ask someone to take you through the last piece of work they delivered. Follow the email, the spreadsheet, the file they copied, and the person they had to wait for. You will learn more than you would from the process diagram alone.

Build the map together from those examples. Look for a handoff you can improve and test it on a small piece of work. Automating a step is useful only if the step should still exist.

## Prepare

Get the people who actually run things: whoever sends the invoices, answers the inbox, does the handoffs, and covers when someone is out. Leadership should be in the room, but the stickies belong to the operators.

This workshop surfaces things people privately work around. Say at the start that naming a broken process is useful, not a complaint.

The same kit: 90 minutes, whiteboards, stickies, Sharpies.

Ask everyone to bring their real week: calendar, recurring tasks, the checklist that only exists in their head.

Agree on the unit before starting: one sticky is one recurring activity, not a department.

## Friction brainstorm · 30–45 min

Everything that is manual, slow, duplicated, error-prone, or dependent on one person goes on the wall: one activity per sticky, said out loud. 'Invoices copied from the sheet', 'onboarding emails written each time', 'only Anna can deploy'.

Include the uncomfortable ones: the process that exists only because it always has, the report nobody reads, the approval that nobody ever rejects. Mark every sticky that depends on a single person with a dot. Those become their own list later.

Rounds of ten minutes until two minutes of silence.

## Keep, fix, kill · 30–45 min

Three columns: Keep (works, leave it alone), Fix (needed but broken: automate, document, or reassign), Kill (stop doing this). Place every sticky as a group.

Kill is the hardest column to fill and the most useful. When a sticky won't settle:

Photograph the board. Anything in Fix that also carries a single-person dot goes to the top of the list.

- Ask what it costs per month in hours — counted, not guessed.

- Ask what happens if it stops for two weeks — often the honest answer is nothing.

- Separate the activity from the artifact — a report can go while the number it contained stays.

- Check whether a tool you already pay for does this.

- Skip it — the workflow map in phase three usually decides it.

## Workflow mapping · 30–45 min

Second session. Cluster the Keep and Fix stickies by the workflow they belong to: lead to deal, deal to delivery, delivery to invoice, invoice to cash, hire to productive. Name each flow and draw the handoffs between people and tools.

Look at every handoff and every loop that crosses more than two tools. Those are the automation candidates. Mark the places where work sits waiting; that's usually where the real time goes.

## Distilling into the backlog · 30–45 min

Transpose the board into an ops backlog: each Fix item gets an owner, how often the pain recurs, and a first step. Rank by frequency times pain: a small weekly problem outranks a dramatic yearly one.

Write the single-person-dependency list separately, each with its backup plan, or 'none' if that's the truth. Close with the automation shortlist: the three fixes where a machine should be doing the work.

## Output

An owned, ranked ops backlog; a named workflow map with the waiting points marked; the single-person-dependency list; and the automation shortlist.

This is the operational half of a proposal: the automation shortlist becomes scoped work, and the backlog sets the cadence we build against.

## Handoff

Record the input sources, decisions, assumptions, owner and acceptance checks. Have the responsible person approve the record before downstream automation.

## Tools, in order

### Before the session

[Notion](https://www.notion.com/) · Paper or a shared workshop board

Choose one recurring process and bring a few recent cases, including one that went wrong. Put the decision you need on the first page. Agree on recording, transcription, access, and retention with everyone before starting; handwritten notes are a valid alternative.

Carry forward: A brief, a prepared board, and an agreed capture method.

### In the room

[Notion AI Meeting Notes](https://www.notion.com/help/ai-meeting-notes) · Paper or a shared workshop board · Phone camera

Use the recorder to support listening, not to replace a facilitator. Map actual handoffs, waits, and approval rules with the people doing the work. Write decisions and disagreements visibly; photograph the boards with permission. Pause recording whenever someone asks.

Carry forward: Authorized source notes, a transcript if agreed, and labeled board photos.

### After the session

[Claude](https://claude.ai/), [ChatGPT](https://chatgpt.com/), or [Grok](https://grok.com/) · [Notion](https://www.notion.com/)

Check speaker names, quotations, numbers, and apparent agreements against the sources. Ask an assistant to draft a process map with owners, failure points, and a small improvement experiment, with a source ID for each decision and a separate list of open questions. Have participants correct the record before using it as a brief.

Carry forward: a process map with owners, failure points, and a small improvement experiment

### Review the work with partners

We make and revise the work with Claude, ChatGPT, or Grok, then put selected versions on our Studio project pages for partners to review. Check the preview before sharing it. You can do the same with a private prototype or shared document; use a workspace that can access the files you need.

Name the version, say what changed, and ask the question you need answered. Keep feedback with that version and discuss conflicting requests before making the next changes. Confirm approval separately, and keep confidential work in a restricted space.

For this method: Does this reflect the real handoff, and who is responsible when the normal path fails?

### Delegate the routine work

Turn verified notes into a source-linked table, label board photos, or format the agreed action list. Give the agent only the relevant excerpts and a completed example.

Keep with a person: Interpreting disagreement, choosing a direction, and deciding what participants actually approved stay with the facilitator and decision owner.

[Sequence prompts, then delegate](https://noord.dev/polder/delegating-with-prompts)

[Choose a model for the design task](https://noord.dev/polder/choosing-design-models)

Source: https://noord.dev/polder/workshop-ops

Public working material from Noord. Third-party code, fonts and assets retain their own licenses. Publication does not imply a license to redistribute third-party material.