Process Before Automation
Whether AI, a new platform, or new tool, don't ignore this critical step when automating a workflow.
When a workflow feels clunky, it’s tempting to start looking for new tools - a slick new platform, a better tool, AI, the software equivalent of a fresh start.
But the real fix usually starts somewhere else: understanding what’s actually happening beneath the surface. If you skip that step, you’re likely to treat the symptom, not the cause.
It’s like replacing all your light fixtures when the problem is faulty wiring. Flashy fix, same old flaw.
Before you overhaul anything, pause. Assess what’s actually happening. Understand what you already have and what it really needs.
Step 1: Get clear on the goal
“The process is inefficient!”
“This platform is ancient - it’s time for an upgrade!”
Valid frustrations. But not goals.
A good goal gives you direction. It’s something clear - a specific, actionable outcome - that you can work toward and use as a gauge for whether a change is having an impact.
For example:
“We need to shorten the time between content submission and publishing.”
“We want to eliminate manual data errors.”
“With AI’s capabilities, let’s rethink how we deliver client value on this part of our service.”
Before making any changes, ask: What are we really trying to accomplish?
Speed? Accuracy? Better value? Less frustration?
If no one can give you a clear answer, your job might be to help shape that goal. You can’t fix a process - or choose a tool - if you don’t know what problem you’re solving.
Step 2: Map the people and the process
People are great at describing their pain points. The hard part is figuring out what is actually causing them. That’s where mapping helps.
Why mapping matters:
It reveals disconnects and redundancies.
It surfaces silent pain points.
It gives you clarity - and credibility.
In siloed organizations, one team may offer a detailed view of a single step, but not how that step fits into the broader picture. But without the full context, you can end up solving the wrong problem entirely.
Tips for documenting workflows
If you’re lucky, your teams already have documentation. If not, or if it’s outdated, roll up your sleeves!
Try this:
Shadow people as they perform common tasks.
Make it clear you’re observing, not evaluating.
Ask: “Who does this task? What happens next? Who touches what system, and when?”
Diagram hand-offs. Make it visual. Review with the people who do the work.
Accuracy matters! These diagrams are not just for clarity. They become the foundation for tool evaluations or change management later on.
(Pro tip: Workflow diagrams are a great way to bring objectivity when operating in a low-trust or “finger-pointing” environment.)
Step 3: Analyze and quantify
Now that you have goals and workflows, dig into what you’ve learned.
Ask:
Where does time pool up?
Are there steps we can skip or streamline?
Where do delays or mistakes happen most?
Do certain approvals always slow things down?
Look for patterns:
Bottlenecks
Points of friction
Risky or error-prone hand-offs
Bright spots that could scale or add significant value
Focus on moments in the workflow where a small change could have a big impact. These are your biggest potential opportunities for automation.
Step 4: Pinpoint needs, priorities, and risks
With real data in hand, start identifying:
What needs to change?
What’s a process issue vs. a tool issue?
What are the benefits and risks of each path?
With this information, you can evaluate your real options.
Example:
A research team pushed for a new data platform to fix persistent errors. But when they mapped the workflow, the real issue turned out to be inconsistent formatting in client-submitted spreadsheets. Research analysts and data operations were using different templates.
The solution? Align the templates. The errors disappeared. No new system required.
Takeaway: Sometimes the fix is smaller, cheaper, and right under your nose.
The real cost-benefit calculation
Automation projects require money, time, and people. But most teams only ask one question:
“Is the benefit worth the cost to build?”
That’s too simple.
When you evaluate automation, you need the full picture:
a) Build cost (what everyone sees)
Development time
Tools / platforms
Internal or external resources
b) Implementation cost (what gets missed)
Training your team or clients
Rolling out new workflows
Supporting adoption across the organization
c) Opportunity cost (what no one talks about)
What are your people not doing while this is happening?
For example, a sales team learning a new forecasting automation tools isn’t meeting prospects. That’s pipeline you’re trading for process.
Don’t get us wrong - automation can absolutely drive value. But only when you weigh it against everything it displaces.
Too often, teams underestimate effort, overestimate speed to value, and ignore the hidden costs of change.
A better question to ask.
Instead of:
“Should we automate this?”
Ask:
“Is this the highest-value investment, right now?”
Step 5: Get ready to recommend and present
By now, you have done something powerful: not only have you identified a problem, but you have built shared understanding around it.
When you present:
Don’t go for a dramatic reveal. Show how you arrived at your recommendations.
Share your findings to test understanding.
Walk through assumptions and risks.
Invite feedback. Clarify tradeoffs. Be honest about what is still uncertain.
Frame your presentation as a shared discovery, not a pitch.
What makes you invaluable
You don’t need to be an AI or systems expert to lead this kind of change. Curiosity, persistence, and thoughtful observation go a long way.
The hard part is taking the time to understand what’s really happening. It’s the step many teams skip, yet makes the difference between a failed automation effort and a lasting one.
This kind of attention doesn’t just improve processes. It builds lasting value, clarity, and alignment. And that’s what makes your work truly invaluable.
There's definitely an art to documenting workflows, which I sort of did for one of my consulting projects via 1:1 video interviews (which sufficed for my use case, but I could imagine there are times when you have to see someone operating widgets first-hand because it's pocedural muscle memory they can't put to words easily)