A staffing business spends most of its money finding people it has never met, while already knowing thousands of people well: the ones it placed. It knows what they did, where, for how long, how the assignment ended, and what the client thought of the work. In most staffing firms that knowledge goes quiet on the day the placement starts and wakes up by accident, months later, when somebody happens to answer a call.
A global staffing and HR services group wrote the correction into its data blueprint as one plain sentence. Use analytics to predict the re-applicability of candidates who are currently on the job. Not to source new candidates. Not to match faster. To know, before anyone picks up a phone, which of the people already placed are coming back to the market and roughly when.
Further along the same plan sits a second use case that reads like a smaller thing and is not. Tailored job suggestions, and frequency of contact, both driven by the personal profile. The first sentence is a forecasting problem. The second one decides whether the forecast makes the firm better company or worse.
The challenge
The re-applicability forecast is not hard because the mathematics is hard. Contract end dates, assignment lengths, sector churn, how long comparable people stayed in comparable roles: this is ordinary survival-style modelling on data a staffing group already generates as a by-product of invoicing. The difficulty is where the data lives.
What the plan asks for is not a cleverer technique but a wider join, and the join is the expensive part. A placement record belongs to the operating unit that made the placement. The person's profile, their skills, their stated preferences and their behaviour on the group's own channels belong somewhere else, often in a different country and a different system, assembled for a different purpose. The forecast requires those two to be joined for the same human being, and the join has to hold across business units that were never asked to agree on what a candidate record is.
That is a data readiness problem wearing an algorithm costume, and the blueprint said so in the least ambiguous place available. The slide setting the target for the high-volume digital service leads with data quality as the enabling condition for automated matching and near real time job suggestions. Not model choice. Not compute. Quality.
The plan is candid enough about this to include a use case most organisations would never put in front of a board: use analytics to predict the value of incorrect or missing data across the estate. Read that as a costing exercise rather than a research project. If the group can put a number on what one stale contract end date or one absent skill field costs in missed re-placements, the argument for lineage, ownership and validation stops being an IT hygiene request and becomes a revenue case with an amount attached.
The approach
The plan names three algorithm classes it has to develop: smart matching, job suggestions, and demand prediction. Naming them is worth more than it looks, because it hands the integration work a test to pass. Each piece can be justified by saying which of the three it unblocks, and anything that unblocks none of them can wait.
The re-applicability forecast serves all three at once, which is what makes it a good first build. It is a demand signal on the supply side. It tells a matching engine which people will shortly be eligible, it tells the suggestion engine who is worth writing to, and it feeds the demand picture from the direction most staffing firms ignore, since a person coming free is a slot opening as surely as a client vacancy is.
Then comes the second use case, and it changes the character of the system. Personalising what gets suggested is a relevance problem, and relevance failures are cheap. An irrelevant job alert is deleted and forgotten. Personalising how often contact happens is a relationship problem, and those failures are not cheap at all. Contact somebody weekly who wants to hear from you twice a year and you do not lose one message. You lose the person, the channel, and every behavioural signal that channel was producing, which is the same signal the forecast was learning from. The system degrades its own inputs.
The plan makes the risk sharper than it may have intended. It asks for engagement that is automated but personal, and says that part of the purpose of that engagement is to further enrich the data. A system rewarded for enrichment has a standing reason to make contact. Left alone, an optimiser handed that objective will discover that more messages produce more observations, and the cadence will drift upward until people leave. The counterweight has to be designed in, not assumed: a per-person contact budget the system cannot exceed, an explicit preference the person controls and can see, and unsubscribes and silences treated as first-class outcomes in the same evaluation the click-through rate sits in.
None of that is a modelling refinement. It is deployment design, and it belongs in the machine learning pipeline from the first day rather than in a policy document written after launch. This is the part of a personalisation programme that our Platform work concentrates on, because the matching model is usually the piece a good internal team can already build.
Three practical lessons were recorded alongside the targets, and they are the least fashionable and most reusable content in the whole plan. Demonstrate the value of analytics early so the business pulls it, rather than pushing analytics at people who did not ask. Adopt market standards and models where possible, on a comply-or-explain basis. Build pragmatic data governance with the team rather than imposing it on them. Each one is an admission that the failure mode here is organisational, not technical.
The outcome
What this engagement produced is a target state, an operating model and a delivery sequence. No forecast was running when the blueprint was written, no cadence engine existed, and the two service blueprints were deliberately set to different data ambitions rather than a single one, because the relationship-led service needs a deeper profile than the high-volume digital service does. Treat every number here as a plan, including the assumption that near real time vacancy data will be available to the suggestion engine at all.
One honest detail in the document is worth keeping. Two of the target-state grids are the same grid, and the one describing the high-volume service still carries a line written for the other. A blueprint is a draft, and a draft in a hurry duplicates.
If the same programme were scoped today, two things would change and one would not. The forecast would be built against event data drawn from the operational systems rather than a curated extract, with process mining over the placement lifecycle to establish where the end-date field actually gets updated and where it silently rots. Features would live in one shared store rather than being recomputed by each team that needs them, so the matching engine and the suggestion engine argue from the same numbers. What would not change is the sequence. Forecast first, cadence second, and cadence gated on evidence that the group can hold to a promise about how often it will write to somebody.
The thing worth taking from this blueprint is not that a staffing group can predict when its own placements come free. It is that the firm wrote the forecast and the contact policy into the same plan, at the same level of seriousness. Most organisations fund the first and improvise the second, then spend a year wondering why engagement fell. Our Consult work now starts by asking what a personalisation programme is allowed to do to somebody's inbox, because that answer constrains the architecture more than any model decision does.