JJamie Blair
← All posts
StrategyAutomationMachine LearningGuide

Rules-based automation vs machine learning: which do you need?

6 min read

A clear breakdown of when to use simple rule-based automation and when machine learning is worth the complexity. Decision framework with real examples.

Intertwined gears and neural pathways depict selecting appropriate automation: simple scripts vs. complex AI.

Quick answer

Use rules-based automation when the logic is clear and consistent (if X then Y). Use machine learning when patterns are too complex for manual rules, the data changes frequently, or you need to handle ambiguity. Start with rules and only add ML where rules break down.

Not every automation problem needs AI. That sounds obvious, but it's a mistake I see constantly. A business has a repetitive task, someone mentions "AI", and suddenly the conversation jumps to machine learning models and training data when a 20-line Python script would have done the job.

The distinction matters because the two approaches have very different costs, timelines, and maintenance burdens. Picking the wrong one wastes money either way: overengineering a simple problem or underengineering a complex one.

Rules-based automation

A rules-based system follows explicit instructions. If X, then Y. There's no learning, no probability, no training data. You write the logic, it executes the logic, it does the same thing every time.

Examples:

  • "If a new row appears in the orders spreadsheet, send a confirmation email"
  • "Every Friday at 5pm, pull data from three APIs and generate a PDF report"
  • "If the invoice total doesn't match the purchase order total, flag it"
  • "Move files from the inbox folder to the archive folder after processing"

Tools: Zapier, Make, cron jobs, Python scripts, SQL queries, spreadsheet formulas.

Strengths:

  • Cheap to build (hours or days, not weeks)
  • Predictable: same input always produces same output
  • Easy to debug: you can trace every decision to a specific rule
  • No training data needed
  • Low maintenance

Weaknesses:

  • Can't handle ambiguity or variation
  • Brittle when inputs change format
  • Doesn't scale well to hundreds of edge cases
  • Can't improve over time without manual rule updates

Machine learning

An ML system learns patterns from data. Instead of writing rules explicitly, you provide examples and the model figures out the rules itself. It outputs probabilities, not certainties.

Examples:

  • "Classify this support ticket as billing, shipping, product, or other"
  • "Extract the line items from this PDF invoice (which could be formatted in any way)"
  • "Predict which customers are likely to churn this month"
  • "Detect whether this product review is positive, negative, or neutral"

Tools: scikit-learn, XGBoost, PyTorch, fine-tuned LLMs, cloud ML services.

Strengths:

  • Handles ambiguity and variation well
  • Can improve as more data becomes available
  • Works with unstructured data (text, images, PDFs)
  • Scales to complex decision-making

Weaknesses:

  • Needs training data (often hundreds or thousands of labelled examples)
  • Probabilistic: will sometimes be wrong
  • Harder to debug and explain
  • More expensive to build and maintain
  • Requires monitoring for drift over time

The decision framework

Here's how I think about it. Ask these three questions in order:

1. Can you write the rules down?

If you can fully describe the logic in an if/then flowchart and it stays under maybe 20-30 rules, use rules-based automation. You'll save time and money.

If the rules are too complex, too numerous, or too subjective to write down explicitly ("I just know when a ticket is urgent"), that's where ML enters the picture.

2. How messy is the input data?

Structured data with consistent formats (CSVs, database rows, API responses) is usually fine for rules. Unstructured data (free-text emails, PDFs from different suppliers, images) almost always needs ML, because the variation is too high for explicit rules.

3. Does it need to improve over time?

If the task is static and won't change, rules work great. If patterns shift (customer behaviour evolves, new product categories appear, seasonal trends change), ML can adapt where rules would need constant manual updates.

Note

The best systems often combine both approaches. Use rules for the predictable 80% and ML for the ambiguous 20%. This is cheaper, more reliable, and easier to maintain than going all-in on either approach.

Common scenarios and the right call

| Scenario | Right approach | Why | |---|---|---| | Send email when order ships | Rules | Clear trigger, no ambiguity | | Triage support tickets by topic | ML | Free text, subjective categories | | Generate weekly sales report | Rules | Structured data, fixed format | | Extract data from varied PDFs | ML | Unstructured, inconsistent formats | | Route leads to sales team by region | Rules | Clear criteria, structured data | | Predict customer churn | ML | Pattern recognition on historical data | | Sync data between two systems | Rules | Mapping fields, no judgement needed | | Detect fraud in transactions | ML | Complex patterns, evolving tactics |

The hybrid approach

In practice, the best automation systems use both. Take invoice reconciliation as an example. The data ingestion and normalisation stages are purely rules-based. The fuzzy matching on messy data uses ML. The reporting is rules-based again.

This layered approach means ML only runs where it's actually needed. The rest of the system is cheap, predictable, and easy to maintain.

Key Takeaways

  • If you can write the logic as a flowchart, rules-based automation is cheaper and more reliable.
  • ML is for ambiguity: unstructured data, subjective decisions, and evolving patterns.
  • The best systems combine both: rules for the predictable stuff, ML for the messy remainder.
  • ML needs training data, ongoing monitoring, and higher maintenance costs. Factor that in.
  • Start with rules. Add ML only when rules genuinely aren't enough.

Not sure which approach fits your problem?

It's a judgment call that depends on your data, your process, and your budget. If you'd like a second opinion, get in touch. I'll tell you honestly whether you need ML or whether a simple script will do.

Related reading: