In most companies, nobody knows how many hours disappear every week into tasks that require no decision at all. Retyping an order received on WhatsApp into the software. Sending the same stock summary every Monday morning. Checking, one by one, which references have dropped below their threshold. Telling a sales rep that a customer has not ordered anything in six weeks.

None of these tasks is hard. That is exactly the problem: they are too simple to deserve any thought, and too frequent to stay free.

Automation is not about replacing people. It is about removing from their day everything that requires no judgement, so that time is left where judgement actually matters.

Recognising an automatable task

A task is worth automating when it meets four conditions. If one is missing, automating it will cost more than it returns.

It repeats. It comes back every day, every week, or with every order. A one-off task should not be automated; it should be documented.

It follows an explicit rule. You can write it as "when X happens, do Y". If the answer depends on context, on the customer's history, or on the manager's instinct, the rule is not ready yet.

Its data already lives in the system. Automating a task whose data sits in a notebook or in one person's head is automating a void.

Errors are detectable. You must be able to see that the automation misfired, otherwise you have manufactured a silent error that repeats.

The five automations that pay off fastest

In order of observed return, these produce an effect within the first week.

1. Threshold alerts. The system continuously watches quantities and flags references that fall below their reorder point. Nobody opens a spreadsheet to look for gaps any more: the list arrives on its own.

2. Replenishment proposals. One step beyond the alert. The system does not just flag, it prepares a costed supplier order based on recent sales and lead time. A human reviews and approves. That is the right division of labour: the machine calculates, the person decides.

3. Scheduled reports that send themselves. The Monday morning summary goes out without anyone building it. The real saving is not the time spent producing the report — it is the disappearance of the report nobody remembered to send.

4. Anomaly detection. A sale at a negative price, an unusually large discount, a stock variance beyond a threshold, a stock movement outside opening hours. The automation does not judge, it flags.

5. Synchronisation between tools. An order placed online flows into stock with no retyping. This is the broadest topic of all, and it deserves its own article: your tools need to talk to each other through APIs.

Writing a rule that holds

An automation is designed in one sentence, before any configuration:

WHEN    a measurable event occurs
IF      certain conditions are met
THEN    perform a specific action
EXCEPT  in the listed exception cases

A concrete example:

WHEN    available quantity for a reference drops below its reorder point
IF      the reference is active and the supplier is not out of stock
THEN    create a purchase proposal and notify the buyer
EXCEPT  for references being phased out

The EXCEPT line is the one people forget, and it is the one that decides whether the automation survives. An automation with no exceptions fires an absurd action about once a month — and it only takes two absurdities before the team stops trusting it and goes back to the manual file.

Non-negotiable safeguards

Three rules prevent almost every accident.

An irreversible action is never fully automated. The system proposes, a human approves. Sending a firm order to a supplier, changing a price, deleting a record: these always keep a human checkpoint.

Every automation is logged. Who, or which rule, triggered what and when. Without a log, unexpected behaviour becomes impossible to diagnose and confidence collapses.

Every automation can be switched off in one gesture. A toggle, reachable without technical help. A rule you cannot stop is a rule you will not dare to switch on.

A four-week rollout

The classic mistake is trying to automate everything at once inside one big project. Those projects stall. Short increments work better.

  1. Week 1 — observe. Ask each person to write down the repetitive tasks in their week and how long each takes. The list almost always surprises the owner.
  2. Week 2 — pick one task. The most frequent one among those that meet all four criteria. One only.
  3. Week 3 — run it in observation mode. The automation runs but only notifies; it does not act. You compare what it would have done with what a human did. Forgotten exceptions surface here, at zero cost.
  4. Week 4 — switch it on for real, then move to the next task.

This pace looks slow. It is in fact the fastest, because it produces no rollbacks.

What not to automate

Some things are better left manual, and a misplaced automation destroys value.

Negotiating a price, settling a customer dispute, choosing a new supplier, deciding to drop a product line: these rest on information that is not in the system. An automation will handle them with apparent consistency and zero relevance.

A badly designed process gains nothing from automation either. It simply becomes a badly designed process that runs faster, and more often. Fix the process first, automate second.

Where the software fits

Automation is not measured by the number of active rules, but by the number of interruptions removed from a working day.

In G-stock, thresholds, alerts, replenishment proposals, scheduled reports and anomaly detection are configured per product family, per warehouse and per role. Every rule keeps its log and its off switch, and committing actions still require human approval.