Where RecruitCRM Reporting Stops (And What to Do About It)

Every agency owner eventually goes looking in RecruitCRM for one specific number, doesn't find it, and exports to a spreadsheet instead. The spreadsheet then becomes a monthly ritual. Somebody rebuilds it on a Friday, this month's version disagrees with last month's, and the trend line nobody quite believes gets presented at the partner meeting anyway.

That isn't a criticism of the product. RecruitCRM is a good ATS and its reporting does the job it was built for. The trouble is that the job it was built for ends roughly where the questions that decide how you run desks begin.

This post covers what the built-in reporting genuinely handles, the structural reason it stops where it does, the four questions that break it, and the path we use to answer those questions properly. It also covers the sequencing mistake that produces dashboards which are confidently wrong, which is a worse position to be in than having no dashboard.

What the built-in reporting does well

Credit where the platform earns it. Without building anything you get:

• Current pipeline by stage, per job and per recruiter.
• Activity counts over a chosen window: calls logged, emails sent, candidates added, submissions made.
• Open jobs and how long they've been open.
• Placements in a period with fee totals attached.
• Filtered candidate and company lists you can slice by whatever fields you've populated.

Those answer the operational questions a manager asks on a Monday morning. What's moving, who's busy, what's stuck. If your reporting need is "what is happening right now," the platform covers it, and building anything else is wasted money.

The questions that break it share a shape. They compare something to something else, over time.

Why an ATS can't answer the next question

An ATS is a system of record for current state. That one sentence explains nearly every reporting limit you'll hit in RecruitCRM, Bullhorn, Loxo, or anything else in the category.

A candidate-on-job record holds a status. When that record moves from Submitted to Interviewing to Offer to Placed, the status field gets overwritten each time. The record tells you where things stand today. It does not hold, in any form you can query, where things stood last March, how many days it sat at each step, or how many records now sitting at Placed passed through Submitted during Q2.

People reach for activity logs and audit trails at this point, and those are the wrong shape for the job. An audit trail is built to answer "what happened to this one record," for troubleshooting and compliance. It's a per-record narrative, not a model you can aggregate across twelve thousand records and twelve months. By the time you've reshaped it into something you can group and average, you've built a warehouse with extra steps.

There's a second constraint sitting underneath the first. An ATS is tuned for the working recruiter: fast reads on one record, fast writes when a status changes, hundreds of small requests a minute from people with a phone to their ear. Analytical questions want the opposite access pattern, scanning everything and aggregating it. Vendors quite reasonably protect the transactional workload from the analytical one, and that protection shows up as API rate limits, export row caps, and reports that time out. You aren't fighting a missing feature. You're fighting a design decision that's correct for the product.

So the fix isn't a better report inside the ATS. It's holding history somewhere the ATS doesn't have to.

The four questions that break

Submittal-to-placement by desk, over twelve months

This is the question that actually tells you where to put your next hire, and it's compound. It needs a submittal count per desk per month, a placement count per desk per month, an attribution rule linking the two across a gap of weeks or months, and a stable definition of what a desk is when recruiters move between them.

The ATS can tell you today's ratio for today's pipeline. It can't tell you that the Boston desk's ratio drifted across three quarters while headcount stayed flat, because the states it would need to compare were overwritten as they changed.

Fee realization against what was quoted

Agencies quote a fee basis and then collect something else. Discounts get agreed mid-search. Guarantee clawbacks land in a later month than the placement. A percentage gets renegotiated when the salary comes in above band, and the flat fee on a two-hire deal isn't the flat fee on one.

Answering "what share of quoted fee do we actually realize, by client and by role family" needs the quoted figure preserved as of the moment it was quoted, plus the invoiced figure, the collected figure, and the credits. The ATS holds the current fee on the current record. The quote history mostly lives in email. This is the number most likely to change how you price, and it's the one almost nobody has.

Source performance over time

Where do placements come from, and is that changing? To answer it you need a source stamped on every record at creation, a source taxonomy that means the same thing in January as it does in December, and the ability to follow a cohort of candidates sourced in a given month through to placements that happen months later.

Two things break this in practice. Sources get typed by hand into a free-text field, so you end up with six spellings of four concepts. And the taxonomy gets edited in place, so records created under the old scheme silently reclassify themselves. Both are data-definition problems rather than reporting problems, which is a point worth holding on to for the next section.

Recruiter cohort comparisons

Comparing a recruiter who started in January against one who started in July means normalizing on tenure rather than on the calendar. Month three versus month three. Ramp curves, not raw totals.

Every ATS view is calendar-based, because that's what an operator needs. Cohort analysis needs a per-person clock and it needs the last two years of activity still sitting there to run against. This is how you find out whether your onboarding got better or your market did.

The sequencing trap

Here's the mistake we watch agencies make, and it's expensive precisely because it feels like progress.

They decide reporting is the priority, commission dashboards, and build them on top of an ATS where the source field is free text, three stages mean different things to different desks, and the same candidate exists twice under two spellings of their name. The dashboards ship. They look excellent. Every number on them is wrong in a way that's invisible, because a chart carries an authority the old spreadsheet never did.

Then it gets worse. Somebody spots one figure that's obviously off, and the whole thing loses credibility at once. The next reporting project is harder to fund than the first was, and everyone goes back to the Friday spreadsheet, which at least they knew to distrust.

Do the definitions first. Not as a preamble to the real work. As the work:

1. Agree what each stage means, in writing, with the desks that use them. Submitted means the CV reached the client, not that the recruiter intended to send it. Interviewing means an interview is scheduled, not suggested. Pick the version you'll defend and write it down.
2. Fix the duplicates before you count anything. Two records for one candidate make your submittal counts and your ratios both wrong, in different directions. Our CRM data quality playbook runs the same sequence we use here: dedupe first, normalize second, enrich third, because any other order creates rework.
3. Lock the source and role-family taxonomies, and version them instead of editing in place. When a category changes, old records keep their old label and you map between versions downstream.
4. Decide which fields are load-bearing for reporting and make those required at entry. The rest can stay optional. A field that's mandatory in a policy document and blank on forty percent of records is just a field.

This part is unglamorous and it's most of the value. It's also why our RecruitCRM consulting engagements open with an audit and a definitions pass rather than a build. Automating on top of an ambiguous field set produces confidently wrong output faster, which is not what anyone thinks they're buying.

The path that actually works

Once the definitions hold, the technical shape is straightforward and it hasn't changed much in twenty years.

Scheduled extracts. A job runs on a schedule (nightly is fine for almost everyone) and pulls candidates, jobs, applications, placements, activities, and companies out of the RecruitCRM API into a Postgres database you control. Pull incrementally off a modified timestamp so you aren't re-fetching everything and colliding with the rate limit. We build these in self-hosted n8n so the logic stays visible and yours rather than buried inside a per-connection subscription.

A change ledger, not just a snapshot. This is the part people skip and later regret. If your nightly job overwrites yesterday's rows, you've built a mirror of current state and inherited the exact limitation you were trying to escape. Write a row every time a tracked field changes instead: record id, field, old value, new value, timestamp. That ledger is what makes "how long did this sit at Interviewing" and "what did the pipeline look like on March 1" answerable at all. Start it early, because it only accumulates history going forward and you can't backfill what the ATS already overwrote.

A modeling layer. Raw extracts aren't reportable. Between the ledger and the charts sits a set of views that apply the stage definitions consistently, resolve a recruiter to a desk as of a given date, attribute a placement back to the submittal that started it, and hold quoted fee alongside invoiced and collected. This is where the definitions from the previous section turn into code, and it's where most of the thinking goes.

Dashboards last. With all that underneath, the front end is nearly incidental. Metabase, Looker Studio, Power BI, or a small internal app all work, and the choice matters far less than people expect. Scheduled email digests often beat dashboards on adoption, because the number arrives where the manager already is instead of waiting behind a login.

The same pattern shows up across RevOps and data work whatever the industry, and there's more on how it fits a desk-based agency in our recruiting and staffing breakdown.

What it costs, and when to skip it

Our tiers are published, so here's the honest mapping. A definitions and data-quality pass on an existing RecruitCRM lands in the Workflow tier, $2,400 to $6,000 across two to four weeks, and it stands alone as a piece of work whether or not you build reporting afterwards. Extracts plus a warehouse plus a first set of dashboards is Orchestration territory, $6,000 to $13,500 across four to eight weeks. Our rate is $150 an hour and the project minimum is $2,500.

Now the case against. If you're a two-desk agency doing a handful of placements a month, the warehouse is overkill, and the money is better spent on the data-quality pass alone while you keep using the built-in reports. If nobody has ever changed a decision because of a number in a report, better numbers won't change that either, and what you have is a management problem wearing a reporting costume. And if your definitions are genuinely contested, meaning two partners disagree about what Submitted means, settle that in a room before anyone writes a query. A warehouse will faithfully compute both answers and let you argue about them at higher resolution.

The rule we apply: build reporting when a recurring decision depends on a number you can't currently get, and name that decision out loud before starting.

One asymmetry worth acting on now

There's a reason this decision doesn't wait politely for you to be ready, and it isn't a sales argument.

Every other piece of this is reversible. Definitions can be rewritten. Duplicates can be merged next quarter as easily as this one. A dashboard built on the wrong model gets rebuilt, annoyingly, but it gets rebuilt. The change ledger is the exception. It only records what happens after you switch it on, and the states the ATS overwrote last Tuesday are gone in a way no amount of budget recovers. Wait twelve months to start and your first cohort analysis is twelve months away from being possible, no matter how much you spend on the day you finally decide.

That inverts the usual sequencing advice, and it's the one place we'll tell an agency to spend money before the definitions are settled. A nightly job writing field changes to a table costs very little to stand up and nothing to ignore. It's insurance against a decision you haven't made yet. If you think there's any chance you'll want desk-level trend reporting inside two years, turn the recorder on this quarter and argue about what Submitted means while it runs.

Everything else on this page can start whenever you're ready. If you'd like a second read on which of those jobs you actually have, bring us one question your Friday spreadsheet is supposed to answer. That question alone usually settles it.