When I rebuilt operating processes at a regional M&A firm, clarifying roles and handoffs was part of the work. That experience shapes how I evaluate workflows today: I don’t treat a faster task as sufficient reason to change an operation. Before committing money and staff attention, I want to know what that speed would make possible.
The decision isn’t simply where to use AI. It’s which workflow deserves the cost and disruption of change. I put the economic case ahead of the tool choice — and compare the proposed change with simpler ways of addressing the same problem.
Start with the work’s economic burden
I look at a workflow from the event that starts it to the point where someone can use the result. Stopping at a department boundary would leave too much of the work outside the assessment.
Within that boundary, I separate time spent doing necessary work from time spent waiting, correcting, checking, or passing information along. I also look for decisions that remain unresolved. Those distinctions matter because each calls for a different response. I wouldn’t choose a technology to address an ownership problem before clarifying who has authority to act.
I then connect the burden to the business: what it costs to complete the work, what it prevents people from doing, and what happens when it’s late or wrong. My aim is to identify a consequence that leadership can evaluate, not just a task that employees dislike.
Distinguish saved time from usable capacity
I don’t count every potential hour saved as an economic benefit. I want to know who would get that time back, whether it would be available in useful blocks, and what work could occupy it.
For me, a capacity claim needs an operating explanation. Would the change let the same people complete more necessary work? Would it remove a constraint on revenue-producing activity? Would it reduce a cost the business would otherwise incur? Without that connection, I’d record potential convenience rather than assume financial value.
I apply the same discipline to new capabilities. I want to understand who needs the capability, how it would be used, and why it matters enough to support its ongoing cost. The ability to produce more output isn’t, by itself, my reason to proceed.
Count the whole change, not the subscription
I include more than software expense when comparing workflows. My assessment includes preparation, implementation, review, training, maintenance, and the attention required from the people who already run the business.
I also examine where work might move rather than disappear. If reducing effort at one step would require additional checking elsewhere, I count that checking. If exceptions would still need experienced judgment, I keep that responsibility visible in the plan.
Where legal or regulatory constraints are material, I include qualified counsel’s review in the assessment. I don’t treat those requirements as details to resolve after choosing a tool.
AI-assisted work may change the economics of a workflow. I still need a defensible comparison between the full cost of the proposed approach and the value of the operating change.
Compare against a simpler fix
Before selecting an AI-assisted approach, I consider whether clearer instructions, fewer approvals, better handoffs, or removing unnecessary work would address the cause.
That comparison keeps the decision honest. I’m not trying to find a justification for a particular technology. I’m trying to select a change that deserves the business’s resources.
I prioritize workflows where I can describe the burden clearly, connect the proposed improvement to a meaningful business use, and identify an accountable owner. I’m more cautious when the case depends on uncertain demand, unresolved dependencies, or savings that nobody can explain how to use.
Make the selection testable
For the workflow I would pursue first, I write down the current burden, the proposed change, the expected economic benefit, and the evidence needed to evaluate it. I also define what would make me stop or revise the effort.
I keep the scope narrow enough to distinguish the effect of the change from unrelated activity. During execution, I evaluate completion, rework, review effort, and whether people actually use the revised process — not just whether the technology functions.
My decision rule is straightforward: choose the workflow with the clearest connection between an operating change and economic value, after accounting for the work required to get there. I choose the tools to serve that decision, not to make it for me.