Multi-client recruitment management requires specific architectural features. Here's exactly what they are and the test to determine if your current ATS has them.
Running a recruitment agency with three or more active clients is operationally demanding in a specific way: you are not just managing candidates. You are managing information boundaries.
Client A must never know that the candidate you are presenting to them is also being considered at Client B. Client B's hiring manager, if you give them visibility into their pipeline, must see only their pipeline. Your revenue is tracked per client, not pooled. Your reporting is per client engagement, not aggregate.
Most ATS platforms were not designed for this. Here is the precise list of what a multi-client ATS must have — and the test that tells you instantly whether your current platform qualifies.
1. Client-level data isolation at the architecture level
Not at the permission level. Not via folders, tags, or access controls. At the data model level, where each client's pipeline lives in a structurally isolated space that makes accidental disclosure architecturally impossible.
The distinction matters because permission-layer isolation is fragile. One misconfiguration, one click on the wrong sharing setting, one new team member given the wrong role — and confidentiality breaks. Architecture-level isolation does not have these failure modes.
2. Cross-client candidate matching with preserved confidentiality
When a new brief comes in from Client B, you need to know if anyone in Client A's pipeline is a strong match — without Client B ever knowing that candidate is in another client's process.
This requires AI matching that operates at the recruiter layer, not the client layer. The intelligence lives in your view. The isolation holds in the client view.
3. Per-client portal access
Clients log in to their own view. They see their jobs, their shortlisted candidates, their feedback forms. They submit feedback directly in the system.
The alternative — PDF exports, email rounds, manual feedback logging — adds 2-4 hours per shortlist delivery and creates a version control problem. Which candidate notes are current? Did the client's feedback make it into the system?
4. Placement and revenue tracking per client
Every placement tracked with fee, fee structure (contingency, retainer installments), billing status, and margin. Visible per client and in aggregate. Not in a parallel spreadsheet.
5. Per-client proof-of-delivery reporting
A client-facing report showing: how many candidates were sourced, how many screened, how many shortlisted, conversion rates at each stage, time from brief to shortlist. Generated from the system, not compiled manually.
This is increasingly a client expectation at the senior end of the market. Agencies that produce it build more trust and win more repeat business. Agencies that cannot produce it are guessing at their own process quality.
Ask your current ATS: "If I give Client A's hiring manager portal access, can they see any of Client B's candidates?"
Any answer that involves a workaround means you have in-house architecture with agency use layered on top. The right answer is: no, structurally impossible.
An ATS capability that enables recruitment agencies to manage multiple client accounts simultaneously with data isolation between clients, per-client portals, cross-client candidate matching, and placement tracking per client.
With proper multi-client tooling, a single recruiter can typically manage 8-15 active client relationships without operational overload. Without dedicated multi-client architecture, 3-5 is typically the practical limit before quality degrades.
Not natively. Ashby has external partner access features designed for occasional collaboration, not multi-client agency operations. Agencies using Ashby for multi-client work build manual workarounds that add significant operational overhead.
Run your free hiring process audit
Connect your ATS in 3 minutes. Get a full breakdown of where your process loses time and candidates — with three prioritised fixes.
Start free audit →Andreas Gruber
Founder of Pickr and ScalingPPL. Former recruiter who placed engineers and operators into European startups and scale-ups for four years before building the tool he wished had existed.