Hamza AkbarWhich tasks should a team automate first?
Start with what the team is already struggling with, not with a tool you want to try. In my case the signal is usually one of two things: a client asking why something takes so long, or an SOP people keep skipping.
- Tasks that repeat every week
- Checking, tracking and reminders
- Routing work and status updates
- First drafts and summaries
- Client conversations and relationships
- Creative work
- Judgment calls that need context
- Strategy and growth ideas
Our brand managers were spending a big part of every week on Amazon support cases and inventory checks. It had to be done, but it never moved an account forward. I automated those two jobs and left the rest of their work alone, so their time goes to growth work instead.
I only build for problems I've seen the team run into. And the point of automating the first list is to give people more time for the second.
Why does a team keep skipping the SOP?
When people keep breaking an SOP, it's usually too expensive to follow. I don't assume they're lazy. I assume following it costs more than skipping it, and I go and find out why.
So I work on making it cheaper to follow.
How do I know the team will actually use it?
It's common to build an automation or buy a tool and watch the team ignore it. Every tool I build has to pass two tests.
Everything the task needs sits in one place, on tools the team already uses. If someone has to jump between the tool, a sheet and Slack to finish one job, they'll go back to the old way.
The team only uses it if they believe it. So I check accuracy against real results before launch, never on sample data. If the first numbers look wrong, it's hard to win people back.
After launch, the first thing I check is whether people use it without being chased. Only then do I look at whether the task got faster.
Two examples
Example 1Weekly client updates
We had an SOP and a format for weekly client updates. Few went out on time, and every one looked different. So I stopped chasing people and made the update quicker to send. Every Friday at midday, each team member now gets a pre-written, structured update built from their tasks. They read it, adjust it and send it.
Compliance went up because the friction went down, not because anyone enforced it harder.
Example 2Amazon support tickets
Amazon was replying to our support tickets, but nobody noticed in time, and the tickets closed on their own after the response window. We only found out because clients told us things felt slow. Every dead ticket meant days of waiting started over, and the client concluding nothing had been done.
The fix was small. The owner adds the ticket ID once, which takes about 10 seconds. A watcher checks the inbox for replies, and the owner gets a Slack message the moment one lands. It runs on email and Slack, with no new software to buy.
What broke
I haven't figured this out. One of my sync scripts once wiped hundreds of rows from a master sheet. I rebuilt it so it can never clear that sheet again.
Now, before any code, I write down what a correct result looks like, and I check the output against real results before the team relies on it.
A checklist for your own week
Run each recurring task through these questions:
- Does it come back every week or month, with the same steps each time?
- Can you point to a time it went wrong, or a client who noticed?
- Does it need judgment, or a relationship with the client? If yes, keep it with people.
- Is there an SOP for it that people skip? Find out what makes it expensive to follow.
- Could the system run on tools your team already uses, in one place?
- Can you check its output against real results before the team relies on it?
If a task gets a yes on the first two and a no on the third, it's a good candidate.
Got a process that keeps slipping?
Tell me about it. I'll tell you honestly whether a system would help.