Education & Workforce
Employee Attrition Forecasting API
Turnover is a planning problem and an organisational-design problem. It stops being either one the moment it is turned into a list of names for managers to watch.
- HR software vendors
- Workforce planning platforms
- People analytics teams
- Large employers
- Staffing providers
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Unplanned turnover is expensive in ways that are easy to count and ways that are not. Recruitment cost, time to productivity, lost institutional knowledge, the overtime absorbed by whoever stays. Finance wants a number for next year's hiring budget; operations wants to know whether the night shift will be staffable in March. Both are aggregate questions, and both are answerable from data most employers already hold.
The market has mostly answered a different question. Individual flight-risk scores, surfaced to line managers, are the default product shape — and they are the wrong shape. A score on a named employee invites exactly the misuse you would predict: passing over someone for a project because the dashboard called them a retention risk, excluding them from a promotion round, or using the score as cover in a redundancy selection. The employee has no idea the score exists, cannot see what drove it, and cannot contest it.
It is also a legal exposure, not merely an uncomfortable one. Under GDPR and comparable regimes, profiling that affects a worker's employment carries transparency, lawful basis and sometimes works council obligations, and a score that correlates with pregnancy, disability, age, caregiving status or union activity — all of which drive turnover — becomes discriminatory the moment it touches a pay, promotion or termination decision. We would decline to build that. The aggregate version answers the planning question better anyway, because what a workforce planner needs is a rate with an interval, not a hundred individual probabilities they will misread.
Who buys this
HR software vendors, Workforce planning platforms, People analytics teams, Large employers, Staffing providers
What the API returns
What comes back
- Forecast turnover rate by team, function, location and tenure cohort, with prediction intervals
- Headcount trajectory under the forecast, including expected vacancy windows
- Retention driver analysis at cohort level, ranked by estimated contribution
- Comparison of cohorts against each other and against the organisation baseline
- Early-signal indicators at team level — workload concentration, span of control, promotion stagnation, pay compression
- Scenario outputs for planned interventions, with honest uncertainty
- Minimum-cohort suppression so no team is small enough to identify an individual
- Backtest accuracy per cohort so a planner knows which forecasts to trust
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/forecast/cohorts | Forecast turnover for defined cohorts over a horizon |
| GET | /v1/cohorts/{id}/drivers | Ranked retention drivers for one cohort |
| POST | /v1/scenarios | Estimate the effect of a planned intervention on a cohort |
| GET | /v1/cohorts/{id}/signals | Team-level early indicators with thresholds |
| GET | /v1/forecast/accuracy | Backtest accuracy by cohort and horizon |
| GET | /v1/suppression | Which cohorts are suppressed and why |
Request and response
illustrativeRequest
{
"cohorts": [
{ "id": "ops-night-shift", "filters": { "function": "operations", "shift": "night" } },
{ "id": "eng-tenure-0-12m", "filters": { "function": "engineering", "tenure_months": "0-12" } }
],
"horizon_months": 12,
"min_cohort_size": 25,
"include": ["drivers", "intervals"]
}Response
{
"horizon_months": 12,
"generated_at": "2026-10-21T08:00:00Z",
"granularity": "cohort",
"cohorts": [
{
"id": "ops-night-shift",
"headcount": 184,
"forecast_turnover_rate": 0.241,
"interval_80": [0.192, 0.294],
"baseline_rate": 0.157,
"expected_leavers": 44,
"drivers": [
{ "driver": "consecutive_night_rotations", "contribution": 0.31 },
{ "driver": "pay_compression_vs_market", "contribution": 0.24 },
{ "driver": "promotion_stagnation_over_24m", "contribution": 0.18 }
],
"backtest": { "horizon_12m_mae_pts": 3.1, "periods": 6 }
},
{
"id": "eng-tenure-0-12m",
"status": "suppressed",
"reason": "cohort_below_minimum (n=19)"
}
],
"policy_note": "Outputs are cohort-level. Individual attrition scores are not produced."
}Where the data comes from
| Your HRIS records | Headcount, tenure, function, location, movement and leaver history — aggregated into cohorts before modelling, not held as per-person features for scoring |
| Scheduling and workload data | Rota patterns, overtime and shift rotation, which are among the strongest and most actionable turnover drivers in operational workforces |
| Compensation and progression records | Pay position against market and time since last progression, both of which an employer can act on |
| Engagement survey aggregates | Only at cohort level and above the survey's own confidentiality threshold — re-identifying survey responses would destroy the instrument |
| External labour market data | Local demand for the same skills, since turnover is partly a function of what else is hiring nearby |
| Works council or union agreements | Not a data source as such, but a binding constraint on what may be analysed and how — it belongs in scope before any pipeline is written |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Modelling at cohort level throughout — survival and discrete-time hazard models fitted on cohort histories, so there is no per-person score to leak, export or misuse
- Minimum cohort thresholds on headcount and on distinct managers, with suppression when either fails, plus differencing checks so overlapping cohort definitions cannot be subtracted to isolate a person
- Prediction intervals on every forecast, because a workforce planner acting on a point estimate will over-hire or under-hire
- Driver estimation framed as cohort-level contribution with confidence bounds, not individual feature attribution
- Deliberate exclusion of protected and quasi-protected attributes from the driver set, with proxy testing on the remainder — caregiving status, health absence and union membership all correlate with turnover and must not become levers
- Scenario estimation presented as a range with the causal assumption written down, since 'raise pay by 4% and turnover falls by X' is an association unless the intervention was actually tested
- Walk-forward backtesting by cohort and horizon, with accuracy published per cohort rather than as one headline figure
- Drift monitoring on cohort composition, because a reorganisation redraws the cohorts and silently invalidates the history
What it changes for the business
Hiring plans that hold
Cohort forecasts with intervals let recruitment be scheduled against expected vacancies instead of reacting to resignations.
Fixable causes
Driver analysis points at rota design, pay compression and progression stalls — things an employer can change, unlike an individual's intentions.
Defensible by design
Aggregate-only output removes the profiling exposure that individual flight-risk scoring creates, which is usually what a works council or DPO objects to.
Measurable intervention
Scenario outputs and cohort backtests let a retention programme be evaluated rather than asserted.
How it fits into your product
How it embeds
- REST endpoints for planning tools and people-analytics dashboards, cohort-scoped throughout
- Deployment inside your own infrastructure, which is the normal arrangement for HRIS data and often a condition of works council approval
- Cohort definitions you author and version, with suppression applied automatically at query time
- Scheduled batch runs feeding your workforce planning model rather than ad-hoc interactive queries
- Accuracy reporting exposed to your users, so a planner can see which cohort forecasts have historically held
- Role-based access that has no individual-level view to grant, because the API does not produce one
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Can you give managers a flight-risk score for each of their reports?
No, and we would turn the work down rather than scope it. A named per-person score handed to a manager gets used in exactly the ways it should not be — project allocation, promotion rounds, redundancy selection — by someone who cannot see what drove it and about an employee who does not know it exists. It is also legally exposed: that is profiling affecting employment, so it carries transparency and lawful-basis obligations, and because turnover correlates with pregnancy, disability, age, caregiving and union activity, the score becomes a discrimination claim the moment it touches a pay or termination decision. The cohort forecast answers the planning question better and carries none of that.
Our executives specifically asked for individual scores. What then?
We would show them what the aggregate version answers, which is usually what they actually needed: how many leavers to expect by team and quarter, which cohorts are deteriorating, and which drivers are worth spending money on. If the requirement really is per-person watchlists, we are the wrong supplier and would say so early rather than build it and attach a disclaimer.
How accurate is a twelve-month cohort forecast?
Accurate enough to plan against, not accurate enough to treat as fact. Typical cohort-level error widens with horizon and narrows with cohort size, and we report measured error per cohort from walk-forward backtesting rather than quoting one number. Small cohorts and recently reorganised teams are the least reliable, and the API flags both.
Will the drivers tell us what to fix?
They tell you what is associated with leaving in that cohort, ranked, with confidence bounds. That is a strong hypothesis, not proof of cause. The honest way to use it is to change one thing for one cohort and measure, which the backtest and scenario endpoints are built to support.
What about engagement survey data?
Usable only in aggregate, and only above the survey's own confidentiality threshold. Survey participation depends on employees believing responses cannot be traced back to them, and a model that effectively re-identifies them destroys the data source and the trust along with it.
Related blueprints
Workforce Planning Forecast API
Forecasts of future role demand, internal capacity and external skills supply, as a planning layer inside HR, ERP or public-sector workforce software.
Salary Benchmarking API
Role, level and region specific pay ranges with stated provenance, as a compensation layer inside HR, payroll or recruitment software.
Skills Assessment API
Standardised skill tests, scoring and gap analysis delivered as an API your HR or learning platform embeds under its own brand.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.