Home/Offers/Education & Workforce/Workforce Planning Forecast API

Education & Workforce

Workforce Planning Forecast API

Workforce plans fail in a predictable way: demand is forecast from last year's headcount, supply is assumed, and the gap only becomes visible when a role cannot be filled.

Workforce planning platforms
ERP and HR suite vendors
Public sector workforce bodies
Large employers
Skills and training agencies

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

Workforce planning in most organisations is a spreadsheet built once a year. Headcount by team, a growth percentage applied, an attrition assumption borrowed from memory, and a hiring plan that treats every role as equally fillable. It holds until a function grows faster than the local supply of people who can do the work, at which point the plan becomes a vacancy list and an agency invoice.

Three separate forecasts have to meet for the exercise to mean anything. Demand: how many people doing what, derived from activity drivers rather than from last year's structure. Internal capacity: who will still be here, who will have progressed, and what the training pipeline will have produced. External supply: how many people with those skills exist in the markets you can realistically recruit from, and who else is competing for them.

The third one is where plans quietly break, and it is the one most organisations have no data for at all. A plan to hire forty specialist engineers in a city that produces twelve a year is not a hiring plan, it is a wage inflation plan. Labour-market data makes that visible eighteen months before the recruitment team discovers it the hard way.

Who buys this

Workforce planning platforms, ERP and HR suite vendors, Public sector workforce bodies, Large employers, Skills and training agencies

Category: Education & Workforce

What the API returns

What comes back

Role demand forecasts by function, location and horizon, with intervals
Internal capacity projection including progression, retirement and expected exits at cohort level
External supply estimates for the roles and markets in scope, with competition intensity
Gap analysis by role and period, separated into buildable, buyable and borrowable
Skills supply pipeline from training, apprenticeship and education output where published
Scenario comparison across growth, automation and location assumptions
Lead-time estimates per role, so a plan reflects how long hiring actually takes
Confidence and data-coverage flags per role and market

Endpoints

Method	Path	Returns
POST	/v1/forecast/demand	Forecast role demand from activity drivers over a horizon
POST	/v1/forecast/capacity	Project internal capacity by cohort, including progression
GET	/v1/supply/{role}	External supply and competition for a role and market
POST	/v1/gap	Combined gap analysis across demand, capacity and supply
POST	/v1/scenarios/compare	Compare workforce scenarios on the same measures
GET	/v1/lead-times	Observed time-to-fill by role and market

Request and response

illustrative

Request

{
  "horizon_quarters": 8,
  "units": [
    { "function": "clinical_engineering", "location": "GB-MAN",
      "drivers": { "service_volume_growth": 0.07, "automation_factor": -0.02 } }
  ],
  "include": ["capacity", "supply", "gap", "lead_times"],
  "scenario": "base"
}

Response

{
  "scenario": "base",
  "horizon_quarters": 8,
  "unit": { "function": "clinical_engineering", "location": "GB-MAN" },
  "demand": [
    { "quarter": "2027Q1", "fte": 141, "interval_80": [134, 149] },
    { "quarter": "2028Q4", "fte": 168, "interval_80": [152, 186] }
  ],
  "internal_capacity": [
    { "quarter": "2027Q1", "fte": 132, "assumes_cohort_attrition": 0.11 },
    { "quarter": "2028Q4", "fte": 119, "assumes_cohort_attrition": 0.11 }
  ],
  "external_supply": {
    "market": "GB-MAN",
    "annual_qualifying_output": 14,
    "active_candidates_estimate": 60,
    "competition": { "employers_hiring": 9, "intensity": "high" },
    "confidence": "medium"
  },
  "gap": [
    { "quarter": "2028Q4", "fte_gap": 49,
      "feasible_hires_in_period": 22,
      "classification": { "build": 18, "buy": 22, "borrow": 9 },
      "warning": "Gap exceeds plausible local hiring; build or relocate." }
  ],
  "lead_time_days": { "p50": 118, "p90": 210 }
}

Where the data comes from

Your HRIS and establishment data	Current headcount, structure, vacancies and movement history, as the base for capacity projection
Operational activity drivers	Service volumes, caseloads, production plans or whatever genuinely drives staffing in your business — demand forecast from drivers beats demand forecast from headcount
Labour market posting data	External demand and competition for the same skills, from permitted sources; see the Job Market Intelligence API
Education and training output statistics	Published completions by qualification and region, which is the hard ceiling on local supply for regulated and specialist roles
Official labour force statistics	Participation, occupational stocks and migration flows, which anchor the supply side to a representative population
Occupational and skills taxonomies	So an internal job title, a training qualification and a job posting can be reconciled to the same role

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

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.

Demand forecast from activity drivers with explicit elasticities, rather than extrapolating headcount, so a growth assumption can be inspected and argued with
Cohort-based capacity projection using survival models on tenure and grade, including progression flows between cohorts and known retirement profiles
Supply estimation combining occupational stock, qualifying output and observed mobility, reported with intervals because every component is itself an estimate
Competition intensity measured from concurrent postings for the same skills in the same travel-to-work area
Gap classification into build, buy and borrow, with feasibility checked against observed lead times and local supply rather than assumed to be fillable
Scenario machinery where assumptions are named parameters, versioned, so a plan can be re-run and the change attributed
Walk-forward backtesting of demand and capacity forecasts against realised outcomes, reported by role family and horizon
Coverage flags where supply data is thin, which is common for niche and newly defined roles and should be visible rather than smoothed over

What it changes for the business

Plans that survive contact

Supply and lead-time constraints are applied before a hiring plan is approved rather than discovered during recruitment.

Earlier build decisions

A two-year view of a supply ceiling is enough time to train internally, which is the only real answer in constrained roles.

Defensible budget cases

Driver-based forecasts with intervals give finance something to interrogate instead of a growth percentage.

Location strategy

Comparing the same plan across markets shows where a role is actually fillable before a site decision is made.

How it fits into your product

How it embeds

REST endpoints feeding planning tools, with scenario comparison as the main interactive surface
Scheduled batch runs aligned to your planning cycle, with results versioned per planning round
Scenario parameters you author and store, so assumptions are explicit artefacts rather than spreadsheet cells
Deployment inside your infrastructure where establishment and HRIS data cannot leave
Export to the ERP or finance model that ultimately consumes the headcount plan
Cohort-level outputs throughout, with the same suppression rules used by the attrition forecasting service

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 weeks

Discovery 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

How far out is a workforce forecast useful?

Two to three years for demand and capacity, with intervals that widen honestly as the horizon extends. Beyond that the assumptions dominate the data and a scenario comparison is more useful than a forecast. Supply estimates are the least certain component and we report them as ranges with coverage flags rather than point figures.

Is this individual-level?

No. Capacity is projected at cohort level, using the same minimum-size and suppression rules as our attrition forecasting work. There is no per-employee departure probability in the output, because a workforce plan does not need one and producing one creates profiling exposure the plan gains nothing from.

Where do the external supply numbers come from, and how reliable are they?

Occupational stock from official statistics, qualifying output from published education and training data, and active candidate estimates from permitted posting and mobility data. For regulated professions with clear qualifications, these are reasonably solid. For loosely defined or emerging roles they are weak, and the API flags low coverage instead of producing a confident-looking number.

Can it tell us whether to automate a role?

It can model the headcount consequence of an automation assumption you provide. It cannot tell you whether the automation will work, what it will cost, or what it will do to service quality — those are not in the data. We would resist a product that presents an automation scenario as a recommendation.

What if our activity drivers are not measured?

Then that is the first piece of work, and it is often the most valuable part. A forecast built on headcount extrapolation will reproduce the structure you already have. Where no driver data exists we would scope a narrower pilot on the functions where it does, rather than model everything badly.

All Education & Workforce offers →

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.

Discuss This Build Browse All Offers