What RevOps Looks Like in Recruitment Agencies

TL;DR: RevOps for a recruitment agency is not about hiring a RevOps person, it is about running your own revenue operation properly: treat BD as sales and delivery as customer success on one shared client record, agree an attribution model before you build any reporting, and measure fill rate, time-to-fill, margin per placement and repeat client rate rather than calls logged and CVs sent. Standard SaaS RevOps playbooks do not transfer, because agency revenue arrives as discrete placement events instead of MRR and a split desk creates attribution questions SaaS never has to answer. Bullhorn, Vincere and JobAdder are ATS-first platforms, so a single revenue view needs either a BI layer on top or a parallel CRM for BD with explicit data ownership rules. The variable that decides whether any of it works is management behaviour: if managers do not run performance conversations off the system, commission-driven consultants will rationally keep their pipeline in their heads.

Why do recruitment agencies need RevOps done differently?

Standard RevOps frameworks were built around subscription revenue. The underlying logic assumes MRR, churn rates, expansion revenue, and a relatively predictable demand curve. None of that applies to a placement-event business. Revenue in a recruitment agency appears in discrete, irregular events - a perm placement, a contract start, a retained search milestone payment. The pipeline between those events is genuinely hard to value because a job order can go cold, get filled internally by the client, or be pulled without a phone call.

Cyclical demand makes forecasting harder still. Hiring volumes shift with macro conditions, sector cycles, and hiring freezes that arrive without warning. A RevOps model that works for a SaaS company in Q4 won't map cleanly onto an agency where November and December are structurally quieter and March can double the pipeline overnight.

Then there's the split-desk problem. Many agencies separate the consultant who wins the job order from the consultant who fills it. That creates attribution ambiguity that no SaaS RevOps framework addresses at all, because in SaaS there is no equivalent of a delivery consultant whose contribution to revenue sits entirely outside the sales motion.

The margin structure adds another layer. Perm fees are one-off. Contract margin accrues over weeks or months. Retained search has milestone payments at brief stage, shortlist stage, and placement. Any reporting layer has to handle all three simultaneously, with different revenue recognition logic for each.

Importing a SaaS RevOps playbook wholesale doesn't just produce imperfect results - it produces reports the business won't trust or act on, because the numbers won't match what consultants experience on the desk.

BD and delivery are your sales and CS: start treating them that way

The parallel is direct. BD consultants prospect, pitch, and win job orders - that is a sales motion in every meaningful sense. Delivery consultants manage the live vacancy, maintain the client relationship through the process, handle objections when a candidate drops out, and manage post-placement satisfaction. That is a customer success motion.

Most agencies don't operate them this way. BD is measured on job orders won and occasionally on revenue attributed to their accounts. Delivery is measured on CVs sent, interviews arranged, and placements made. Neither team has clear line-of-sight to the full client relationship value, and there's typically no shared revenue view at the account level.

The specific failure mode this produces: a client has been placed with twice in twelve months. The BD consultant who owned that account has left. A new BD consultant picks up the account and re-approaches the same client with no knowledge of what was placed, who the candidates were, what the client's preferences are, or where the relationship stands. The delivery consultant who actually managed both vacancies holds all of that knowledge in their head, or buried in notes inside the ATS that nobody is reading.

The fix here is structural, not cultural. A shared client record with full job order history, relationship notes, and account ownership clearly assigned - visible to both BD and delivery, with a defined handoff process when a new vacancy goes live. Account-level ownership rather than vacancy-level ownership. The question "who owns this client?" should have one answer, and that answer should be visible in the system.

In practice this means deciding who updates the client record at each stage, what the minimum required fields are at job order creation, and how relationship history gets captured so it survives consultant turnover. That is RevOps work, even if it doesn't feel like it.

How should you attribute placement revenue on a split desk?

Three attribution models hold up on a split desk: job order owner attribution, where all of the placement revenue goes to the consultant who owns the client and won the vacancy; split attribution, where it is divided by an agreed percentage between BD and delivery, most commonly 60/40 or 50/50; and candidate-source attribution, where part of the credit goes to whoever sourced the candidate. Split attribution is the most equitable of the three and aligns incentives across both functions, but only if the percentage is fixed in advance rather than negotiated deal by deal. Marketing attribution models such as first-touch, last-touch and linear do not transfer, because they were built to credit channels rather than several consultants working one job order across six weeks.

When a placement happens, the revenue has to land somewhere. In a split-desk model, at least three people have a defensible claim: the consultant who developed the client relationship and won the job order, the consultant who sourced or shortlisted the candidate, and potentially a resourcer who did the legwork on the search. Most agencies resolve this informally, which means the resolution is inconsistent, the reporting is untrustworthy, and at least one person feels they were short-changed every time a fee is paid.

Bolting on a marketing-style attribution model doesn't help. First-touch, last-touch, and linear attribution were designed for channel attribution - working out which marketing touchpoint deserves credit for a lead converting. They were not designed for human-to-human sales processes involving multiple consultants across six weeks of a job order lifecycle. Applying them here produces numbers that are technically consistent but behaviourally meaningless.

There are three models that are actually defensible in practice:

1. Job order owner attribution. One hundred percent of the placement revenue is attributed to the consultant who owns the client relationship and won the vacancy. Clean to report and straightforward to implement in Bullhorn or Vincere. The upside is it incentivises business development. The downside is it can demotivate delivery consultants and resourcers who did most of the actual work on a placement but receive no credit in the revenue figures. In a competitive desk environment, this creates resentment quickly.

2. Split attribution. Revenue is divided by an agreed percentage between BD and delivery - 60/40 and 50/50 are the most common splits I see. More equitable, and it aligns incentives across both functions. The catch is that it requires a consistent rule applied at the point of placement, not retrospectively when someone disputes the split. If you're negotiating attribution deal by deal, you've already lost - the conversations will eat more time than the placements are worth.

3. Candidate-source attribution. A portion of credit goes to whoever sourced the candidate, which matters most where there's a dedicated research or resourcing function. Rarely implemented cleanly in practice, because sourcing activity is inconsistently logged. If your Bullhorn records don't reliably capture who added a candidate to a shortlist and when, you can't build a sourcing attribution model on top of that data.

The principle that matters here: you have to define the attribution model before you build any reporting. Build the dashboard first, define the rules second, and you will spend months explaining why the numbers don't match what consultants expect. Nobody will trust the output, and the dashboard will stop being used within a quarter.

Worth noting a specific Bullhorn behaviour here. Bullhorn's native reporting surfaces placement data against the record owner, which defaults to whoever created the placement record. That is often not the person who should be receiving credit - it's whichever consultant or administrator happened to log the placement first. If you're pulling revenue reports from Bullhorn without addressing this, you're reporting against a proxy for attribution rather than an actual model.

Which metrics actually measure a recruitment agency's revenue engine?

Six metrics measure the revenue engine in a recruitment agency: fill rate, time-to-fill, margin per placement, repeat client rate, vacancy-to-placement ratio, and time from job order to first CV sent. Calls logged, CVs sent and interviews arranged measure effort rather than output, which is why a default ATS dashboard can look busy and tell you almost nothing about effectiveness. None of the six come out of the box in Bullhorn, Vincere or JobAdder; each one needs deliberate reporting configuration.

Most Bullhorn and Vincere default dashboards surface activity metrics: calls logged, CVs sent, interviews arranged. These measure effort, not output. A consultant can have a high call volume and a low fill rate. A consultant can send forty CVs to a single client over three months and generate no revenue. Activity data in isolation tells you how busy your team is, not how effective it is.

The metrics that actually reflect the revenue engine are different.

Fill rate - the percentage of job orders that result in a placement - measures both the quality of the vacancies being taken on and the effectiveness of the delivery process. An agency taking on every job order regardless of viability will have a low fill rate and a pipeline full of noise.

Time-to-fill - average days from job order receipt to placement confirmed - affects client satisfaction directly and matters for capacity planning. It also tells you whether a slow pipeline is a sourcing problem or a client-side sign-off problem.

Margin per placement is particularly important for contract desks. Two contract placements at 25% margin outperform five at 10%. Reporting on placement volume without margin per placement is how contract desks end up busy but not profitable.

Repeat client rate - what percentage of clients placed with in a given period return with another vacancy within twelve months - is the single best leading indicator of relationship quality. It is also the metric most directly affected by the BD and delivery alignment problem described above.

Vacancy-to-placement ratio is similar to fill rate but expressed as a volume ratio. Useful for pipeline health and for spotting when a particular sector or consultant is taking on vacancies they can't fill.

Time from job order to first CV sent measures responsiveness. Slow first-CV time is one of the most common reasons clients use multiple agencies on the same vacancy - if you're not back to them within 24 to 48 hours, someone else is.

Building these views requires custom reporting configuration in most ATS platforms. They are not available out of the box in Bullhorn, Vincere, or JobAdder without deliberate setup work.

Building a single source of truth when your CRM wasn't designed for it

Bullhorn, Vincere, and JobAdder are ATS-first platforms. The CRM functionality was added to make them stickier, not built from first principles as a revenue operations tool. The data model reflects that history.

A specific Bullhorn limitation worth understanding: client contacts and candidate records are separate entities. A person who is both a potential candidate and a client contact - common in senior-level or executive recruitment - exists in two separate records with no native link between them. Revenue roll-up at the company level requires custom configuration or an external reporting layer, because the native object hierarchy doesn't support it cleanly. If you're trying to answer "what is this company worth to us across all placements and live vacancies?", Bullhorn won't give you that answer without work.

Option 1: ATS as the source of truth

Keep everything in Bullhorn or Vincere, and build the revenue views in a BI layer on top - Power BI, Looker, or a well-configured Google Looker Studio setup. This works well when all BD activity is consultant-led and there's no inbound marketing motion or complex new business pipeline to track. The risk is twofold: BI tools require ongoing maintenance as your data model evolves, and the data quality in the ATS has to be consistently clean before any of the reporting is trustworthy. Garbage in, clean-looking dashboard out is a real problem here.

Option 2: run a parallel CRM for BD

Use HubSpot for the BD pipeline - new business prospecting, client nurturing, meeting and call tracking - and sync confirmed client data and live job orders back to the ATS for delivery. This works well for agencies with a defined new business function separate from delivery, or agencies running structured outbound campaigns. The risk is sync complexity. When the same contact exists in both HubSpot and Bullhorn, you need a reliable two-way sync and a clear rule about which system owns which data. Without that rule, you end up with conflicting records in both systems and consultants choosing whichever version they prefer.

My view on which approach to use: if all revenue activity happens inside the ATS and there's no meaningful marketing or inbound motion, stay ATS-first and invest in the reporting layer. If you have a separate BD function or run any kind of outbound campaign, the parallel CRM approach gives you more flexibility - but only if you're willing to configure and maintain the sync properly. What I would not do is run the parallel CRM approach informally, with no sync at all and no data ownership rules. That's the worst outcome: BD data in HubSpot, delivery data in Bullhorn, and no shared view of either.

What does RevOps look like at different agency sizes?

At a 10 to 15 person agency, RevOps means data hygiene, three to five agreed revenue metrics, and a weekly pipeline review that BD and delivery sit in together, with no BI layer needed yet. At around 50 people it becomes a structured BD pipeline separate from delivery capacity, margin reporting by sector, consultant and client, an attribution model that is enforced rather than negotiated, and the first useful workflow automation. At 150 people it is a full BI layer with automated daily reporting, cross-team attribution built into the data model, compliance automation, and integration between the ATS, finance system and marketing tooling.

The goal here is to avoid a 15-person agency trying to implement what a 150-person firm needs. The maturity level has to match the operational reality.

At a 10 to 15 person agency, RevOps is mostly about data hygiene and a shared pipeline view. Three to five agreed revenue metrics. A Bullhorn or Vincere instance that the whole team is actually using consistently. Weekly pipeline reviews with BD and delivery in the same conversation, looking at the same numbers. No BI layer needed yet. The measure of success is whether a manager can answer "what are we likely to place this month and with whom?" without building a spreadsheet on the morning of the meeting.

At a 50-person firm, the requirements shift. You need a structured BD pipeline distinct from delivery capacity. Margin reporting by sector, by consultant, and by client. Delivery capacity planning linked to live vacancies so the business can see when it's overcommitted. Some automation starts to make sense here - job order creation workflows, interview scheduling reminders, placement milestone notifications. The attribution model should be defined and enforced, not negotiated deal by deal. A BI layer starts to justify its cost at this size.

At a 150-person firm, you're looking at a full BI layer with automated daily reporting, cross-team attribution built into the data model, compliance automation across right-to-work checks and contract generation, and an integration between the ATS, finance system, and any marketing tooling. At this size, RevOps probably needs to be a dedicated function or at minimum a clearly named responsibility, not something that sits with an ops manager alongside ten other priorities.

The honest observation: most agencies of 50 people are trying to operate at the 150-person level with tooling they haven't configured properly, which means they get the complexity without the benefit.

How do you get commission-driven consultants to adopt process discipline?

Two things move commission-driven consultants: managers running performance conversations exclusively off what is in the system, and making logging fast enough that it stops feeling like a tax on billable time. Poor data hygiene on a commission-heavy desk is a rational response to incentives rather than laziness, because logging costs minutes that could be spent on a call and updating a client record exposes a pipeline to colleagues working competing desks. No CRM fixes that on its own, because it is an incentive alignment problem rather than a technology one.

Most RevOps implementations in recruitment agencies fail here. Not in the tooling choice. Not in the configuration. Here.

You can have a properly configured Bullhorn instance, a sensible pipeline structure, clean data models, and well-built dashboards - and if consultants aren't logging activity consistently, none of it produces accurate output. The question is why they don't log consistently, and the answer is rational, not behavioural.

A commission-heavy consultant's time is money. Logging a speculative CV sent to a client they've been developing takes three minutes they could spend on a call. Updating a client record after a meeting reveals their pipeline to managers and to colleagues who might be working competing desks. In an environment where information is a competitive advantage - internally as much as externally - data hygiene is a rational sacrifice. Consultants aren't being lazy. They're optimising for their own commission.

This is not a technology problem and it is not fixable with a better CRM. It is an incentive alignment problem. If the commission structure rewards placement volume and there is no consequence for poor data quality, the data will be poor. That's not a moral failure - it's a predictable response to the incentive structure in place.

What has to change before process adoption happens: managers have to use the data in performance conversations, and not as an add-on but as the primary source. If a consultant knows their manager will only discuss what's in the system, they have a concrete reason to keep the system current. If the manager asks verbally, uses their own notes, or accepts "I'll send you the update later", the system remains a box-ticking exercise that nobody trusts.

The second lever is making logging fast enough that it doesn't feel punitive. If logging a client interaction requires four screens and two minutes in Bullhorn, consultants won't do it at scale. If it takes one click from an email integration or a mobile app, the barrier is low enough that compliance becomes realistic. This is a configuration and UX problem as much as a discipline problem, and it's worth spending time on it before assuming the team is the issue.

The failure mode I see most often in practice: an agency goes through a full HubSpot or Bullhorn implementation, trains the team, and finds six months later that adoption has drifted back to spreadsheets and verbal pipeline updates. The tooling didn't change. The management behaviour didn't change either - and that was always the variable that mattered.

Where should you start if your agency has no RevOps function today?

Start by auditing what data you actually have and trust, before touching the tech stack at all. Then agree three to five revenue metrics with BD and delivery heads, attribution model included; then get both teams into one shared pipeline view; then build automation on top of the clean process rather than before it. Most agencies stall at the audit because it shows the data is worse than expected, which is information about where the effort needs to go rather than a reason to postpone.

Practical sequencing matters here. There's a logical order of operations, and skipping steps produces predictable problems.

Step one: audit what data you actually have and trust. Before touching the tech stack, walk through what's in the ATS, what's in spreadsheets, and what exists only in people's heads. Identify the three or four questions the business most needs to answer - fill rate, top clients by margin, average time-to-fill - and work out whether the current data can actually answer them. Usually it can't, and that tells you exactly where to start.

Step two: define three to five revenue metrics the whole business agrees on. Not twenty KPIs. Three to five that will go on a dashboard leadership looks at every week. Get BD and delivery heads to sign off on the definitions, including the attribution model. If you can't get agreement on the definitions at this stage, you will not get agreement on the numbers later.

Step three: get BD and delivery into a shared pipeline view. Even if it's a single shared report in Bullhorn or a simple HubSpot pipeline. The goal is that both teams are looking at the same data, not maintaining parallel versions of the truth that diverge every time someone leaves or changes desk.

Step four: build automation on top of clean process. Automation built on inconsistent data makes inconsistent data move faster and creates more noise, not less. Fix the process first, then automate the repetitive parts.

For most agencies, step one is where they get stuck - not because it's technically difficult, but because the audit reveals the data situation is worse than expected. That's not a reason to delay. It's information about where the effort needs to go.

If you want an external view of where your agency actually stands before committing to a rebuild, a Bullhorn audit is the practical starting point. It maps what you have, identifies the gaps, and gives you a sequenced plan for what to fix first - without assuming you need to replace everything to make progress.