Recruitment in construction runs on job board email. A growing groundworks contractor hires constantly, and most of that hiring is site trades: applications arrive as job board emails, dozens at a time, each with a CV attached and no two laid out the same way.
Every one of them used to be opened, read, judged and typed into the board the team actually works from. Then the candidate had to be contacted, a questionnaire sent, the answers chased, an interview slot agreed by email, the diary updated, and the outcome fed back.
Two things go wrong at that volume, and both cost hires. Work gets re-keyed, so the record is only ever as good as the last person who had time to update it. And the response is slow, which matters more in trades than almost anywhere else: a good groundworker who applies on Monday has other offers by Wednesday. The business that replies first wins, and an inbox does not reply first.
We built M Squared a six-stage recruitment pipeline that runs continuously and covers every step from the application landing to the interview being booked and the outcome sent.
It checks the mailbox every minute. When an application arrives, AI reads the CV itself and returns structured facts rather than a wall of text. The document is filed, the candidate is created on the board the team already works in with the CV attached, and the team is notified. From there the pipeline scores the questionnaire, messages the candidate on shortlist, issues a personal interview booking link, records the booking when a slot is taken, and sends the outcome afterwards.
The CV is read, not parsed. A screening agent opens the attachment and returns structured facts: the role applied for, relevant experience, skills and tickets held. Job board formats change constantly, and a template-based parser breaks every time they do. Reading the document does not.
Every candidate reaches the board with their CV attached. The file is stored and attached to the candidate record, so whoever is hiring opens one item and has everything, instead of going back to the inbox to find the attachment.
Scoring runs against the role, not the person. Site trades and office roles are scored on separate criteria, because they are different jobs with different requirements. The score sorts a list for a human to work through. It does not reject anyone.
Everything goes out by email and by SMS. This is the most important decision on the project. Site trades do not sit in an inbox. Shortlist messages, interview invitations and outcomes all send both ways, and that is the difference between a booked interview and silence.
Candidates book their own interview. Each one receives a personal, single-use booking link, so there is no diary tennis. When they take a slot the interview date lands on their record automatically. If they cancel, the status reverts and the date clears, rather than leaving a ghost in the diary that somebody has to notice.
Every stage writes an audit line. Each step posts into the team channel as it happens, so hiring managers watch the pipeline move without opening anything.
Most recruitment software is built for office hiring: a considered application, a candidate who checks email daily, a process measured in weeks. Construction hiring breaks all three assumptions, which is why generic tools underperform in it.
The volume is different. A contractor winning work needs groundworkers, operators and labourers in numbers, quickly, and often for a start date already in the programme. Applications arrive in bursts tied to job board activity rather than in a steady trickle.
The candidate is different. Someone on site does not sit at a desk. They will read a text between deliveries and may not open an email for days. A process that only emails is a process that loses people who were interested.
The speed bar is different. In trades, availability is the whole game. A candidate who applies today is talking to other contractors this week, and the one who gets back to them first usually gets them. That is not a nice-to-have in a market where a delayed start costs money on the programme.
Every design decision in this pipeline follows from those three facts: it runs continuously rather than in batches, it sends by text as well as email, and it lets the candidate book a slot themselves rather than waiting for a manager to find a gap.
Most recruitment automation is a demo that breaks in week three. The difference between a demo and a system is what happens when something fails at two in the morning, and that is where most of the engineering goes.
Applications are de-duplicated by message, so a retry or a replay cannot create the same candidate twice. Credentials refresh on a schedule of their own, rather than expiring quietly and taking the pipeline down with them. A heartbeat confirms the pipeline is alive. An error trigger raises a failure the moment a step fails, instead of the team discovering it when nobody has applied for a week. And the AI has a fallback model, so an outage upstream does not stop applications being processed.
None of that demos well and all of it is why this runs continuously rather than being switched on when somebody remembers.
Recruitment was one process. It proved the approach, and the same principles now run across the business in the operating system we built them: work that crosses teams, a record that updates itself, and AI doing the reading rather than a person.
Tell us where your team loses the most time. We will tell you honestly whether AI pays there, what it takes to build, and what we have already delivered for businesses like yours.
We use cookies to measure how the site is used and, if you allow it, for advertising. Nothing is set until you choose. Privacy policy.