Where to start with business automation so it pays back

How do you choose the first process to automate?

A good candidate meets four conditions at once: it happens at least weekly, its rules fit on one page, the data already lives in some piece of software, and mistakes are easy to spot. If one of these is missing, park it and move to the next item on the list.

This filter rules out most of the tempting projects for now: the AI sales assistant, the forecasting model, the one system for everything. They can come later, once the simpler processes underneath produce clean data. Plumbing first, everything else after.

The second filter is pain. Ask people what they do on the last day of the month, or on a Friday afternoon when everyone wants to go home. It's almost always retyping, checking and stitching reports together from several sources. Those are your candidates.

How do you work out what manual work costs today?

One formula is enough: hours per month times the full cost of an hour, plus the time spent fixing mistakes. Payback is the implementation cost divided by the monthly saving minus running costs. It takes fifteen minutes on the back of an envelope.

1. Hours per month: people × weekly hours each × 4.33 (52 weeks divided by 12 months).
2. Add the hours that go into finding and fixing errors every month.
3. Saving: total hours × the share of the work automation takes over × full hourly cost.
4. Payback in months: implementation cost ÷ (monthly saving − monthly running cost).

The full hourly cost isn't the rate in the contract. Add employer contributions, holidays and absence to the salary, then divide by the hours actually worked. It usually comes out well above the number you have in your head.

Here's an example. It's an estimate, not a result from a real company: three people retype orders from emails into the system, six hours a week each. That's 78 hours a month. If automation takes over 70% of it, you get back about 55 hours. At a full cost of PLN 70 an hour, that's roughly PLN 3,800 a month. My automation projects start from PLN 15,000 excl. VAT, so at that price the process pays back in about 4 months, and a project twice the size in about 8.

You can plug the same numbers into the automation savings calculator. It uses this formula and shows the month in which you break even.

My rule of thumb: if the first process doesn't pay back within a year, I look for another one. Almost every company has one that pays back faster.

Measure the starting point too. When I built the delivery run for supplies at Reefa, I first checked how long it took on average from order to delivery on site: 9.4 days. Without that number you can't honestly say later whether anything improved.

Which processes pay back fastest?

The fastest paybacks come from work nobody likes and that needs no judgement: matching payments to invoices, client reports, payment reminders, copying enquiries into the CRM and collecting data from the field. Because it's boring, people leave it until last and get it wrong.

The common thread: the data already exists somewhere, and a person is just moving it by hand. That's the cheapest work to take away, because it needs neither a new system nor a new way of working.

An example from Reefa: three boring processes I'd start with again

Reefa is my cleaning company. Since 2020 it has looked after offices, medical facilities and residential buildings in Kraków, and since 2024 in Katowice as well. I've automated a lot there, but if I were starting over, these three would come first.

Bank and invoices

There's one rule: every transaction on the account needs cover. Money in needs an invoice, money out needs a cost document. On the first day of each month the system goes through all transactions on our bank accounts, matches them to invoices from inFakt, and anything it can't match shows up in red and is sent to me on Telegram.

Most of the effort didn't go into the matching itself but into the exceptions. An invoice number can be split across two lines of a bank statement. The same transfer sometimes arrives twice, once from an MT940 file and once through the bank connection. Without handling cases like these the automation would raise false alarms, and within a week nobody would read it.

I imported the cash register and reconciled it against the documents the same way: 312 entries across 21 closed months, down to the last grosz. Before trusting the result, I checked it against 14 cash withdrawals that someone had reconciled by hand earlier. Every one of them matched.

Monthly client reports

Every client gets a PDF report by email on the fifth of each month. Nobody puts it together by hand. Visits come from the schedule, and Polish public holidays up to 2030 are built into the calendar, so the system doesn't count visits on days off. The module was built in early September 2026, and I switched sending on for all clients on 16 October.

Photos and hours from the field

Staff don't log in to any panel. They start and finish shifts in a Telegram bot, with location and photos from the site. In August 2026 it handled 1,100 hours of work across 364 shifts, and the system now holds more than 2,800 shift photos.

This process taught me two things. First, automation is exactly as good as the data that goes into it. In June roughly half of the planned visits went through the bot, so the reports for that month showed only part of the picture.

Second, you look for bugs in the data, not in the code. When photos kept disappearing at one site, the logs showed no errors at all. Only lining up the timestamps showed that in 17 of 24 shifts the last photo arrived 0–1 seconds before “Finish” was pressed, so closing the shift overtook the upload. The fix was simple: a 15-⁠minute window to finish sending photos, and no closing a shift without photos unless the worker explicitly chooses to.

Both are described in more detail in the case studies on an operating system for a service company and a bot for the field team.

What usually breaks a first automation?

Mostly it's what happens before the first line of code: automating a mess, buying a tool before describing the process, and nobody owning the process. The technology is rarely the problem.

• You automate a mess. A bad rule inside an automation just repeats faster and more often. Fix the rule first, then automate it.
• You buy a tool before describing the process. The process then bends to fit the tool, and a quarter later the team is back in a spreadsheet.
• Nobody owns the process. You need one person who knows how it should work and gets the alert when it stops.
• You start with everything. “Let's automate sales” is a six-month project. “An enquiry from the form lands in the CRM with the tax ID and scope” takes a few weeks.
• You don't measure the starting point. Without a number from week one you can't prove anything got better.
• There's no path for exceptions. Every automation eventually meets a case it doesn't know. It should stop and ask a person, not guess.
• The new way is harder than the old one. People route around anything that takes more clicks than before. I rewrote the Reefa bot around a “one button” model after an audit found 55 confirmed issues. One of them made the bot ask the same question twice.

What does a 30-⁠day plan look like?

I split the first 30 days into four stages: a week of measuring, a week of rules, ten days of building and just under a week running in parallel. At the end you compare the numbers from week one with what the automation shows, and only then do you switch off the old way.

Testing on last month's data is the cheapest check I know. You already know the correct answer, so every difference shows up immediately. That's how I checked the cash reconciliation before I trusted it.

If on day 14 it turns out the rules won't fit on one page, that's a result too. Better to find out after two weeks than after the budget is spent.

When doesn't automation pay off?

It doesn't pay off when the process is rare, changes every month, or when the real problem is a missing decision rather than a missing tool. If nobody in the company knows who approves discounts, automation won't settle it. Agree the rule first, then automate it.

Sometimes you don't need to build anything at all. Switching on a feature in software you already have, or connecting two tools with an off-the-shelf integration, can be enough. If you're weighing up a system of your own, read how to choose between a custom system and an off-the-shelf tool. If AI is part of the plan, see the guide to AI in small and medium businesses.

If you'd rather go through this choice with your own processes, start with the free AI readiness assessment or book a 30-⁠minute call. Scope and prices are on the process automation page.