What should we automate first?
Pick something frequent, boring, triggered by a clean event, and harmless when it goes wrong. That usually means writing call outcomes back into the CRM, following up on missed calls, or generating a daily summary from data you already have. Do not start with anything that touches the schedule, money, or a customer promise. Your first automation should be one where the worst case is a wasted minute.
Four filters, applied in order
- Frequency. Something that happens many times a day. Automating a weekly task saves nothing and teaches you nothing.
- Clean trigger. A specific event exists in a system you control: call ended, job completed, form submitted. If you cannot name the trigger, you are not ready.
- Single system of record. If two systems disagree about the underlying fact, fix that first. Automation on top of ambiguous data multiplies the ambiguity.
- Low blast radius. If it fires wrongly a hundred times overnight, what happens? If the answer involves customers or money, choose something else for number one.
Good first candidates
The pattern that consistently works is capture and summarize — taking information that already exists in a call, a form or a job record and putting it somewhere useful in a structured way.
Writing a structured call outcome back to the CRM is the archetype: it happens constantly, it is triggered by call completion, the record is unambiguous, and a bad summary costs someone ten seconds. Daily operational summaries are similar — they read data and produce a message, touching nothing. That is the whole idea behind daily intelligence briefs.
Bad first candidates, however tempting
Automated quoting, automated scheduling changes, automated discounting, automated review requests without suppression rules, and anything that sends a message to a customer without a human ever having seen the pattern. These are not bad ideas. They are bad first ideas, because they fail in ways that reach customers before they reach you.
The sequencing logic is simple: build the observation layer before the action layer. Once you can see what the system would have done, you have earned the right to let it do it. That staging is core to how we approach operational AI.
Set a success condition before you build
Write down what you expect to be true in thirty days — a specific reduction in manual entry, a specific record that is always populated, a specific report that no longer gets built by hand. Without that, the automation becomes something everyone assumes is working because nobody complained.
Then check it. The most common outcome of an unmeasured first automation is that it silently stopped firing weeks ago. Monitoring is part of the build, not a later phase, and it applies to every workflow you add after this one.
Topics: automation · prioritization · first project · risk
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.