Most "Machine Learning" Is a Spreadsheet You Won't Admit To

A few years ago I sat through a vendor demo of a “predictive maintenance AI” that flagged which servers in a rack were likely to fail. The slide deck had a neural network diagram on it, all glowing nodes and confident arrows. I asked to see the actual model file. It was a gradient-boosted tree with nine features, three of which were disk temperature averaged over a week, disk age in days, and SMART reallocated-sector count. I could have built the same triage logic in a spreadsheet with three IF statements and a weighted average, and it would have flagged the same three drives the vendor’s tool flagged in the pilot. The AI framing sold the contract. The actual mechanism was arithmetic I’d been doing manually for years.

That’s not a knock on gradient boosting, which is a genuinely useful technique. It’s a knock on the habit of reaching for “machine learning” as a label rather than a diagnosis. Most business problems that get an ML label are, underneath, one of three things: a lookup table built from historical averages, a linear or logistic regression fit to a handful of numeric features, or a threshold rule someone tuned by eye and then had a model formalise. Knowing which one you’re actually dealing with tells you how much infrastructure the problem deserves, and how much you should trust the output when it’s wrong in a way nobody predicted.

The pitch versus the pipeline

The pitch for machine learning is generalisation: give the system enough examples and it learns a pattern too complex for a human to write down as rules. The pipeline that actually ships is usually much narrower. Take churn prediction, one of the most common “ML use cases” in any SaaS product. The features that carry almost all of the predictive power are days since last login, number of support tickets in the last 30 days, and whether the last invoice failed. A logistic regression on those three columns typically gets within a percentage point or two of whatever a random forest or gradient-boosted model achieves on the same data. The forest adds complexity, training time, and a model file you can’t read in a text editor. It rarely adds enough accuracy to justify the cost, and the three-variable logistic regression can be reduced, coefficient by coefficient, to a formula anyone in finance already understands: a weighted sum of inputs, run through a curve that squashes it between 0 and 1.

I’ve watched this pattern repeat across recommendation (“show more of what this user’s cohort already clicked” is a groupby and a sort), fraud scoring (“flag transactions more than three standard deviations from this account’s usual pattern” is a rolling mean and a threshold), and demand forecasting (“next week probably looks like this week adjusted for the day-of-week effect” is a seasonal average, not a neural network). None of that is an accusation that the industry is lying. It’s a description of where the actual difficulty in these problems lives, which is almost never in the model class. It’s in getting clean, timely, correctly-joined data into a table in the first place. The join is the hard part. The regression on top of the join is comparatively trivial, however impressive the word “model” makes it sound in a board deck.

What a lookup table can already do

Here’s the exercise I run on every “we need an ML model for this” request before agreeing to build one: I ask what the simplest possible baseline would be, and I build that first. For churn, the baseline is a lookup table keyed on the same three variables, bucketed into deciles, with the historical churn rate for each bucket stored as a plain average — no model at all.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

import pandas as pd

# baseline: a bucketed lookup table, not a "model"
bins = pd.qcut(df["days_since_login"], q=10, duplicates="drop")
baseline = df.groupby(bins)["churned"].mean()

# score a new customer by finding their bucket
def score(days_since_login):
    bucket = pd.cut([days_since_login], bins=baseline.index.categories)[0]
    return baseline.get(bucket, df["churned"].mean())

That’s eight lines, it’s fully auditable by someone who has never opened Python, and on real churn data it lands within a few points of AUC of a properly tuned XGBoost model. The lookup table has an honest failure mode too: if a customer falls in a bucket you’ve never seen much data for, you get the global average back, which is a sensible, boring answer. A neural network in the same situation will still confidently emit a number, and that number carries no warning label saying “extrapolated, treat with suspicion.”

This is the test I’d encourage anyone commissioning an ML project to run before signing off on a budget: build the boring baseline in an afternoon, measure it against whatever success metric matters, and only pay for the sophisticated version if it clears the baseline by a margin that justifies the maintenance burden. Most of the time it doesn’t, because the signal in the data was linear and low-dimensional to begin with, and no amount of model complexity manufactures nonlinear signal that isn’t there.

Where the term actually earns its keep

None of this means machine learning is a con. It means the label covers an enormous range of problems, and only a fraction of them need what a modern neural network actually provides: the ability to learn a representation from raw, unstructured, high-dimensional input — pixels, audio waveforms, tokens of free text — where hand-engineering features would be impractical. Image classification is the clean example. Nobody is writing IF statements over pixel values to detect a cat, because the relationship between raw pixels and “cat” is not something a human can articulate as a formula. That’s genuinely a different category of problem from “will this customer with these five known account attributes cancel next month,” and it’s where the extra machinery of what a neural network buys you something a spreadsheet fundamentally cannot.

The tell, in my experience, is the shape of the input. Structured, tabular data with a handful of meaningful numeric or categorical columns is spreadsheet territory even when the columns number in the dozens, because the relationships tend to be close enough to linear (or piecewise-linear, which a decision tree handles) that fancier models buy marginal gains. Unstructured data — images, audio, free text, video — is where representation learning earns its complexity budget, because there’s no small set of hand-built features that captures what’s happening in a photograph. If your project’s input is a dataframe with named columns, ask hard questions before you reach past linear or logistic regression and a decision tree. If your input is raw pixels or a wall of text, the extra machinery is probably doing real work.

The maths you’re already doing in a spreadsheet

Logistic regression, worked through by hand, is the same weighted sum most people already build in a spreadsheet to score suppliers, prioritise leads, or rank support tickets by urgency. SCORE = w1*x1 + w2*x2 + w3*x3 + b, then squash it with a sigmoid so it reads as a probability instead of an unbounded number. The “training” step that sounds intimidating is just finding the weights that minimise prediction error on historical data, which is precisely what Excel’s Solver add-in does when you ask it to minimise a sum of squared errors by adjusting a handful of cells. The vocabulary differs — “gradient descent” instead of “Solver,” “loss function” instead of “error,” “features” instead of “columns” — but the object underneath is the same weighted formula a financial analyst has been building for decades.

Where this matters practically is in explaining model behaviour to people who have to sign off on decisions the model makes. A weighted sum with three terms is explainable in one sentence: “your score dropped because your login recency term went from 2 days to 34.” A five-hundred-tree ensemble with hundreds of interacting features requires a separate explainability tool (SHAP values, permutation importance) just to approximate an answer to the same question, and even then the explanation is a post-hoc approximation, not the actual mechanism. If your business has any regulatory or customer-trust requirement to explain a decision — credit, insurance, hiring, moderation — that’s a strong argument for staying on the linear side of the ledger even when a more complex model scores marginally better on a held-out test set, because the cost of an unexplainable wrong answer in those domains outweighs a point or two of accuracy.

Troubleshooting: when someone insists you need a model

The most common failure I see is skipping the baseline entirely and jumping straight to a neural network because it’s the exciting part of the project. When that happens, the debugging path looks the same every time: pull the feature importances out of whatever black-box model got shipped, and check whether the top three or four features could reproduce most of the accuracy on their own with a simple regression. In my experience they usually can, at which point the honest move is to ship the simple version and quietly note the complex one as a research artifact rather than production code.

The second failure is the opposite: someone builds the lookup-table baseline, it performs adequately, and it never gets replaced even after the business genuinely outgrows it — new segments appear that the historical buckets never saw, and the average silently degrades because nobody is monitoring bucket coverage. Watch for buckets receiving fewer and fewer data points over time; that’s your signal the world has moved on from the data the table was built on, and it’s the reason even a “boring” lookup table still needs an ongoing monitoring dashboard alongside the initial build.

The third, and the one that costs the most money, is choosing model complexity based on what’s fun to build rather than what the data supports. A team excited about deep learning will happily spend a quarter on an architecture built for one problem shape (unstructured, high-dimensional) and apply it to a problem with the other shape (tabular, low-dimensional), and then spend another quarter debugging why it isn’t beating a boosted tree that took an afternoon.

Why the label persists anyway

Part of the reason “AI” gets attached to a lookup table is commercial. A vendor selling a “predictive maintenance AI” charges a subscription; a vendor selling “three IF statements and a weighted average” doesn’t, even though the second description is the accurate one. I don’t think this is usually deliberate deception — the sales team genuinely believes the label, because somewhere upstream a data scientist did build the thing using scikit-learn, and scikit-learn’s marketing is “machine learning,” so the term propagates untouched all the way to the board slide. It’s worth reading what AI actually is once you strip the sales deck away before signing off on any tool described with the term, because the gap between the pitch and the mechanism is exactly where budget gets wasted.

There’s a second, more sympathetic reason the label sticks: once a team has built the tooling to train, version and monitor one model, reusing that pipeline for a much simpler linear model is often less work than building a bespoke spreadsheet-and-lookup-table process outside it. If your organisation already has experiment tracking and a feature store serving predictions, the fastest way to ship a three-variable churn score might genuinely be a one-line logistic regression call inside that existing pipeline, rather than a new spreadsheet process nobody owns. In that case the “ML” framing is accurate about the deployment mechanism, just silent about the mathematical complexity underneath it — worth being explicit about internally, even if the external pitch keeps calling it AI. The same reasoning shows up when a team chooses between hand-tuned rules and a retrieval-based system for answering questions from documents; how retrieval keeps a language model from making things up is a good example of a case where the “AI” part does real, non-trivial work, even though the decision of which documents to fetch can still be an ordinary similarity lookup underneath the framing.

Is it worth building the fancy version

Sometimes, yes — genuinely. If your input is raw text, audio or images, or if you’re squeezing out the last few percentage points of accuracy in a competitive, high-value prediction where those points translate directly into money (ad ranking at Google’s scale, say), the extra complexity earns its keep and the maintenance burden is a rounding error against the value delivered. But for most internal tooling, most SaaS churn and lead-scoring problems, and most “let’s add AI to this feature” requests that land on an engineer’s desk, the honest answer is that a well-labelled spreadsheet formula would ship faster, cost less to run, and fail more predictably than the neural network someone’s already scoped in the roadmap. Build the boring baseline first. Let the data, not the vendor deck, tell you whether you need anything more.