Map recurring work before automating it

Automation projects often begin with a tool: add an agent to the inbox, connect the CRM, generate a dashboard, or replace a spreadsheet. That reverses the order.

The first object of study should be the operation itself.

The official process is not the real process

An SOP may describe the happy path. The team also knows the actual path:

• information arrives in the wrong format;

• one customer receives a different rule;

• a spreadsheet fills the gap between two systems;

• a manager approves unusual cases in chat;

• a missing field is reconstructed from an old email;

• a deadline is tracked in somebody's head;

• one person knows which exceptions matter.

These details are not noise. They are the workflow.

Define the boundary

Choose one recurring unit of work. Name what starts it and what “done” means.

For example:

A new service enquiry arrives through email. It is qualified, missing information is requested, an appropriate next step is prepared, the CRM is updated after approval, and a follow-up is scheduled if the prospect does not respond.

That boundary is small enough to map and important enough to measure.

Capture the minimum operating model

Document:

1. Trigger: what starts the case?

2. Owner: who is accountable for completion?

3. Systems: where does evidence live?

4. States: what stages can the case be in?

5. Rules: which decisions are deterministic?

6. Judgment: where is interpretation required?

7. Actions: what can the system prepare or execute?

8. Approvals: which actions have consequences?

9. Exceptions: what breaks the happy path?

10. Outcome: what business result should improve?

Without this model, an automation can move one step faster while making the overall operation harder to see.

Establish a baseline

Measure the current workflow before changing it. Useful baselines include:

• cases per week;

• time to first response;

• total cycle time;

• human handling minutes;

• backlog and ageing;

• rework;

• missed follow-ups;

• exception rate;

• error or policy-violation rate;

• cost per completed case;

• conversion or revenue where relevant.

The baseline does not need perfect instrumentation. It needs enough evidence to compare the new system with the current one.

Choose the smallest valuable system

The first implementation should usually prepare work before it executes work. It can collect context, identify missing information, draft the next step, and route exceptions into a visible queue.

That is enough to test whether the workflow model is correct, whether the team trusts the system, and whether the proposed change moves the selected metric.

Only then should the operating system expand into more actions or adjacent workflows.

Next step: Start with an Operations Sprint.