If you're asking how to start automating your business, the honest answer is that you don't start with a tool. You start with a stopwatch. Most teams skip straight to comparing software, sit through four demos, then pick whatever the loudest vendor promised, and six months later the tool is half configured and nobody can say what it actually saved. This guide gives you a five day method for finding where your business actually loses time, before you evaluate a single tool.
Begin with the hours, not the software
The first move is measurement, not procurement. You are not looking for a list of apps to try. You are looking for a list of specific, repeated tasks that cost your team real minutes every week, because that list is what tells you which tool, if any, is worth buying.
This matters for a specific reason: software gets sold on features, but it earns its cost back on frequency. A tool that saves 40 minutes on a task you do twice a year is a rounding error. A tool that saves 5 minutes on a task you do 60 times a week just bought back five hours. The sequence is the same whether you're cutting manual data entry or running an ecommerce business: find the repeated task first, then match a mechanism to it.
Skipping this step is why so many automation projects stall. The team builds against a guess instead of a number, and the return never shows up on a P&L anyone checks.
Run a five day time log before you touch any tool
Put a shared sheet in front of every person who touches sales, marketing, or operations admin. For five working days, every time someone retypes data, chases a colleague for an update, rebuilds a report from scratch, or copies something from one system to another, they log it. Four columns is enough:
- Task: what they did, in a few words ("re-entered order into CRM from email")
- Minutes: how long it actually took, not a guess made afterward
- Trigger: what caused it (a new lead, a customer email, a Friday deadline)
- System: which tool or tools it moved between
Five days, not one, because Monday and Friday behave differently and a single day will miss your monthly reporting crunch or your Tuesday quoting rush. People are bad at estimating this kind of time in a meeting, they round down without meaning to. Watching it happen in the same week it happens gives you the real number instead.
Expect fifteen to thirty rows per person by Friday. That log is the only input the next three steps need.
Why frequency beats pain when you choose what to automate first
Once the log is full, resist the urge to automate whatever made someone the most furious. Pain is a bad sorting mechanism because it is not correlated with cost. Sequence by three things, in this order: how often it happens, how much judgement it requires, and how stable the rules are.
Frequency first because it is what pays for the build. Low judgement second because a rule based task can be automated with a simple flow, while a task like "decide if this customer deserves a discount" needs a human. Stability third because a workflow that is right today and wrong next quarter will need constant rework, and rework is what turns a one time build into an ongoing cost.
Take lead response time as an example. A new lead notification is high frequency, requires no judgement to route to the right rep, and the rule barely changes. That is exactly why lead follow-up shows up early on most automation backlogs and something like pricing exceptions does not.
Score each task on paper
You do not need software to rank the log. Multiply three numbers for each row:
- Weekly occurrences: how many times it happened across the team in five days, scaled to a week
- Minutes per occurrence: the average from your log
- Rule stability: score 1 if the rule changes monthly, 2 if quarterly, 3 if it has not changed in a year
Multiply occurrences by minutes, then multiply that by the stability score. The highest number on the page is your first candidate. It's the same arithmetic as costing manual work company-wide, just done at the task level. If you manage a shared inbox, the same log works there too: track which replies are templated and repeated, not the ones that need a real answer, and those are the ones worth automating first.
Carry the minutes to a real yearly number
Here is a worked example, and the assumptions are part of the answer, not a footnote. Say your log shows order confirmations retyped into your CRM 40 times a week, at 6 minutes each. That is 240 minutes, or 4 hours, a week. Over 48 working weeks that is 192 hours a year. At a fully loaded cost of EUR 35 an hour for the person doing it, that is EUR 6,720 a year on one task.
Change any input and the number moves: fewer occurrences, less cost; a higher loaded rate, more cost. That is the point of doing this on your own log instead of trusting a number from a case study that used someone else's headcount and someone else's hourly rate. If you want to run this against your own figures without doing the multiplication by hand, our cost calculator does the same arithmetic on your numbers.
Four jobs to leave alone for now
Automating the wrong task doesn't just waste a build, it can actively make things worse. Four to leave alone until later:
- An undocumented process. If nobody can write down the steps consistently, you cannot automate it, you can only guess at it.
- A task that happens twice a month. Low frequency means a slow payback even if the task itself is painful.
- A workflow that is broken, not slow. Automating a broken process just produces wrong answers faster. Dirty CRM data is the classic version of this: duplicate contacts, missing fields, and stale stages. Cleaning that up is a data project, not an automation project, and it has to come first. Fix that before anything downstream reads from it.
- Rules that change every quarter. You'll spend more time rebuilding the automation than the automation ever saved. Keeping CRM data current matters more here than any new tool: a single source of truth has to exist before anything else gets built on top of it, and cleaning up customer data is worth solving on its own before it becomes an input to an automation.
What happens after the automation ships
An automation is not finished when it goes live. It's finished when someone owns it. Without an owner, small things drift, a field gets renamed in your CRM, an API key expires, a form adds a question, and the automation keeps running on the old assumption.
The dangerous failure is a silent one. A manual process that breaks gets noticed the same day, because a person is doing it and a person notices when something's wrong. An automation that breaks quietly can run incorrectly for a month before anyone checks the output, because nobody was watching it in the first place.
The fix is simple to state and easy to skip: every automation, whether it is an n8n workflow or a script inside your CRM, should report its own failures to a named person by email or Slack the moment it fails, not when someone happens to audit it. Build that reporting in from day one, not as a later improvement.
Pick one job, two weeks, one number
Do not try to fix everything the log surfaced at once. Pick the single highest scoring task, give it two weeks, and pick one number it is supposed to move before you start.
Good numbers to track, depending on the task: minutes saved per week measured against your original log, first call resolution rate if it touches support, or lead response time if it touches sales. Both of those are just before and after comparisons against the baseline you already logged. Write down what "done" looks like in one sentence before you build anything: "leads get a reply within 5 minutes, down from an average of 4 hours." At the end of two weeks, check the number, not your impression of how well it went.
If the first one works, the log already tells you the second task, and the third. Order and data entry and weekly reporting are two of the most common places this method points to, and the full list of use cases we build most often is worth a scan once your own log is ready. order and data entry · weekly reporting · the full list of use cases
Common questions
What's the very first step in automating a business?
Run a five day time log across your team before evaluating any software, so you know where the hours actually go.
How do I decide which task to automate first?
Score each logged task on how often it happens, how many minutes it takes, and how often the rules change, then start with the highest frequency, lowest judgement, most stable one.
Does this approach work for an ecommerce business?
Yes, the log and scoring method are the same whether you're automating an ecommerce business or a service company, only the tasks on the list change.
What's the biggest mistake people make when they start automating?
Automating a process that's broken rather than slow, which just produces wrong answers faster instead of fixing anything.
If your log is full and the highest scoring row is bigger than you expected, that's usually the moment to score the whole backlog on value against effort and put a fixed price on each build, rather than guessing at order alone. That's the part of the job we do for a living.
