Machine learning consulting in the Nordics should end with a model your team uses every week, not a slide deck. In practice that means four things: the right data, a model that answers one business question, a way to run it in your systems, and monitoring after launch. Here is what that looks like in three cases: two projects we have shipped and one we would build for Icelandic tourism.
What does ML consulting actually deliver?
A good engagement delivers a working system, not just a trained model. That system usually has five parts:
- A data pipeline that pulls history from your systems and cleans it on a schedule.
- One or more models trained on that history and tested on data they have not seen.
- Deployment, so predictions reach people where they already work: an app, a dashboard or an API.
- Monitoring, so you know when the model starts to drift.
- Handover, so your own team understands the model and can tune it.
The model is often the smallest part of the work. The other four decide whether anyone uses it.
Case one: predicting machine failures at Buff
Original Buff runs production in Igualada, Spain. Unplanned machine failures were delaying production and raising costs. The maintenance team spread its effort across every machine, and the factory mixed machines from the 1990s with modern ones, so the data was inconsistent.
We extracted three years of machine usage, environmental and failure data. We then trained five models. Two time series models, XGBoost and Prophet, picked up seasonal patterns. Three classification models predicted the type of failure. The GEMBA method helped us pick the most critical machines, so predictions focus on them.
The results live in a Qlik Sense app. Users can compare models and see why a machine was flagged. Every Monday an automated report lists the machines most likely to fail in the coming days. The full story is in the Buff case study.
Case two: recommending products at CorEnroll
CorEnroll is an insurance enrolment platform used by brokers and reps across the USA. With our partner CloudTech, we built recommendation models for it. Reps had spent much of their time searching a large catalogue for the right product, during a busy month-long enrolment period.
We built three recommenders:
- Trending products by insurance type in the rep's state.
- Similar products that match the filters a rep applies.
- Complementary products suggested at checkout.
The data leaned heavily towards one product, so we used sampling and balancing to keep suggestions varied. The models run behind API endpoints on AWS, with an MLOps pipeline for deployment and monitoring. Dashboards compare what the models recommend with what actually sells. CloudTech's team received full documentation and training on tuning the models. See the CorEnroll case study.
Case three: forecasting demand for Icelandic tourism
This one is an idea, not a shipped project. Tour operators and hotels in Iceland plan guides, buses and rooms months ahead of a short, busy season. A demand forecast helps them hire and book at the right level.
The inputs would be the operator's own bookings by travel date and booking date, joined with public data. The Icelandic Tourist Board publishes monthly counts of departing foreign passengers at Keflavík by nationality. Statistics Iceland publishes monthly overnight stays in accommodation. A forecast built on these would show expected bookings per tour and week, with a range rather than a single number.
The groundwork is a clean booking history, which is the kind of data foundation we built for TourDesk.
How much data do you need?
Enough history to cover the patterns you want to predict. For seasonal demand, that means at least two or three full seasons. For failures, it means enough recorded failures to learn from. Buff had three years. If your data is thinner, start by collecting it well and revisit the model later.
What happens after launch?
Models age. Customer behaviour shifts, products change and machines get replaced. After launch we track three things:
- Accuracy against what actually happened.
- Input data quality, so a broken feed doesn't quietly spoil predictions.
- Use, because a model nobody opens has no value.
When accuracy drops, the model is retrained on newer data.
When should you not use machine learning?
Skip it when a simple rule does the job, when the decision is rare, or when the data doesn't exist. Skip it too when nobody will act on the prediction. A clear dashboard often answers the question first, and ML can follow once the data is in shape.
If you have a prediction problem in mind, our approach explains how we scope it, and you can book a call.