Why Recruitment Agencies Cannot Run on an In-House ATS
Using Greenhouse, Ashby, or Lever as a recruitment agency? Here's the architectural reason why it does not work - and what breaks within six months.
I made this mistake myself.
When I started ScalingPPL, I used tools that were built for the companies I was recruiting for — because those were the tools I knew. It worked until it did not. The moment I had three clients running simultaneously, the architecture started fighting me. Candidate confidentiality between clients was a manual process. Client shortlist delivery was a PDF email. Revenue tracking was a spreadsheet I updated when I remembered to.
None of that was a process failure. It was a tooling failure. I was using tools designed for one employer, one pipeline, one set of hiring managers. I was running five clients.
Here is the architectural reason this always breaks.
The single-entity problem
Every major in-house ATS — Greenhouse, Ashby, Lever, Workable — is built on a single-entity model. One company. One set of hiring managers. One candidate pool that belongs to that company. The data model reflects this: there is no "client" entity because there does not need to be one. In-house teams do not have clients.
Recruitment agencies are multi-entity operations. Client A and Client B are two separate businesses with two separate confidentiality requirements. A candidate active in Client A's CFO search must be invisible to Client B's hiring manager — not through a permission workaround, but structurally, at the data level.
Pickr is built multi-entity from the start: agencies get client-level isolation, cross-client matching and client portals, while in-house teams run the same system against a single employer. The distinction is not agency software versus company software. It is whether the data model has a client entity at all.
When you take a single-entity ATS and try to run multi-client operations on it, you immediately need workarounds for the things the data model does not support. And workarounds compound. The first workaround is a tag. The second is a separate account. The third is a spreadsheet. By month six, you have an ATS you use for the bits it handles and a spreadsheet system for the bits it does not.
The four things that break specifically
Candidate confidentiality. Without client-level data isolation built into the architecture, you are one misconfiguration away from a client seeing candidates they should not see. In practice, most agencies manage this through discipline and careful access controls. In practice, discipline fails under pressure. One accidental disclosure is enough to damage a client relationship that took two years to build.
Client shortlist delivery. In a properly designed agency ATS, a client logs into their portal and sees their pipeline, their candidates, their feedback forms. In an in-house ATS repurposed for agency use, you create a PDF, write an email, wait for a reply, update the system manually with their feedback. This workflow does not scale beyond three clients before it becomes a genuine operational problem.
Revenue and placement tracking. In-house tools track hires. They do not track placement fees, retainer installments, margin per role, or billed-versus-collected per client. If your ATS cannot tell you your revenue pipeline, you are running your business finances in Excel alongside your recruiting operations. That means two sources of truth and at least one of them is always wrong.
Cross-client candidate matching. When a new brief comes in from Client B, your best lead might be a candidate currently in Client A's process who is not the right fit there but is ideal here. A properly designed agency ATS surfaces this at the recruiter level while keeping it invisible to both clients. In an in-house ATS, this match either gets missed or requires manual cross-referencing across separate views.
The migration cost is lower than you think
The most common reason agencies stay on the wrong tool is the data migration argument. Years of candidate history, notes, application records.
Modern agency ATS platforms import from Greenhouse, Ashby, and Lever via API. The actual migration takes 24-48 hours. The data does not disappear — it moves. The real cost is one week of parallel operation while the team transitions. That is a one-time cost against the ongoing cost of building workarounds into every search you run. If you want that ongoing cost in euros and hours before you move anything, the free recruiting process audit takes about two minutes and no signup.
Frequently Asked Questions
Can a recruitment agency use Greenhouse?
Greenhouse is designed for in-house talent teams with a single employer. It lacks native multi-client management, client portals, and placement tracking. Agencies using Greenhouse consistently build manual workarounds within 6 months.
What makes an ATS suitable for recruitment agencies?
Client-level data isolation, cross-client candidate matching with confidentiality rules, a client portal for shortlist review and feedback, placement fee tracking, and proof-of-delivery reporting. These features require an agency-native data model, not in-house architecture with permissions layered on top.
How hard is it to switch ATS platforms?
Less hard than it feels. Data migration from major ATS platforms takes 24-48 hours via API import. Full team onboarding typically takes one week. Most agencies that migrate report wishing they had done it sooner.
Free recruiting audit · 2 minutes
Find out what your hiring process is actually costing you.
Answer eight questions, or connect your current system read-only, and get a report on where your funnel loses candidates and which changes are worth making. No signup, no API key stored, data stays in the EU.
Written by Andreas Amann
Founder of Pickr. Former operator at startups in Berlin and Silicon Valley, where he helped scale companies from 40 to 200+ people. Built Pickr after years of using every major ATS as a recruitment agency owner at ScalingPPL.