Jae coordinates intake for a support team, and part of the job is entirely mechanical: when a ticket moves to "Needs Review," reassign it from the intake queue to whichever specialist covers that category, then post a note so they know it's waiting. It's not hard work, it's just work that has to happen every single time a status changes, dozens of times a day, and it's exactly the kind of task a human eventually forgets to do at 4:45 on a Friday.
The busywork inside the busywork
A lot of what looks like "process" on a team is really just a status change followed by a predictable, mechanical reaction to it: reassign, notify, set a field, move it to the next list. None of that requires judgment, it requires noticing that the status changed and then doing the same three clicks every time. That's precisely the part a rule can do instead of a person.
What an automation actually is
An automation here isn't a flowchart builder with branches and conditions you need documentation to understand. It's a rule simple enough to read out loud: when a task hits a status, move it, assign it, or set a field. That's the whole vocabulary. It's deliberately narrow, because the goal isn't to replace judgment, it's to remove the mechanical steps that don't need any.
Three starter rules worth setting up
- Status to assignment: when a ticket moves to "Needs Review," automatically assign it to the specialist queue for its category, instead of a person doing that lookup by hand each time.
- Status to field: when a task moves to "Done," automatically set the completion date field, so nobody has to remember to fill it in for the report at the end of the month.
- Status to list: when a bug is marked "Fixed," move it out of the active sprint list and into the QA list automatically, instead of relying on someone to notice and drag it.
Why small and readable beats powerful and complicated
It's tempting to want an automation system that can do anything, but a rule nobody can predict the behavior of is worse than no rule at all, because now something is happening and nobody's sure why. A rule that reads as "when X, do Y" is one a new team member can understand in a sentence, and one Jae can audit in the activity history when something looks off, instead of debugging a hidden branch of logic three conditions deep.
What it actually saves
None of the three rules above save a dramatic amount of time individually. What they save is the accumulation: the version of Jae's day where forty tickets each need a manual reassignment and a manual note, versus the version where that happens on its own the instant the status changes, and Jae's actual job becomes the reviews and judgment calls a rule was never going to be able to make anyway.