“Can we automate this?” is a useful opening to a conversation. It tells you that someone is feeling friction. The next step is to understand where that friction comes from.
The approach I find useful starts with the work itself: what people are trying to achieve, where effort accumulates, and who will own the process after it changes.
- Follow the work
- Name the friction
- Establish a baseline
- Shape the change
Follow one piece of work
Start with a concrete example. Ask someone to walk through the last request, schedule, approval, or record they completed. Follow it from the trigger to the outcome.
A process description often explains how things are supposed to happen. A recent example can reveal the follow-up message, duplicate entry, or missing information that the description leaves out.
- What starts the work, and what counts as finished?
- What information does each person need?
- Where does the work wait, return, or get repeated?
Name the friction precisely
“The process is manual” describes how work happens. It still leaves the cost of that work unclear. Try to name the burden more specifically: repeated entry, unclear ownership, preventable errors, or time spent chasing a decision.
This makes it easier to consider different interventions. Sometimes the useful change is a clearer rule or a better handover. Sometimes it is an integration or a purpose-built digital workflow.
Establish a useful baseline
Choose a measure that reflects the problem. If the burden is administration, look at effort. If work gets stuck, look at elapsed time and the reasons for waiting. If errors create rework, record where they originate.
Keep the basis of the measure visible. An estimate, a sample, and a measured operational result each tell a different kind of story. Time returned to a team is useful capacity; translating it into financial savings requires additional evidence.
Choose the change around the problem
Once the friction is clear, shape a bounded change. Explain which part of the workflow it will improve and how you will recognise that improvement.
A prototype can help when the proposed experience is hard to describe. A process map can help when the difficulty sits in handoffs. The most useful artefact is the one that resolves the uncertainty in front of you.
Make ownership part of the solution
Agree who will own the process or capability after delivery. Someone needs to maintain the rules, handle exceptions, and decide what should change next.
In transformation work, the project team may help establish a capability and then hand it over. That transition deserves attention from the beginning, because an improvement has to keep working after the project ends.
A good diagnosis produces a clear problem, a useful baseline, and a practical owner. That is a stronger place from which to decide what to digitalise or automate.
Have you worked through something similar?
Let’s compare notes on LinkedIn (opens in a new tab)