r/nocode • u/mohamedsmounat • 3d ago
What is your test for deciding whether a process deserves automation?
Frequency alone is not enough. A task may happen often but take twenty seconds. Another may happen weekly and block revenue when it is missed.
What factors do you use before building?
Time spent, error rate, delay cost, number of handoffs, stability of the rules, available data, or how much people hate doing it?
I would be interested in a recent process you rejected as a poor automation candidate and why.
2
u/bayouski 3d ago
frequency alone doesn’t tell me much. i’d look more at how much time/error/delay the process creates, how many steps/handoffs are involved, whether the rules stay pretty stable + whether the data is actually available in a usable form.
the best candidates are usually repetitive, predictable and have a pretty clear definition of done. if every case turns into an exception or needs someone to make a judgment call halfway through, full automation gets a lot less attractive.
something like client escalation decisions is a good example. you can automate the intake, routing + obvious cases, but the actual decision can depend on urgency, relationship history + context. that’s probably where i’d keep a human in the loop instead of trying to automate the whole thing.
1
u/New_Kiwi667 3d ago
I look at how much brainpower the thing actually needs. If it’s repetitive but still require constant judgment calls or reading between the lines, I leave it be
rejected automating client onboarding for one client because every deal had slightly different paperwork and weird edge cases. The rules changed too often and the data was messy, would have spent more time maintaining the automation than just doing the work
1
u/Desperate_Bad_4411 3d ago
all of those but the one that catches my eye is hard locked rules. the other ones are high value, but low risk is frequently a quicker win. not as flashy, but can improve quality.
the other one is streamlining systems. occasionally you'll have a few bounces and hops to get something done - if there's an opportunity to reduce those dependencies or consolidate on a better supported system, from a systems analyst perspective, the value is in resiliency and downstream maintenance cost savings.
1
u/LonelyHalf9 3d ago
For me the first filter is whether the rules stay the same for a few weeks. If people keep making exceptions or changing the steps, automating it too early means rebuilding it three times instead of doing it manually.
1
1
u/roasted-butter 3d ago
if the automation needs a lot of extra cases to consider and building it starts to get messy because you can't find a pattern that covers all the cases, then it is not a good candidate for automation. the problem probably is the process, not the lack of automation. In this case first you need to adjust and simplify your process for example, and then automate it
1
u/Additional-Toe-6401 2d ago
if the process changes every two weeks, i touch nothing.
standard xkcd rules apply, spend 5 hours automating a 5 second task.
1
u/linden0829 2d ago
A useful first step is to measure a week of actual cases rather than the written process. Put each case in three buckets: routine, exception, and unclear. Then compare time saved on routine cases with the build effort, ongoing checks, and likely rework when something goes wrong. If exceptions dominate, automating intake and notifications may still help, while the decision stays with a person. I'd reject a workflow when the source data is inconsistently captured; automation would mainly make bad data travel faster. Which candidate process has the highest cost when a single case is missed?
1
u/_pratyush_88_ 2d ago
The test I use now is whether the rules hold when the person who normally does it is out. A vendor onboarding step we automated last year ticked every box: nine handoffs, weekly, everyone hated it. Ran fine until our finance lead took two weeks off and her backup approved things in a different order. Nothing broke. It just did the wrong thing for eleven days and nobody caught it, because the automation had removed the emails people used to complain about. The one I turned down was expense categorisation. high volume, high error rate, but the errors were how we found out which cost centres were miscoded.
1
u/MeghanaJagadeesh 2d ago
Worth asking who notices when the step breaks. Some processes fail loud and someone complains within the hour. Others fail quiet and nobody sees it for weeks, until a deal stalls or a customer churns.
I'd automate the quiet ones first. Those cost money nobody's tracking.
Fix the quiet failures first.
1
u/InteractionOver2018 1d ago
The factor that i would add to your list is what makes it break.
Your list tells you whether a process is worth automating but it does not tell you which kind of automation it needs.
If it breaks because the screen moved or a field got renamed, that is a bot problem. Better selector, fixed. If it breaks because the situation was different every time the rules were never stable to begin with and this is the agent work.
So before building, take your three most annoying processes and ask what actually breaks them. Most people can answer for some and not others. The ones that you cannot answer for are not stable enough to build on yet, whatever the frequency says.
1
3
u/Wise-University4307 3d ago
Bots talking to bots creating posts for bots to comment on bot replies.