Automation

Automating routine work: where to start

It's worth automating frequent, repeatable processes with clear rules. How to find them and why a process has to be described in words first.

A request for automation usually sounds like this: "staff are drowning in manual work, something needs to be done". The problem is real, but starting by choosing a tool is a sure way to spend the budget and keep the same routine. First you need to understand which actions actually repeat, what rules they follow and what happens if a rule fails.

Which processes are worth automating at all

Not all manual work pays back automation. A suitable candidate has three characteristics at once.

Frequency. The action is performed regularly — daily or several times a week. An operation that happens once a quarter is almost never worth the development and subsequent support: the rules will be forgotten and the script will go stale.

Repeatability. The same thing is done every time, with predictable steps. If every case is unique and needs a human decision, there's nothing to automate — you can only simplify data entry.

Clear rules. There's a precise condition: if a request of this type comes in, send it there, assign it to that person, set this status. If the answer to "how do you decide what to do next?" is "well, it depends", the process isn't ready for automation.

There's a fourth, less obvious characteristic: the cost of a mistake when done by hand. A forgotten email to a client, a request lost in a messenger, an invoice not issued — that's not just time but money. Such spots are worth closing first, even if the operation itself takes a minute.

Typical candidates in a services company:

  • collecting requests from all channels in one place;
  • notifying the people responsible about new enquiries and overdue tasks;
  • preparing standard documents from a template;
  • reminding clients about a meeting, a payment, an expiry date;
  • regular data exports and report building;
  • moving data between systems, which is currently done by copying.

Why you can't automate chaos

Automation doesn't create order. It fixes the existing order in code and makes it run fast and without exceptions. If a process currently relies on an experienced employee intuitively handling edge cases, automation will handle those cases wrongly — just at a larger scale and faster than a person would.

A typical picture: a department has three managers, and each works in their own way. One creates a deal immediately, another after the first call, the third once the client has confirmed interest. While it's manual work, the discrepancies even out. As soon as an automated scenario is built on top of this, reports start showing incomparable data, and notifications arrive at the wrong time.

Automation amplifies a process; it doesn't fix it. A bad process after automation becomes a bad process running around the clock.

So the first step isn't a specification but an agreement on how the process should be carried out. And carried out the same way by everyone.

What to describe before development

Before implementing anything, the process is described in words — on one or two pages, without development jargon. The minimum set of points:

  1. Trigger. What starts the process: a request arrived, a date came, a status changed, a file came in.
  2. Steps in order. What happens next, literally action by action. "The manager opens email, copies the phone number, creates a record in the CRM, sets the status to 'new'".
  3. Data. Which fields are needed at each step and where they come from. This is usually where it turns out half the data lives in personal correspondence.
  4. Decision points. Where the process branches, and on what basis.
  5. Owners. Who is responsible for each step and to whom a problem is escalated.
  6. Exceptions. What to do if data is missing, the client doesn't respond, an external system is unavailable. This is the most often skipped part and the most important.

The description almost always has a side effect: two or three steps become visible that aren't needed at all and are done out of habit. They should be removed before automation — there's no point automating an unnecessary step.

Rollout order

A sensible sequence looks like this.

Step one — measure the current state. Even roughly: how much time the operation takes, how often it's performed, where mistakes happen most often. Without this, you can't tell later whether things improved.

Step two — choose one process. Not three, and not the whole department at once. The best candidate for a first step is frequent, simple and with a clear cost of error. It gives a quick result and, more importantly, shows the team what this looks like in practice.

Step three — build a minimal version. Without a dream interface and without handling every rare case. The goal is to cover the main scenario and see what breaks in reality.

Step four — run it in parallel with the manual process. For a while, the scenario runs alongside people rather than instead of them. Discrepancies between the automated and manual results are your list of improvements.

Step five — plan for failure. External services go down, a key expires, the data format changes. Failures need to be visible: a notification to the person responsible, an operation log, the ability to retry a failed operation by hand. A silent failure is more dangerous than no automation, because everyone assumes it's working.

Step six — hand the process over to people. A short instruction, an understanding of where to look when there's a problem, and an assigned owner. Without this, the scenario will last exactly until its first failure.

Then the next process, in the same order.

Where people usually start

In our experience, the first steps are most often taken in one of three places.

  • A single intake point for enquiries. Requests from the website, messengers and email are brought into one system. Often it's a bot as an intake channel plus automatic record creation in the CRM.
  • Notifications and reminders. The cheapest class of task to implement and the most visible in effect: nothing gets lost simply because someone was reminded in time.
  • Data exchange between systems. Removes double entry — this deserves separate discussion, because integrations require their own discipline.

Practical checklist

Before commissioning automation, check point by point:

  • The process is performed regularly, not occasionally.
  • The steps repeat and can be described in words without the word "usually".
  • Branching rules are formulated and the same for all employees.
  • It's known what to do when data is missing and when something fails.
  • It's clear which systems are involved and whether they have access for data exchange.
  • A person is assigned to be responsible for the scenario after launch.
  • There's a way to measure whether things got better.

If even half of these points cause difficulty, start with describing the process, not with development. It's an unpleasant stage, but the cheapest one. Ready to discuss a specific task — write to us.