Machine learning for business: what it actually solves and what to demand from whoever sells it to you

Machine learning for business has spent a decade being sold as magic and deployed as a spreadsheet with extra steps. The confusion is understandable: the same label covers a model that decides which customer you call tomorrow and a demo that classifies pictures of cats. This article is about the former, written for whoever has to decide whether a project is worth it without knowing — or needing to know — what a gradient is.

The underlying idea fits in one sentence: a machine learning model learns a pattern from your history and applies it to new cases. That's it. Everything that matters — whether it works, whether it can be used, whether it pays — comes from three far more boring questions: what data you have, what decision you're going to change, and who answers for it when it gets things wrong.

What is machine learning and how is it different from rule-based automation?

You write a rule yourself: "if the order exceeds €5,000, route it for approval." It's explicit, anyone understands it, and it can be audited in a minute. A model isn't written, it's trained: you feed it thousands of past cases with their known outcome and it works out which combination of signals anticipates that outcome.

When each one wins:

• Rules when the criterion is known, stable and involves few variables. Never put a model where a clear rule does the job: it's more expensive, more fragile and harder to explain.
• Machine learning when the criterion exists but nobody can write it down, many variables interact, and you have enough history. The classic example: "this customer smells like they're leaving." A veteran account manager senses it; turning that into twenty rules doesn't work.

And a third path that gets forgotten: the hybrid, which is what almost always ends up in production. The model scores, business rules set the hard limits (never quote below cost, never touch a client in litigation) and a person decides in the grey band. It works better than either option alone, and it is infinitely easier to defend in front of the board.

If you don't know what you'd do differently tomorrow with the prediction in hand, you don't have a machine learning project. You have curiosity, which is legitimate and far cheaper to satisfy.

Which machine learning use cases actually work in a mid-sized company?

Three families come up again and again because the data exists and there's a clear decision behind them. The rest is usually a variation on these.

Scoring: ordering a list. Probability that a lead buys, that a customer churns, that an invoice is paid late, that a candidate fits. The value isn't in getting each case right, but in changing the order in which your team spends its limited time. If your sales rep calls 30 companies from a list of 400, raising the concentration of buyers inside those 30 is worth money even when the model is often wrong.

Forecasting: anticipating a quantity. Demand by product and warehouse, workload by week, consumption, collections. Here the bar is set by what you already do: if your current forecast is made by a person with judgement and their error margin is 12%, the model has to beat that consistently to justify itself. It does more often than you'd think, because a person can't repeat the exercise for 4,000 SKUs every week.

Anomaly detection: finding the odd one out. Fraud, accounting errors, machine failures, consumption outside the normal pattern. This is the family with the best effort-to-return ratio when the cost of a missed case is high. One caveat: if the rare cases really are rare (one in a thousand), the "accuracy" metric lies — a model that always says "normal" is right 99.9% of the time — and you have to look at how many real cases it catches and how many false alarms it raises per catch.

Concrete examples of what we've seen fit well, by type of business:

| Situation | Family | Decision that changes | |---|---|---| | Portfolio of 3,000 recurring B2B customers | Churn scoring | Who the account team calls this week | | Distribution with 5,000 SKUs | Demand forecasting | How much is ordered and what stock moves | | Service business with seasonal peaks | Workload forecasting | How many people are scheduled per shift | | Production with instrumented machines | Anomalies | When you stop for maintenance instead of waiting for the breakdown | | High volume of supplier invoices | Anomalies | Which document gets a manual review before payment |

What data do you need before training anything?

This is the section people like least and the one that saves the most projects. A model learns from the past, so you need that past to be recorded and comparable to the present.

The minimum for a serious conversation:

• History with known outcomes. Having data isn't enough: you need to know how each case ended. To predict churn you need to know who left and when; if your CRM flags "inactive customer" with no date, you have no label and there is no model.
• A reasonable volume of positive cases. The useful figure isn't "how many rows", it's how many examples of the rare event you have. Forty historical churns won't train a churn score no matter how many of your 3,000 customers are in the database.
• Enough time depth for the cycle. If your business is seasonal, one year of data gives you a single occurrence of each season. Two or three years change the conversation.
• Stable definitions. If eight months ago you changed the catalogue, the chart of accounts or the way tickets are categorised, the earlier history speaks another language. It can be mapped, but you need to know before promising timelines.
• Availability at decision time. The most common and most expensive mistake: training with a variable that doesn't exist yet in production when the prediction has to be made. If you use "amount invoiced this month" to predict something you decide on the 3rd, you're cheating without meaning to, and the model collapses the moment it goes live.

If reading this makes you think your house isn't in order, the right sequence isn't to cancel: it's to start with data strategy and with defining who owns each piece of data, which is what data governance is about. The plumbing work that holds all this up is the discipline of data engineering, and it's where the bulk of the real effort in any project goes.

How do you tell whether a model is good without understanding the maths?

You don't need to read a ROC curve. You need four questions and a refusal to accept vague answers.

1. Compared to what? Every model must be compared against the cheap alternative, not against random chance. If your current forecast is "same as last year plus 5%", that's the bar. A vendor presenting 87% accuracy without telling you what the dumb method scores is hiding half the information.

2. Measured on what data? The model has to be evaluated on cases it didn't see during training, and for forecasting, on a period later than the training window. Measuring on the same data it learned from is like marking an exam with the answer sheet in front of you: you get a 98% that means nothing.

3. Which error hurts more? They're almost never symmetrical. In fraud detection, letting a case through costs thousands of euros while a false alarm costs five minutes of review: the threshold goes towards paranoid. In a sales score, saturating a good customer with calls can cost more than ignoring a bad one. That trade-off is a business decision, not a technical one, and someone from the business has to make it.

4. Does it hold up over time? Models degrade because the world changes: a competitor arrives, a price goes up, the customer mix shifts. Performance has to be measured in production month by month, with a defined point at which it gets retrained and a named person watching.

A practical rule for meetings: always ask to see the result expressed as a decision, not as a percentage. "Of the 100 accounts the model flagged as high risk last quarter, how many actually churned?" is a question you answer with reality in front of you, and it disarms any presentation built on smoke.

What should you demand from a machine learning vendor?

Machine learning gets bought badly because it gets bought on the strength of a demo. These are the conditions we set — and recommend you set — before signing:

| Requirement | Why it matters | Red flag | |---|---|---| | A trial on your data | A demo on someone else's data says nothing about your case | "Let me show you the result on a sample dataset" | | A declared baseline | Without comparison, any number looks good | They can't tell you what the current method scores | | A metric tied to the business | Technical accuracy doesn't pay invoices | They only talk about precision, never euros or hours | | Explainability at case level | Someone will have to justify a decision | "The model is a black box, it just works" | | A retraining plan | Every model degrades | It's not in the budget or in the contract | | Ownership of model and data | It's your history and your competitive edge | Vague clauses about reusing your data | | Integration into the real tool | A model outside the workflow gets used by nobody | The deliverable is a report or a code notebook |

That last point kills more projects than any other. A score living in a file someone has to open isn't used three weeks later; the same score as a sortable column inside the CRM the team already opens every morning is. The difference between the two is integration, and that's where the return is decided. We cover it in depth in why AI pilots fail.

Add one more condition, uncommon and very healthy: the right to stop. Have the contract include a decision point after the pilot, with success criteria written down before starting, and the option not to continue without penalty. An honest vendor has no problem with that; one who does is telling you something.

What does it cost and when do you see something?

Generic cost figures are close to useless because the real range depends on how messy your data is, not on the algorithm. But the shape of the spend is fairly stable, and it's worth knowing so you avoid surprises:

• Data preparation: the largest share. Access, cleaning, unifying master records, building the history. If someone quotes you a project where this is a minor line item, either your data is exceptionally good or the budget is wrong.
• Modelling: less than people think. With tidy data, getting to a first defensible model is a matter of days, not months. Algorithmic sophistication is rarely the bottleneck in a business case.
• Integration and going live: more than people think. Connecting to the CRM or the ERP, keeping it running on a reliable schedule, handling errors, permissions and traceability.
• Maintenance: always there. Monitoring, retraining, threshold tuning. Budget it annually from the start.

On timelines, a first sensible use case in a mid-sized company is measured in weeks for the pilot and months to have it integrated and genuinely in use. And a warning about ordering: the second use case always comes out far cheaper than the first, because half of the initial cost was building the road — access, cleaning, integration — that is now already there. So choose the first one thinking about what infrastructure it leaves installed, not only about its isolated return.

What legal and governance risks do you have to cover?

A model that scores people — customers, candidates, employees — is not a neutral technical exercise. The minimum before going live:

• Legal basis and personal data. If you train on data about identifiable people, the full data protection framework applies: purpose, minimisation, retention periods. We detail it in GDPR and AI compliance, and where you can work with treated data, in data anonymisation.
• Automated decisions about people. If the model decides without human intervention and significantly affects someone, additional obligations apply around information and the right to human intervention. The practical way out is almost always the same: the model proposes, a person decides.
• Bias inherited from the history. The model replicates what was there. If a segment was historically served worse, the model learns that and consolidates it with the appearance of objectivity. You control it by measuring performance by segment, not only overall.
• Traceability. Store which model version produced each prediction, with which inputs, and who acted on it. Without that you can't explain a decision six months later or correct a systematic failure.

None of this is defensive bureaucracy: it's what lets the project survive the first customer complaint or the first uncomfortable question from the board.

Frequently asked questions

How much data do I need to apply machine learning in my company?

It depends more on the event you want to predict than on your total size. The right question isn't how many rows you have, but how many examples of the target case exist in the history and whether they're properly labelled. As a practical order of magnitude, with fewer than a few hundred occurrences of the event you're better off starting with rules or descriptive analysis and returning to the model once the history grows.

Is machine learning the same as generative AI?

No. Classic machine learning predicts or classifies from your history — a probability, a quantity, a category — and is evaluated against real outcomes. Generative AI produces text or images and is evaluated differently, with different risks. Both belong in the same company and often in the same workflow, but they solve different problems; we develop this in generative AI in business.

Do I need to hire a data science team?

For the first use case, almost never. It makes more sense to lean on someone external who builds the complete case and leaves the infrastructure running, then evaluate hiring internally once there are two or three live models to maintain. What you do need from day one is an internal person who knows the business and owns the criteria.

How do I know when a model has stopped working?

Through deterioration of the metric in production, not through gut feeling. You define a business-linked indicator at the outset, measure it monthly on real cases, and set a threshold that triggers a review. If nobody is watching that number, the model has been failing for months and you haven't noticed yet.

If you have a use case in mind and don't know whether your data can support a model or whether tidying up comes first, that's exactly what comes out of the audit: use cases ranked by effort and return, with the real state of your history as the starting point and a clear verdict on what's viable this year. If you'd rather sense-check it in half an hour before moving anything, let's talk.