A multi-vertical construction company is really several companies wearing one name. The verticals price work differently, staff projects differently and answer to different clients — so they hire differently too. Designations that matter in one barely exist in another, approval chains run through different people, and each vertical is convinced, usually with reason, that its way reflects what its work actually demands.
Then someone proposes one hiring system for the whole group, and the tension surfaces immediately. Software wants uniformity; verticals want fidelity. Most projects resolve the tension by force — one standard process, imposed everywhere — and then wonder why half the organisation drifts back to email and spreadsheets within a quarter.
When we built Vensar ATS, an end-to-end recruitment platform for a construction company running five verticals, we took the other route: standardise where it helps, stay faithful where it matters. Telling those two apart was the real project.
The flattening temptation
Uniformity is seductive because it is cheap. One process means one configuration, one training deck, one set of reports. Generic hiring templates assume it, vendors prefer it, and on a slide it looks like discipline — five untidy processes replaced by one clean one.
But a process is not untidy just because it varies. If a vertical routes certain hires through an extra approver, there is usually a reason behind it — a hard lesson, a client requirement, a cost structure the other verticals do not share. Flatten that, and the system stops matching reality on its first day.
And people are unsentimental about systems that do not match reality. They do not file objections; they simply stop using the system. The requisition that cannot follow the real chain gets approved over WhatsApp instead, and the new platform becomes a place where decisions are recorded after the fact, if they are recorded at all.
The irony is that forced uniformity does not even deliver the efficiency it promises. A standard process that fits nobody generates exceptions everywhere, and exceptions handled outside the system are the most expensive kind — invisible, unauditable and slow.
Habit or requirement
The honest starting point is admitting that not every difference deserves to survive. Some variation is habit — a form designed years ago for a problem that no longer exists, a step added around a person who has since left. Habit can be standardised away, and nobody will miss it.
Other differences encode what a sector genuinely demands: which documents must be verified for which roles, who is accountable for a hiring decision at each designation tier, which exceptions are legitimate and who may invoke them. Erase these and you have not simplified the business — you have blinded the software to it.
Telling the two apart cannot be done from a conference room. It meant mapping how each of Vensar's verticals actually hires — sitting with the people who run the process, tracing the hierarchies and policies, and writing down every exception together with the reason it exists. That map, not a template, became the design.
The mapping also surfaced rules nobody had written down — approvals that existed only in practice, tiers that behaved one way on paper and another on site. Knowledge like that usually lives in a few heads. Turning it into explicit structure was worth nearly as much as the software that followed.
One pipeline, five chains
What emerged was a clean split. The pipeline was standardised for everyone: screening → document verification → salary negotiation → offer → joining. Every candidate in every vertical moves through the same stages, so the whole company finally speaks one language about where any candidate stands.
The approval chains were not standardised. Manpower requisitions travel through the company's own chain — the real one, with every designation tier and every exception the verticals actually use — and automatic reminders keep files moving, so no requisition sits on a desk. The chains differ; the discipline is identical.
This split is what made the system adoptable. Managers recognised their own process on the screen — their chain, their tiers, their exceptions — so there was nothing to work around. The uniformity lives where it helps everyone and inconveniences no one: in the stages, the records and the reporting.
Standardise the pipeline; let each vertical keep the rules it actually runs on.
What one system made possible
Once all five verticals hired inside one system, things became possible that no vertical could manage alone. Surplus staff on a project winding down in one vertical became visible to projects ramping up in another — and redeployment now comes before any new hiring spend, because the company checks inside before it shops outside.
The talent pool consolidated the same way. Every resume from every vertical is captured — 100% of them, evaluated rather than lost — with duplicates merged into single candidate records and promising candidates pooled for future roles. A candidate one vertical passed over can be exactly right for another, and now that match can actually happen.
The candidate-facing busywork was automated once, for everyone: offers shared as private accept/decline links that are trackable, revocable and fully audited, and candidates kept informed over email and WhatsApp from first contact to joining day. Altogether, the company saved 70% of the time and effort hiring used to take — and the hires improved, because selection now draws on the full pool rather than the resumes someone remembered.
None of these gains required any vertical to hire like another. They came from the shared plumbing underneath — one pipeline, one pool, one set of automated follow-ups — running quietly under five different sets of rules.
Uniform where it helps, faithful where it matters
The principle travels well beyond hiring. Any multi-vertical company adopting shared software faces the same fork: flatten the differences and lose the organisation, or preserve every quirk and lose the point of having one system. The way through is to sort each difference honestly — habit or requirement — and build accordingly.
It is why we begin every engagement by studying the rules a business actually runs on — who approves what, how people are informed, what each sector demands — before designing anything. Different industries, one approach: build around your real rules, automate the busywork, keep your people in control of the decisions.
Five verticals, one system — and no vertical was asked to become another. That is the version of standardisation worth paying for: not the one that flattens your differences, but the one that keeps the differences that matter and finally makes everything around them move.