Automation is not the starting point
When a process is repetitive, manual or frustrating, automation can look like the obvious answer.
Sometimes it is.
But “automate it” is not yet a problem definition.
Before deciding what technology should do, I want to understand how the work currently happens.
Who is involved?
What information moves?
Where are the handoffs?
Which steps are genuinely repetitive?
Where does work stop?
Where do people compensate for unclear rules or missing information?
What parts of the problem are caused by the workflow itself rather than the absence of automation?
Those questions matter because automation tends to preserve the logic of the process it is given.
If the logic is unclear, technology does not automatically make it clearer.
Understand how the work actually moves
A workflow is more than a list of tasks.
It includes people, states, information, decisions and dependencies.
Consider a customer process.
A customer enters the journey.
Information is captured.
Someone needs to respond.
A booking or request moves into another state.
Another person needs visibility.
Follow-up needs to happen.
Records need to remain consistent.
If any of those relationships are unclear, automating one step may simply move the friction somewhere else.
That is why I prefer to map the process before choosing the automation.
The aim is to understand the operating system around the task.
Find the real source of friction
Not every manual step is a problem.
And not every problem is caused by manual work.
Sometimes the issue is duplicated data.
Sometimes it is unclear responsibility.
Sometimes different people are using different versions of the same information.
Sometimes the workflow itself contains unnecessary steps.
Sometimes a system does not support the way the process actually needs to function.
Sometimes automation is genuinely the missing mechanism.
The analysis should distinguish between these situations.
Otherwise, teams risk solving the visible symptom rather than the underlying operational problem.
Define the future state
Once the current workflow is understood, the next question is:
What should the improved process actually look like?
That future state needs definition.
What should happen automatically?
What still requires human judgment?
What data must exist before the next step?
What state changes need to be visible?
What exceptions require intervention?
Which system or role owns each part of the process?
The Retail / Lifestyle Client work is useful here because it represents Design / Requirements evidence, not implementation evidence.
The work translated a fragmented, WhatsApp-led customer-management process into lifecycle definitions, requirements, acceptance criteria, future-state workflows, data handoffs, system-interaction definitions and integration requirements.
That creates a clearer future state.
It does not mean the automation was configured, deployed or producing live outcomes.
Those are different evidence stages.
Decide what should—and should not—be automated
Once the future workflow is clear, automation can be evaluated more intelligently.
A useful automation candidate is often:
- repeatable;
- rules-based;
- dependent on known information;
- frequent enough to justify intervention;
- and safer or more consistent when handled systematically.
But other steps may need judgment, conversation, exception handling or deliberate human control.
The goal should not be maximum automation.
It should be an appropriate operating model.
Automation is one design choice inside that model.
Distinguish design from operational use
This distinction matters when describing professional evidence.
Retail / Lifestyle demonstrates workflow and automation design requirements.
All Smiles Dental Clinic provides a different evidence maturity.
There, the wider work included customer and operational analysis, CRM/data restructuring, service-process redesign and supporting digital and automation workflows used within the operational environment.
Both are legitimate examples.
They simply prove different things.
One demonstrates how a future state can be analysed and defined.
The other includes evidence of implemented workflow change.
Treating them as identical would weaken both stories.
Attribute outcomes carefully
The same discipline applies to results.
At All Smiles, average patient waiting time reduced from 42.5 minutes to 11 minutes during the five-month monitored improvement period, a 74% reduction.
That is meaningful evidence.
But the evidence does not support saying:
automation caused a 74% reduction.
The monitored improvement occurred within a broader CRM/customer-operations/process-improvement intervention involving changes to data, workflows, service processes and supporting automation.
When several parts of an operating system change together, outcomes should be described within that wider intervention unless the evidence isolates a specific cause.
That is not weaker storytelling.
It is more accurate analysis.
The takeaway
Automation should not be the first question.
The stronger sequence is:
understand the process → identify the friction → define the future state → decide where technology genuinely improves the workflow.
Sometimes the answer will include automation.
Sometimes the biggest improvement will come from clearer ownership, better information or a simpler process.
The professional skill is not finding something to automate.
It is understanding the workflow well enough to know what should change.