A group running two different businesses on one platform is making a decision about difference, whether or not anyone writes it down. Either the platform is built to the more demanding of the two and the other business pays for capability it will never use, or it is built to the cheaper one and the demanding business quietly starts building its own. The third option is to state, element by element, which of the two each part is being built for, and to state it before the first feature is scoped.
A global staffing and HR services group took the third option in the blueprint behind an integrated platform. Its target state was written as five elements: what customers and talent experience, what the data has to be able to do, how the capability is run across countries, who staffs it, and what it runs on. Two of those five were given a separate destination for each of the two businesses. Three were given one answer for the whole group. That split is the finding, and it is a design decision rather than a compromise.
The challenge
The two businesses do not want the same thing from software. One is a high-volume servicing model whose economics rest on throughput, where the more of a placement that completes without a person touching it, the better the business works. The other is a professional servicing model, where the value is the relationship and the experience across channels, and where speed on its own buys very little.
Both were nonetheless held to one shared set of design principles, written down once and applied to both, and that is what makes the argument for a single platform reviewable rather than assumed. Consistency of experience across every touchpoint and every geography sits in that set, and so does the requirement to build on the brand, the in-house data and the skills the group already has rather than replace them. A group that publishes its principles once and then scores every option against them has a decision it can defend later.
Then the elements diverge, and the document is precise about where.
On experience, the first move named for the high-volume business was to understand the customer well enough to offer accurate straight-through processing. For the professional business, the first move was toward the relationship, so a personalised experience could run across channels without breaks. What matters is that the document names where each business starts, rather than issuing one group target and letting the two argue about it later.
On data, the destination for the high-volume business is the ability to integrate data sets company-wide and build an accurate straight-through-processing algorithm, at a data quality that supports automated matching and near-real-time job suggestions. The destination set for the professional business is the ability to combine internal and external sources into multidimensional personal profiles and deliver tailored experiences from them. One business needs data complete and consistent enough to decide automatically. The other needs data rich enough to say something specific about one person. Those are different engineering programmes wearing the same word.
The approach
The three elements that were not split are the ones where the difference would have cost money rather than earned it.
How the capability is run was answered once for the group: coordinate centrally, recognise that capability and good practice already exist in the local markets, and seat local representation inside the central unit so the coordination is not one-way. Three conditions were named for that to work at all, and all three are about early motion rather than design quality: high engagement, tools that let people do the work, and early mobilisation.
Who staffs it was also answered once. Five skill families were named for the enabling organisation, spanning creative, technology, data, operations and management, with the majority of them needed in the first horizon, both to detail the strategy and to execute it. That is an uncomfortable claim to put in a blueprint, because it front-loads cost ahead of any benefit. Sourcing was to be hybrid: upskill existing staff, hire permanently, and use contractors to move while the first two catch up.
What it runs on was answered once as well. One integrated technology platform to supply the data, the touchpoints and the content, combining a customer-experience play with automated workflow and underpinned by the data work. Three algorithm families were named for that data work, once for the group rather than once per business: matching, job suggestions and demand prediction. The list is single. The data destination behind it is not.
This is the point where a blueprint turns into something we sell. Deciding that two businesses share a platform is a workshop. Deciding which parts of that platform have two acceptance thresholds, and building the pipelines, feature definitions and lineage so a model can be tuned to one threshold without silently failing the other, is a build. The Platform work we do starts from that written split, because a platform specified without it defaults to one threshold and discovers the second in production.
The lessons recorded against those two split elements are all about adoption rather than method, which is the tell of a team that had been through this before. A segmentation model has to be operationalised into a process to change anything, because a model that sits beside the workflow changes nothing. A customer-centric culture is only fully adopted if senior management are seen to live it, which is a claim about visible use rather than sponsorship. Analytics value has to be demonstrated early to create demand pull from the business. Market standards and models should be followed on a comply-or-explain basis so the same choices are not relitigated. Data governance should be built pragmatically and with the team rather than issued at it.
The outcome
What this engagement produced is a target-state definition, a set of design principles applied to both businesses, a recommended operating shape, a sourcing recommendation and a written set of lessons. It is a blueprint. No throughput figure, adoption rate or match-quality measurement is reported against any of it, and none should be inferred. The destinations are destinations.
The honest question is what would be done differently running the same exercise now. Two things.
The destinations for the high-volume business are directly measurable and were set by discussion instead. The share of placements completing without a person touching them, the share of matches accepted without a recruiter edit, the delay between a vacancy appearing and a suggestion reaching a candidate: all of it is event data a placement workflow already emits. Process mining over those events gives the same target with a source attached and a number that refreshes, which turns an agreed ambition into a tracked one.
The professional destination needs a different instrument. Multidimensional profiles built from internal and external sources are only trustworthy if a reader can tell which field came from where. That is feature-store and lineage work, decided at the same time as the data model rather than after it, and it is the thing that lets the same platform serve a business that needs completeness and a business that needs richness without either one corrupting the other's records.
The current wave of cautious language-model pilots in document handling and candidate screening changes none of this. A model that reads a CV well still has to write its answer into a record whose fields have owners and tolerances, and those tolerances differ by business. Our Consult engagements start by asking which threshold a pilot is being judged against, because a pilot with two unstated thresholds passes and fails at the same time.
One platform carrying two ambitions works only where the difference is written into the target state. Left unwritten, it does not disappear. It gets renegotiated in every feature refinement, by whoever is in the room.