Mankind Recruitment OS

The problem

A small executive search team was losing about half of every working day to admin. Every candidate profile took 50 minutes to put together: reading the CV, cross-checking LinkedIn, writing it up, redacting it, formatting it for the client. Around that sat scheduling, verification, forms and filing. Roughly four hours a day of work that wasn’t search.

The obvious fix was to buy software. Recruitment platforms exist and the pitch is always the same: a demo, a six-figure commitment, a six-month rollout, and the hope that the team uses it once it arrives.

I didn’t think the admin was the problem. It was the symptom I could see. I wanted the cause before spending anything.

What I found when I did the work manually

I did the job myself for four weeks before building anything. Same tools, same deadlines, same mandates.

The four hours were real, but two problems sat underneath them.

“Good” had no definition. Every consultant could tell a strong candidate from a weak one, and every consultant was measuring something slightly different. One weighted tenure, another the calibre of previous employers, a third how the person came across on a call. None of it was written down. It worked because the same few people made every call.

That is exactly the kind of process people want to hand to AI, and exactly the kind that breaks when you do. A model asked to judge “good” when good has three private meanings doesn’t settle the question. It picks an answer, a different one on a different day, and produces it fast and confidently. You cannot automate judgement. You can only automate a standard, and there wasn’t one.

The firm had no memory. When a strong candidate didn’t get an offer, they left the process and effectively left the firm. Their profile sat in someone’s inbox. Six months later a new mandate needed the same person and the firm paid to find them again. It was buying knowledge it already owned.

Neither problem could be fixed by buying software. Both could be made worse by it.

What I built

Step one was a standard, not code. Before writing anything I sat with the head-hunters and worked through how they read a job description: which requirements actually decide a hire, which are filler, and how they weight one against another. That conversation was the real engineering. What I built afterwards was a prompt that applies their logic.

The system now reads the job description for a role, identifies up to eight criteria that matter, weights them by importance, and generates a rubric scored out of 100. Every CV for that role is scored against that same rubric. The model isn’t deciding what good looks like. Experienced recruiters did that, once, out loud, and the system applies it consistently.

Step two was testing adoption before paying for it. The risk with operational software is rarely whether it works. It’s whether anyone uses it. So I procured nothing. I built on tools the firm already had, for $27 a month, to find out cheaply whether working habits would change. If they didn’t, the loss was a month’s subscription.

Step three was the system.

• ClickUp is the backbone. Every candidate and mandate is a task moving through a defined workflow, so status is visible rather than remembered.
• Custom JavaScript is the bridge, moving data between ClickUp and the model only when someone deliberately triggers an action.
• Claude is the evaluation layer, extracting structure from CVs and scoring them against the rubric.

It runs on a private server behind a browser interface, so nobody on the team touches infrastructure. A tool that feels like homework doesn’t get used.

The pipelines make the split visible. The system runs two: eight steps for a vacancy, ten for a candidate. Every step is labelled either BY HAND or AUTOMATIC, and the label is a decision, not a description of what’s technically possible. Anything that involves judgement stays by hand. Anything that only moves, formats or checks information is automatic, wired to specific ClickUp fields so each step sets the task’s status itself. The redaction step that builds the client-facing profile sits on the automatic side, because once you’ve decided what a client should and shouldn’t see, applying it is clerical. Reading that list is the fastest way to understand the system: the automatic steps are the admin I was losing four hours a day to, and the by-hand steps are the job.

I designed the system: the workflow, the rubric logic, and the rules governing what the model may and may not do. AI wrote the code. That split is deliberate. The hard part here was never the JavaScript. It was deciding what the JavaScript should do.

(opens the full-size image in a new tab)

(opens the full-size image in a new tab)

(opens the full-size image in a new tab)

Two rules shaped the design. No scraping: profiles are viewed legitimately and only documents we’re given get processed. And every CV is redacted before it leaves the firm, so a client can assess a candidate without being able to go around the search and contact them directly. Both cost speed. Both protect the business the system exists to serve.

What changed

Profile creation went from 50 minutes to 15. My own daily admin went from about four hours to 45 minutes. Running cost is $27 a month.

The memory problem closed too. Every candidate is now a structured, rubric-scored record rather than a note in an inbox. I’ve placed candidates who missed out on one mandate and were found again for the next, instead of being sourced from scratch.

The same tooling has since screened 458 applications against job descriptions for a separate research engagement, described in One method, three reports.

The speed came from defining good before automating. With an explicit standard in place, the model had something consistent to apply. Without one, the same system would have produced the old inconsistency three times faster.

What I would do differently

The system worked. Adoption didn’t. I built it for the team and I’m still its main user. I spend measurably less time on admin than colleagues doing the same work, and they haven’t switched.

The $27 test did exactly what it was designed to do. It proved the tool worked and the habits hadn’t moved, before anyone committed six figures to learning the same thing. That’s the cheap version of a failure most companies buy at full price.

What I’d change is the order. I extracted the rubric logic from my colleagues, then went away and built. Next time they’d help shape the thing itself from the start, so the system arrives as theirs rather than as mine to sell to them.

Next step

If your team is about to buy software to fix a process nobody has written down, talk to me first.

Book a call↗ (opens in a new tab)