ML Services for Business: What They Cover and When You Need Them
Every Monday at a frozen-food distributor we will call Kestrel Cold Chain, three planners spend the morning rebuilding a demand spreadsheet for 2,300 SKUs across four depots, and they still overstock vanilla tubs before a cold snap. A partner offering AI development Services, such as KriraAI, would treat that spreadsheet as raw material for a forecasting model instead of a weekly chore. ML services are the outside help that turns a problem like Kestrel's into a model running in production, starting with whether the records are usable and ending with keeping predictions accurate long after launch.
For an operations or analytics lead, the forecasting algorithm is rarely the hard part of Kestrel's problem. The hard parts are picking which depot problem deserves a model, judging whether three years of spreadsheet history is clean enough, and deciding who keeps the forecast working in month seven. Kestrel is a made-up company with illustrative numbers, but its planners face the same decisions real buyers do.
What's inside ML services, traced through one SKU forecast
For a distributor like Kestrel, ML services cover five jobs: choosing which problem deserves a model, preparing the depot data, building and testing the forecast, wiring it into the ERP, and keeping it honest when a heatwave scrambles buying patterns. Some vendors sell all five together, while others specialize. Mapping them against Kestrel's forecast shows what a proposal quietly leaves out.
Service line | What it looks like at Kestrel |
Scoping which Kestrel problem to fund first | Freezer-failure alerts get ranked against SKU forecasting, and forecasting wins because spoiled cartons have a clear price |
Cleaning and joining the depot records | Sales logs get matched to delivery manifests that label the same mango kulfi under two different product codes |
Building and testing the SKU forecast | A weekly forecast per SKU per depot, scored against what Kestrel's planners would have typed by hand |
Putting forecasts inside the ERP | Suggested order quantities appear in the ERP ordering screen before the Monday planning call starts |
Watching and retraining each depot's model (MLOps) | An alert fires when a long weekend pushes forecast error at the coastal depot past the agreed limit |
Some firms sell the first row on its own as ML consulting, which suits a team like Kestrel's that wants an independent opinion before committing a build budget. The middle rows are what most people picture when they hear ML development, yet depot cleanup often eats more calendar time than modeling. The last row is the one buyers most often forget to price, and it decides whether Kestrel's planners still trust the forecast a year later.
How an ML project moves from spreadsheet to production
A typical engagement takes Kestrel's forecasting problem through seven stages, each ending at a checkpoint where the team can stop if the evidence looks weak. A good vendor should walk you through them with your own spreadsheets before you sign. If a proposal skips one, ask who does that work.
Frame the Monday ordering decision. The model suggests order quantities per SKU per depot, and success means fewer written-off cartons.
Audit three years of depot history. Sales and delivery records get checked for gaps, such as five weeks when one depot was shut for a freezer floor repair.
Turn depot records into model inputs. This step, called feature engineering, creates signals such as the weekday, the temperature forecast and an upcoming long weekend.
Test candidate models on holdout weeks. Holdout weeks are recent weeks hidden during training, and each candidate must beat the planners' own spreadsheet numbers on them.
Run a shadow pilot at one depot. For six to eight weeks the model forecasts beside the planners without placing orders, exposing where it is confidently wrong.
Connect accepted forecasts to the ERP. Suggested quantities flow into the ordering screen, and every planner override is logged as a training example for the next version.
Watch each depot for drift and retrain. Drift means reality has moved away from the training data, as when a new supermarket account lifts one depot's volumes, so retraining starts once weekly error passes the agreed limit.
Four first projects hiding in a typical depot
Walk through one Kestrel depot and you will find the four most common starting points for machine learning: a forecast that drives orders, a compressor that could warn before it fails, pallets and paperwork a model could read, and retail accounts that could be ranked. Teams in other sectors usually start in one of the same four places. Only the details change by industry.
Forecasting demand, stock and staffing
Forecasting is the usual first project because its value is easy to count in Kestrel's own units: cartons written off, trucks sent half empty and overtime hours. Vendors often package it as predictive analytics services, delivering a forecast per SKU, depot and week. The same model could tell a depot manager how many pickers to roster before a long weekend.
Early warnings from freezer sensors and transactions
A freezer compressor rarely dies without warning, because its temperature curve often starts to wobble a few days earlier, and a model trained on months of that unit's healthy readings can catch the wobble. That technique is anomaly detection, and Kestrel's compressors and 14 refrigerated trucks already log temperatures every few minutes, which gives predictive maintenance its raw material. Finance teams apply the same idea to fraud detection, flagging refunds or supplier invoices that break an account's usual pattern.
Reading pallet photos, invoices and customer emails
Cameras at the loading dock can flag crushed cartons or a pallet stacked too high for a freezer aisle before the truck leaves. Teams that need this often look for dedicated Computer vision solutions, since image models need labeled photos and different hardware than sales-table models. Language models handle the text side, reading supplier invoices into the ERP and routing a retailer's email about a melted delivery to the right depot.
Scoring and recommending for retail accounts
Kestrel sells to 380 retail accounts, and a churn prediction model can rank them by the chance of paying late or quietly cutting orders next quarter. A recommendation model can sit beside it, suggesting the two or three SKUs a corner shop is likely to add before summer. Both lists earn their keep when the sales team has more retail accounts than it can phone each week.
Comparing MLaaS platforms, packaged tools, partners and in-house teams
Kestrel can get machine learning into its ordering process four ways, and the right one depends on how unusual the problem is and who will own the forecast next year. With machine learning as a service (MLaaS) you rent training and hosting tools, with packaged software you rent someone else's model, a partner builds yours, and an in-house team does everything. Many companies like Kestrel mix two of these.
Route
Renting a cloud MLaaS platform for Kestrel's data
When it suits a company like Kestrel
Kestrel already employs two data engineers who can build features and connect the ERP
Where it tends to break down at Kestrel
Staff time balloons if nobody in-house has kept a forecast alive through a heatwave
Route
Buying off-the-shelf replenishment software for Kestrel's depots
When it suits a company like Kestrel
Kestrel's ordering looks like generic grocery replenishment and the vendor's assumptions fit
Where it tends to break down at Kestrel
Per-depot freezer capacity limits and coastal weekend spikes may not fit a fixed template
Route
Commissioning a custom Kestrel forecast from a partner
When it suits a company like Kestrel
The forecast must respect Kestrel-only rules, such as pallet caps per freezer aisle
Where it tends to break down at Kestrel
The pilot stalls if no Kestrel manager owns the forecast after the vendor leaves
Route
Hiring a Kestrel in-house ML team
When it suits a company like Kestrel
Kestrel has years of SKU, sensor and account projects queued and budget to hire
Where it tends to break down at Kestrel
Recruiting experienced ML engineers often takes months before the first depot sees a forecast
Custom work makes sense when the forecast must respect rules only your business has, like Kestrel's pallet cap per depot freezer. For a longer look at why companies choose that route, read this piece on Custom machine learning models for business. A common middle path is a partner-built model hosted on Kestrel's own cloud account, so its analysts can take over later.
Are you ready for outside ML help? Start with your spreadsheets
You are ready for help when a decision repeats weekly, a wrong call has a countable cost, the records already sit in your spreadsheets or ERP, and a named person will own the result. Kestrel ticks all four boxes for SKU forecasting but only two for compressor alerts, because its freezer sensor logs started just eight months ago. That mismatch is normal, and it is why use cases get ranked before any is funded.
Using AI somewhere is now common, but scaling it beyond a pilot like Kestrel's is not, and data is usually the brake. In McKinsey's State of AI survey released in August 2026, 89% of respondents said their organizations use AI regularly, yet 44% reported scaling it across the enterprise. Gartner, for its part, predicted in February 2025 that organizations will abandon six in ten AI projects that lack AI-ready data through 2026, after a survey in which 63% of organizations said they lacked suitable data practices for AI or were unsure. If Kestrel's sales history lived on depot laptops in five spreadsheet formats, its first purchase should be a data cleanup project, not a model.
The signals for waiting matter just as much, and this is where ML is plainly not for everyone. If a fixed rule would do the job, such as reordering a slow-moving SKU whenever stock falls below ten cartons, a model adds cost without adding accuracy. If nobody can name the Monday decision the model would change, curiosity is driving the project, and it usually stalls after the demo.
What drives the price of an ML engagement
The price of a project like Kestrel's forecast depends less on the algorithm than on four things: how messy the depot data is, how many systems the model must connect to, how accurate it needs to be, and who runs it after launch. Matching Kestrel's two product code systems might take days with a master SKU list or weeks without one. When two vendors quote very different numbers for the same depots, ask each to write down its assumptions on those four factors.
Most vendors split the work into three phases. A fixed-price discovery phase produces the ranked use cases and data audit, and it is the cheapest place for Kestrel to learn that compressor alerts should wait. The build then runs as a fixed-scope shadow pilot or on time and materials, and monitoring moves to a monthly retainer or to Kestrel's own analysts after a handover period.
Questions to put to any ML vendor before you sign
A good vendor asks about your Monday decisions and your depot data before talking about models, and five questions bring that out within one meeting. Bring your analytics lead and the manager who would own the forecast, since each will hear different warning signs. Write the answers down, because they shape Kestrel's contract or yours.
What baseline will the model beat, and will you measure it against our planners' spreadsheet numbers rather than a simple average?
Which depot data do you need in the first two weeks, and what happens to the timeline if those records turn out worse than expected?
Who owns the trained forecast model, the code and the depot data pipeline when the contract ends?
How will we see that a depot's forecast is drifting, and who pays for the retraining it triggers?
Can you describe a project where you told the client a spreadsheet rule would beat a model?
The answers show how a vendor thinks about month seven at your depots, which matters more than the demo. To compare responses against what has held up recently, this review of which Machine learning services are working in 2026 adds useful context. A vendor that welcomes these questions from Kestrel's planners has usually answered them before.
What machine learning won't fix
A model can only learn patterns that already exist in your records, so Kestrel's forecast cannot predict a supplier strike, a product recall or the first summer of a flavor nobody has sold before. New SKUs need a fallback, such as borrowing the sales curve of a similar ice cream line, until real history builds up. A model also cannot repair a broken process, and if depots log returns two weeks late, it will learn from late data and give late answers with great confidence.
Explanations have limits too. Many accurate models cannot give a simple reason for each prediction, which is fine for a carton forecast but awkward for credit limits on Kestrel's 380 retail accounts. There, a simpler and more readable model is often the better choice even if it scores a little lower.
Finally, a model only pays off if people use it. If Kestrel's planners distrust the forecast and quietly keep their old spreadsheet, the project delivers nothing. Budget time for training, override rules and a few weeks of planners and the model working side by side.
Where to start: three weekly decisions and the spreadsheets behind them
The cheapest first step is a list of three decisions your team repeats every week, with the spreadsheets or systems behind each one. If one of them looks like Kestrel's Monday forecast, with real money at stake and a few years of data underneath, an outside review is worth the time. KriraAI's Machine learning development services team can go through that list with you and help judge whether a model would pay for itself before any build begins.
FAQs
For a distributor the size of Kestrel, the scope usually runs from use-case selection and depot data cleanup through model building, ERP integration and monitoring. A distributor with its own data engineers might buy only the build and depot-level monitoring. The mix depends on how much depot data work your analysts can already handle.
Kestrel's BI dashboard tells planners how many vanilla tubs each depot sold last week, while a demand model proposes how many to order next Monday for each of 2,300 SKUs. One looks back at depot sales, the other commits to a number, and the dashboard later shows how good that number was. Neither replaces the other, so most distributors like Kestrel keep both running.
It can, but one year gives the model a single example of each season, so heatwave and holiday patterns at Kestrel's depots will be shaky. Non-seasonal tasks such as reading invoices or flagging freezer anomalies often need less history. Discovery should confirm whether your spreadsheet history is long enough.
In most implementations the forecast can be written into an ERP through an API, a scheduled file drop or a shared database table. An older ERP with no API can turn this into the slowest part of a project like Kestrel's. Ask the vendor to name the exact connection method for your ERP before the build starts.
Timelines depend on how clean the depot data is, but the order is fixed: discovery, cleanup, a build, then a shadow pilot. In the Kestrel example, the shadow pilot alone runs six to eight weeks at one depot. Be wary of any quote that skips the one-depot shadow pilot.
A well-built system logs the miss, lets a planner override the suggested order and feeds that override into the next training cycle. At Kestrel, any SKU whose heatwave sales land far from the forecast triggers a review by the head of planning. Clear override rules protect the depots better than chasing a perfect accuracy score.
Platform fees usually look smaller than a custom quote, but someone still has to design features, test models and connect forecasts to the ERP. For a company like Kestrel with no ML engineers, that salary cost can outweigh the saving. Compare two years of total depot forecasting cost, not the first invoice.
One model can often cover many sites if it receives each depot's climate, customer mix and freezer capacity as inputs. Separate models sometimes win when sites behave very differently, like Kestrel's coastal depot that spikes every sunny weekend. Testing both setups during the shadow pilot settles it with your own numbers.
Ridham Chovatiya is the COO at KriraAI, driving operational excellence and scalable AI solutions. He specialises in building high-performance teams and delivering impactful, customer-centric technology strategies.