Trigger, condition, action
Nearly every automation reduces to this shape. Something happens (a deal changes stage, a form is submitted, a date passes). A condition is checked (the value exceeds a threshold, the owner is unset). An action follows (a task is created, an assignment is made, an event is scheduled).
Understanding the shape makes automation design tractable: if you cannot state your rule in those three parts, it is not yet well enough defined to build.
Automate the reliable, not the judgemental
Good candidates are steps that are predictable, rule-driven and currently dependent on someone remembering. Creating an onboarding checklist when a deal is won. Assigning an inbound form submission to a queue. Scheduling a review when feedback is negative.
Poor candidates are steps requiring judgement about a specific customer. Automating those produces confidently wrong actions at scale, which is worse than the inconsistency it replaced.
Automation amplifies whatever it runs on
An automated bad process is a bad process executed faster and more consistently. This is the most common reason automation projects disappoint: the rule works exactly as specified, and the specification encoded an assumption nobody examined.
The sequence that works is to run the process manually until it is genuinely stable, then automate the parts that have stopped changing.
Keep it visible and reversible
Automation that acts invisibly erodes trust in the data. When a task appears with no explanation, people assume a colleague created it and act on wrong assumptions.
Rules should be inspectable by the people affected, their actions should be attributable in the activity history, and it should be possible to switch one off without a developer.