Lightweight automation: what you can automate without opening a project

When people talk about automation, the mental image is usually a project: a vendor, a budget, months of work. That image hides the most profitable and least discussed part: what you can already automate with the tools your company already pays for. Your email, your spreadsheets and your ERP or CRM ship with rules, templates and alerts that almost nobody switches on. The decision this article helps you make is when that is enough — lightweight automation, no project, no vendor — and when a small rule stops being enough. Whether it's too early to automate at all is a separate question with its own criteria; this article is the other half: where to start saying yes, in small ways.

What lightweight automation is — and isn't

Lightweight automation means delegating to a tool you already use a small, repetitive decision you currently make by hand: where this email goes, which values this cell accepts, which alert fires when an order changes status. It adds no new piece to your system: it switches on capabilities that were already there, paid for and dormant.

What defines it isn't the size of the saving but three properties: it takes minutes to set up, minutes to undo, and the person who uses it understands it. That last one matters most. A rule created by the same person who lives with it every day creates no dependency on anyone: if it gets in the way, they adjust it; if it stops being useful, they delete it. None of that is true of an automation project, which is why the two shouldn't be confused.

Where it lives: three layers you already pay for

Email

The repetitive work in email isn't writing — it's deciding. Deciding what gets read now, what gets filed, what gets forwarded to whom. All of that takes rules: sorting by sender or subject, moving admin traffic to its folder, flagging what comes from customers. And half the emails an admin team writes are variations of the same text: those are templates, the oldest and most ignored automation there is.

Spreadsheets

A shared spreadsheet without rules degrades on its own: free text where a closed list should be, dates in three formats, duplicates nobody notices. The same spreadsheets you already use let you restrict accepted values, highlight anything out of range, and flag duplicates as they're entered. This isn't automating the work — it's automating quality control on the data coming in, which is exactly where spreadsheets rot. The sheet goes from passive container to first line of defence.

The ERP or CRM

This is the layer with the most paid-for features lying asleep. Mandatory fields that would prevent half your incomplete-data problems, alerts when a record changes status, tasks created automatically when a stage closes. Almost no business system gets used beyond its minimum, and switching these rules on doesn't need a vendor: it needs someone in-house to spend an afternoon finding out what the tool the company has been paying for all these years actually includes.

Why this is not a project

The difference isn't just size — it's nature. An automation project needs requirements, vendor selection, testing, training: all of that makes sense when the cost of being wrong is high. In lightweight automation the cost of being wrong is close to zero: if the rule misfiles something, you fix it; if the validation gets in the way, you remove it. When undoing is free, trying is cheaper than analysing. So the right way to decide here isn't an upfront study — it's a small trial, on one task, this week.

That also changes who decides. A project gets approved by management; an email rule gets decided by whoever lives in that inbox. Handing that capability back to the team is part of the value: people who automate their own small tasks understand their processes better, and that understanding is exactly what any larger project will need later.

The signs it has stopped being lightweight

Lightweight automation has borders, and drifting across them unnoticed is the real risk. Clear signs:

• It crosses two systems. If the rule needs a piece of data to travel from email to a spreadsheet, or from the spreadsheet to the ERP, with someone copying in between, it's no longer a rule: it's an integration in disguise, with everything that implies.
• It needs exceptions that live in someone's head. If the rule works "except when…" and only one person knows the exception, you're not automating a process — you're freezing an unwritten judgement call.
• A silent failure would hurt. If the rule touches payments, orders or commitments to customers and could fail without anyone noticing, it needs monitoring that basic tools don't always provide.
• Nobody knows how many rules exist any more. Rules accumulated over years, created by people who have since left, form a ghost automation layer: nobody sees it, everything depends on it. A one-page inventory — which rules exist, who created them, what they do — saves you from inheriting a mystery.

When these signs appear it doesn't mean automating is a bad idea. It means the decision has changed in nature and deserves to be treated as what it is: a project, with a project's criteria.

Three questions before you create the rule

1. Does everything happen inside a single tool, with nobody copying anything in between?
2. Can you write the rule in one sentence, with no "it depends"?
3. If it fails, would you notice — and would the damage be small?

Three yeses: build it this week, without asking anyone's permission or calling it a project. Any no: that no is telling you exactly what kind of work you're actually looking at — an integration, an undefined process, or a risk that needs monitoring — and none of those three gets solved by an email rule.