Purpose and fit

Use this when a team proposes automating a busy but frustrating process. First establish which work still serves a useful purpose. A recurring report, copied field or review step may be essential, optional or left over from a previous arrangement. Its frequency alone does not answer that question.

The outcome is a smaller, agreed body of work to support. Keep required controls and downstream dependencies visible while considering changes.

Before you start

Start with a recent authorised work item or your current list of steps and recipients. Approximate effort can be labelled as an estimate; exact time tracking is not required. Include known controls and dependencies, remove personal details and adapt the prompt to whatever process evidence exists.

Expect a candidate-change register and draft simplified process, not permission to remove a step or evidence of realised savings. Every removal proposal should retain an owner, dependency check, fallback and bounded review step.

Required inputs

  • A recent end-to-end example, including requests, intermediate outputs and the final recipient.
  • A list of recurring steps, their effort, stated purpose and current owner.
  • People who use each output, including teams outside the immediate process.
  • Known controls, commitments, records and operational dependencies that constrain removal.

Practical workflow

  1. Walk through a typical work item and list every step, including copying, checking, waiting and correcting. Note the output produced and who uses it next.
  2. Ask each recipient what decision or action the output enables. If no user or purpose can be confirmed, mark the step for investigation rather than declaring it unnecessary.
  3. Classify candidate changes: remove, reduce frequency, combine, simplify inputs, clarify ownership or retain. Identify whether an upstream improvement would prevent downstream correction work.
  4. Check dependencies with the relevant owners. A step that appears redundant may provide a control, record or contingency. Record the purpose explicitly and seek an approved alternative if removal is proposed.
  5. Rehearse a simplified version on a sanitised example. Then, if authorised, try a reversible, bounded process change with a named owner, a fallback and clear signs that required work is being missed.
  6. Compare the recipient’s ability to complete their task and the effort across all affected teams. Confirm the revised process before deciding which remaining steps might benefit from AI assistance.

Expected output

A work-removal register and a revised process outline. Use these fields for each proposed change:

Current step: [description] Output and recipient: [what/who] Purpose confirmed by: [owner] Dependency or control: [requirement or unresolved] Proposed change: [remove/reduce/combine/simplify/retain] Expected effect: [outcome and displaced work] Approval needed: [decision owner] Bounded check: [scope and acceptance signs] Fallback: [how work continues] Observed result: [evidence] Final decision/review date: [owner and date]

Hypothetical example: two teams prepare overlapping weekly summaries. The recipients confirm that one shared source and a shorter update would answer their questions. The teams first test that simpler arrangement rather than immediately automating both reports.

Human checks

Ask downstream colleagues whether effort is genuinely removed or merely transferred to them. The process owner verifies approvals before any live step is stopped. Keep staff involved in the redesign and discuss work requirements without treating a task-level exercise as a decision about individual roles.

Limitations

Low usage does not automatically mean low value: some records and contingency steps matter only occasionally. A short trial may miss rare dependencies. Process simplification requires operational judgment and cannot establish that a control is optional.

Starter prompt

Review this workflow for avoidable work using only these sanitised notes: [steps, outputs, recipients, dependencies and constraints]. The process owner is [owner]. Identify candidates to remove, reduce, combine or simplify, and explain what evidence is needed for each.

Create a register with these fields: current step; output and recipient; purpose and confirming owner; dependency or control; proposed change; expected effect and displaced work; approval needed; bounded check and acceptance signs; fallback; observed result; final decision and review date. Leave unobserved results unresolved. Flag unknown recipients, hidden downstream effort and steps serving a possible control or contingency purpose. Propose a reversible rehearsal. Do not remove steps, waive requirements, change responsibilities or start automation; prepare proposals for authorised owners to review.

Adapt the requested fields to the authorised inputs actually supplied. When a recipient or purpose is unknown, mark the step for investigation rather than removal. Preserve conflicting dependency accounts and distinguish reduced effort from effort shifted to another team. Do not fill future observed-result fields. State the expected output and acceptance criteria before drafting. Ask for essential missing information; where a useful partial draft is possible, label its limits and assumptions. Do not invent facts, evidence, results or approvals.

Data, model variability and your responsibility

Use relevant data that exists or that you provide, with accuracy and completeness sufficient for the task. Different AI models and versions may produce different results, and responses may vary between runs. You are responsible for checking and validating the output against your own requirements, source information and acceptance criteria before relying on it.