Before You Automate the Workflow, Decide What Work Is Worth Keeping

Imagine a leadership team looking at a fourteen-step workflow and asking where AI might help. Someone has mapped the process, calculated the time spent at each stage and identified several places where drafting, classification or document checking could be automated. The opportunity looks compelling. Then a slightly awkward question comes up: why do we need steps nine through fourteen in the first place?

Perhaps those steps were introduced years ago to compensate for a system that has since been replaced. Perhaps we’re asking people to check information another team has already verified. Perhaps three layers of approval are all doing slightly different versions of the same thing, and nobody has gone back to challenge them because they have become part of the way the organisation operates. If we automate all of that, we might make a cumbersome process faster without making it particularly better.

This is related to the question of workflow redesign, but I think it deserves its own conversation. The temptation with new technology is to preserve the existing shape of the work and look for opportunities to add speed. In workshops, I find it can be more revealing to ask a group to explain what value each activity creates, for whom, and what would happen if it disappeared. Sometimes an activity exists for an excellent reason: risk, safety, a customer promise or a regulatory control. Sometimes the explanation is simply that it’s been there for years.

I wouldn’t start this with a giant current-state process map that takes half a day to read. I’d rather choose a representative customer or colleague journey and work through it with the people who actually understand the exceptions. What is the outcome we’re trying to create? Where does somebody wait? Where is information copied rather than used? What is a genuine decision versus a handoff or a routine status update? It’s often the conversations around the map, rather than the map itself, that are most useful.

From there, the design work becomes much more interesting. There are activities we could stop entirely, others we could combine, some we should redesign, and some we might be comfortable delegating to technology. I’d use individual reflection first, then bring observations together, create a few alternative future-state concepts and challenge the group to make choices. A modified Concept Poster could work well here too: show me a future experience in which the customer gets what they need with fewer internal contortions. Then tell me what we would have to believe, change and test to make it real.

AI can absolutely be part of the answer. It might support a colleague with better context, complete a genuinely repeatable step or bring together information that previously sat in different places. But I’d want to introduce it after we have questioned the work, not before. Otherwise we risk hard-coding the very problems that were worth redesigning in the first place.

There’s also an important trade-off for the sponsor to make explicit. Are we designing for lower cost, faster service, improved quality, stronger controls, a better employee experience or some balance between them? Removing an approval might improve speed but introduce unacceptable risk. Keeping a human conversation might look inefficient on a process diagram but be central to the customer relationship. The point is not to remove people or steps indiscriminately. It’s to understand why each part exists and make an informed choice.

Perhaps that’s the distinction I’d like leaders to keep in mind. The ambition shouldn’t be to build the most automated version of the organisation we already have. It should be to design a better version of the work—and then decide what contribution AI, people and the surrounding systems ought to make to it.