Recruitment automation planning for a global recruitment agency

A talent agency is only as good as what it knows about its people. Who applied where, who passed which assessment, who was turned down and why: all of it decides who gets put forward next, and how quickly.

The trouble is that candidates rarely move through one system. An agency keeps its own records, while each client runs its own hiring pipeline on its own platform. Every time a candidate moves forward or drops out on the client's side, the agency's records fall a little further behind, unless someone updates them by hand.

At small scale, that's a chore. At large scale, it becomes a full-time job nobody wants, and a steady source of mistakes.

Gramian Consultancy Group places engineering, data, and AI talent with companies around the world. They're remote-first, with teams across Europe, the Middle East and North Africa, and Latin America, and offices in Skopje, Zagreb, and New Cairo.

Their talent pool holds around 130,000 records, kept in one system that acts as the agency's single source of truth. Putting candidates forward to one of their largest clients was already automated. What came back wasn't. As candidates progressed through that client's hiring pipeline, none of those updates flowed back into Gramian's records.

Keeping them current meant someone had to take exports from the client's platform and compare them, candidate by candidate, against what Gramian's own system said. It was slow, expensive, and exhausting, and the more successful the agency became, the worse it got.

This was an advisory project. Our job wasn't to write the tool. It was to work out exactly what the tool should be, so that when it was built, it would work the first time.

We started with how Gramian's team actually handled these updates: which fields they looked at, what each status really meant, and what they did in the edge cases. We were also clear about the limits. The client platform offers no public API for this data, so instead of proposing a fragile workaround that could break its terms of service, we planned around the exports it does provide.

Much of the manual work was judgment: reading a status and a reviewer's comment, and deciding what should happen to the candidate. We turned that judgment into explicit decision rules.

Rejected candidates get exactly one reason recorded, chosen by a clear order of checks, so the reason is always specific and never ambiguous. Approved candidates have any earlier rejections cleared and move to the right stage of the pipeline, based on where they are in the client's process and how they did in its technical assessment. Written down like this, every rule can be reviewed by the recruiters and tested before it touches real records.

With around 130,000 records at stake, the plan put safety first. The specification set out that the automation must:

• process only what changed since the last run, instead of reworking everything each time
• be safe to re-run, picking up where it left off after an interruption, with no duplicate updates
• keep going when one record fails, logging the problem instead of stopping the whole run
• leave a full audit trail, with a clear summary at the end and a direct link to every record that needs a person to look at it
• keep every credential, stage, and rule in configuration, so the process can change without rewriting the tool

The final specification went beyond requirements. It covered scope, what was deliberately left out, and the assumptions behind every decision, along with our recommendations for the technical design and the rollout: a short first build, followed by a break-in period on real production data to catch the edge cases no plan predicts.

Gramian finished the project in 2026 with a complete, build-ready specification for automating one of their most time-consuming processes.

That's the value of planning done properly. The expensive mistakes in automation projects usually happen before any code is written, when nobody has pinned down what the tool should do in the awkward cases. Getting those answers first means the build is faster, cheaper, and far less likely to surprise anyone once it goes live.