Before anything is automated
Governance questions
- Who owns this process today
- Which system is authoritative
- What happens when the output is wrong
- Who reviews the exception
- What is the stopping condition
- Who maintains it in six months
How I solve problems
I do not start with software. I start by understanding the decision, the people involved, and how the work actually happens. A visible symptom in one department is often caused by a breakdown somewhere else.
Phase one
Watch how the work actually runs before forming an opinion about it.
Ask the people doing the work what slows them down.
Document the real path, including the workarounds nobody wrote down.
Phase two
Learn what each group needs, fears, and is measured on.
Trace the symptom back to where it actually starts.
Agree on what gets solved first and what waits.
Phase three
Build the simplest structure that answers the real question.
Put it in front of the people who will use it and watch.
Roll out with owners, training, and a fallback if it stalls.
Phase four
Track whether the decision got faster and clearer.
Adjust based on real use, not on the original assumption.
Why it works this way
A backlog in customer operations usually is not a customer operations problem. It is an intake problem, a routing problem, a definitions problem, or a training problem that shows up last in the place with the least room to absorb it. If you fix the visible symptom, the work comes back.
So the first three steps are not deliverables. They are the part where I resist the urge to build. Watching the work, asking the people doing it what slows them down, and drawing the real path including the workarounds nobody documented. That map is almost never the same as the official process.
Only after that does it make sense to talk about who is affected, what is actually causing it, and what gets solved first. Priorities matter here because most operational problems are not solvable all at once, and pretending otherwise is how improvement projects stall.
The build phase stays deliberately small. The simplest structure that answers the real question, tested with the people who will use it before it is rolled out to anyone else. Then measurement, then adjustment, because the first version is always based on an assumption that turns out to be slightly wrong.
Governance is not the paperwork at the end. It is the first question. Who owns this process, which system is authoritative, what happens when the data is wrong, and who reviews the exception. If those answers do not exist, no tool will hold, and building one just moves the confusion somewhere newer.
In practice
Automation and AI
Automation should remove work that never should have been manual. It should not be added because the capability exists. The interesting question is never what the tool can do. It is what the organization is prepared to be accountable for.
Before anything is automated
Where a person stays
What earns automation
Taking a step back to understand the whole picture is not a delay before the real work. It is the part that determines whether what gets built is worth trusting.