A recruitment agency's pipeline finally matches how its placements actually happen

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

A specialist recruitment agency placing senior candidates into permanent roles, run by a director and a bench of consultants who each own their own book of client companies. Placements happen through phone calls, shortlists assembled in private documents, and relationships the consultants guard individually — that personal ownership is how the agency has traded for over a decade. HubSpot was bought some eighteen months earlier with the intention of professionalising the pipeline, and the data went in, but the working truth of every placement still lived in the consultants' own spreadsheets.

What it was costing

The agency ran HubSpot with the default sales pipeline — 'Appointment scheduled, Qualified to buy...' — which described nothing about recruiting. Consultants kept private spreadsheets, deals stalled in stages that meant different things to different people, and the weekly pipeline review was fiction.

What they could see

• Every consultant maintains a private spreadsheet of live roles, candidates, and placements — the shared pipeline review reads from the CRM and describes a world nobody recognises.
• The same stage name means different things to different consultants; a deal marked shortlist can be any of three different situations.
• Right-to-work documents sit in email threads and drives, with no record in the CRM of whether a check exists or where it lives.
• When a consultant takes leave, their placements stall — nobody can pick up a role without a guided tour of the spreadsheet.
• Client companies and candidates are all contacts in one undifferentiated pile; the CRM cannot express that a placement connects two different parties.

The constraints we worked inside

• The consultants' spreadsheets were genuinely better tools — the pipeline had to adopt their logic or die in adoption.
• Client and candidate were both customers; the CRM's single-pipeline default fought that reality.
• Compliance data (right-to-work) sat in documents; the CRM had to reference, never store, sensitive detail.

What had been tried before

Management announced a pipeline-hygiene drive: consultants were asked to keep the default HubSpot pipeline current after every call.

The default stages described software sales, so every update meant translating recruiting into a vocabulary nobody on the desk used.

An operations hire spent a summer consolidating the consultants' spreadsheets into one shared tracker with agreed column names.

Each consultant's book works differently, and the shared tracker demanded the lowest common denominator; within a month everyone was back in their private copy.

A dedicated recruitment CRM was trialled with two volunteer consultants the year before we arrived.

Migration meant abandoning paid HubSpot seats and retraining the desk, and the trial found its candidate records weaker than the spreadsheets it was meant to replace.

What we proposed

The proposal rebuilt the CRM around the placement itself: a pipeline whose stages follow the agency's real funnel — intake call, role brief, shortlist, interviews, offer, placed, invoiced — with exit criteria written in the consultants' own words. Client companies and candidates become two linked record types with separate lifecycles, so a placement is a relationship between records rather than a note on a contact. Compliance stays out of the database: the CRM records that a right-to-work check exists and where it lives, never the document's contents. Each consultant's spreadsheet was then imported, their columns rebuilt as saved views, and retirement negotiated per consultant on their own timeline.

Just as important is what we ruled out, and why:

• A dedicated recruitment CRM — Licensing a second platform mid-season meant retraining the whole desk and abandoning paid HubSpot seats, while its candidate model had already lost a trial here.
• Custom-built CRM on a low-code base — A bespoke build needs a developer for every change; a six-week engagement cannot hand over custom software with confidence.
• Syncing the spreadsheets into the CRM — Two masters means permanent conflicts, and the sync would preserve the very fragmentation — per-consultant logic — the engagement was meant to end.

How the work ran

Delivered by the systems pod — automation specialist over 6 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

HubSpot CRM

Seats were already paid and the desk knew the name; switching platforms mid-season would have cost two pipelines' worth of goodwill for no capability gain.

Custom object schema

Candidates and client companies need separate lifecycles; a single contacts object cannot express that a placement connects two parties with different needs.

Pipelines & deals

Deals map naturally to live placements, and exit criteria per stage force the shared language the spreadsheets had maintained privately.

Saved views

Each consultant's spreadsheet columns reappear as filters, so adopting the CRM meant keeping their view of the world, not learning ours.

Import tooling

Each private tracker had its own column conventions and quirks, so the move needed repeatable cleaning and mapping rather than one heroic paste.

What went wrong

How we worked together

Cadence

A weekly stage-design workshop with the operations manager and two senior consultants, plus a short Friday demo to the whole desk; adoption questions were answered at the demo, not by email.

Client side

Two senior consultants formed the design pair whose sign-off carried the desk's trust; the operations manager ran the project's schedule and kept the data moving.

Decisions

Stage names and exit criteria were taken verbatim from the consultants' vocabulary; anything the workshop could not settle went to the director, who decided within the week.

They provided

Exports of every consultant's tracker, the compliance policy governing right-to-work data, and an hour a week from each design consultant through the schema work.

What changed

The headline: deals per consultant progressed past 'shortlist' per week, first full quarter — 2 → 5, read from CRM stage-report vs prior spreadsheets. A second check: consultant shadow spreadsheets still in use at 0.

The weekly pipeline review stopped being a performance and became a working meeting — the numbers on the screen were the numbers the desk recognised. Consultants answer for each other's roles on leave days without a handover ritual, and a placement can be discussed in the room without its owner present. The spreadsheets did not die in a ceremony; each consultant simply stopped opening theirs in their own week, and nobody asked for them back.

The result was read from CRM stage-report vs prior spreadsheets against the pre-engagement baseline over the stated window, with a guardrail check on consultant shadow spreadsheets still in use. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The pipeline schema document — stages, exit criteria, and the linked candidate–client object model — written for the agency's own reference.
• A saved-view library mirroring every consultant's former spreadsheet columns, editable by the ops manager.
• A repeatable import template and cleaning checklist for future bulk candidate uploads.
• Admin credentials, permission sets, and the compliance rule that keeps document contents out of the CRM.