Afshin Mashayekhi CTIO & Transformation Executive
← All insights
AI & operations

Where AI actually paid: forecasting the roster, not the pitch deck

The most valuable AI use case in the business was the least exciting one on the list. That is usually the pattern.

Afshin Mashayekhi 6 min read

When an executive team first sits down to talk about AI, the conversation drifts toward the visible: a chatbot on the website, something generative in marketing, a demo that photographs well. Those ideas are not wrong, they are just rarely where the money is. The money is in the decision that gets made hundreds of times a week by someone under time pressure with incomplete information.

In a workforce-heavy services business, that decision is the roster. Every week, managers guess at demand, then pad the roster to protect service levels. The padding is invisible, it never shows up as a line item, and across hundreds of sites it is one of the largest controllable costs in the business.

So we started there. Not with a model, with the data: two years of attendance, seasonality, site-level variation, weather, school terms, and the human overrides managers had already been making. Cleaning and defining that data took longer than building the forecast, which is the part nobody puts in the business case.

The forecast then fed a rostering recommendation rather than a rostering decision. Managers could accept it, adjust it, or ignore it, and every override was captured. That single design choice did two things: it kept accountability with the person who owns the site, and it gave us a feedback loop that made the model better every week.

Rostered hours came down by more than two per cent without a measurable service impact. Two per cent sounds modest until you multiply it by a national workforce and a full year, and it compounds because the operating rhythm changed alongside the tooling.

The question is never “where could we use AI?” It is “which decision do we make badly, often, and expensively?”

What I would do again

01 Start from the recurring decision, not the technology, and size the prize before writing any code.
02 Budget properly for data definitions, quality and lineage; it is most of the work and all of the trust.
03 Keep a human in the loop and capture every override, because the overrides are your training signal and your change-management evidence.
04 Measure against a baseline agreed with finance before go-live, so the benefit is not debated afterwards.

Working through something similar? I am happy to compare notes.

Get in touch
← Back to all insights