Client portal for recruitment agencies to share shortlists
A client portal for recruitment is a page a hiring manager opens to see the candidates you have shortlisted for a role, without downloading a batch of CV attachments or creating an account on your software. At minimum it needs to show the candidates, their fit against the role, and let the client leave feedback or move someone forward, all from one link you control and can revoke.
Most agencies start without one. A shortlist goes out as five CV attachments and a covering email, the client replies "like candidates 2 and 4," and somebody on your side manually matches that reply back to the right people. It works until you are running more than a couple of roles at once, at which point the email thread becomes the bottleneck and nobody can tell which version of a CV the client actually looked at.
What a client portal needs, beyond "a page with CVs on it"
No account for the client. The person deciding whether to interview a candidate is rarely willing to set a password for your ATS. A link that works on its own, usually a long random token in the URL rather than a short guessable one, is what makes a portal something a client actually opens instead of ignoring.
Per-job screening answers, visible or not by your choice. If you ask candidates screening questions when they apply ("are you authorised to work in the EU," "what's your notice period"), the client usually wants those answers next to the CV rather than having to ask again. But not every question belongs in front of the client: an internal note about salary flexibility or a reference check in progress should stay on your side. A portal needs a per-job setting for which questions the client sees, not a global on/off switch, because what's appropriate to share varies by role and by client relationship.
Anonymisation that survives free text. Covered in full in our CV anonymisation guide, but it matters enough here to repeat the one-line version: a portal that only swaps the name field and leaves the candidate's own company names and team details sitting in the experience section has not actually anonymised anything.
Feedback that comes back to you, structured. "Like 2 and 4" in a reply email is feedback that only exists in that one inbox. A portal that lets the client mark a candidate as interested, reject with a reason, or leave a note against a specific person turns that signal into something your team can see and act on without forwarding an email.
An expiry, or a way to revoke access. A shortlist link that works forever is a data-protection liability once the role is filled and the candidates have moved on to other conversations. Being able to close a link, or set it to expire, is not a nice-to-have.
Does the client need to install anything?
No, and if a portal requires an app or a signup, most clients will not use it. The working pattern is a web page that opens from a link with nothing to install, viewable from a phone if the client wants to skim it between meetings.
What usually goes wrong with a DIY version
A shared Google Drive folder of CVs is the most common substitute, and it fails in a specific way: there's no way to attach screening answers or match reasoning to a specific CV without renaming files or adding a separate spreadsheet, and anonymisation is entirely manual, so it is the first thing skipped when someone's in a hurry. It also has no feedback mechanism, so you are back to parsing replies by hand.
A shared inbox or CC thread fails differently: it works for one role with three candidates and stops working the moment you are running five roles with the same client at once, because every reply has to be manually matched to the right shortlist.
How is a client review link different from just emailing a shared folder link?
The structural difference is that a review link is generated per shortlist and tied to the specific candidates on it, rather than being a static folder a client can poke around in indefinitely. That makes it possible to anonymise consistently (the data is assembled fresh for that link, not pulled from a folder of pre-made files), track who looked at what, and revoke access to one shortlist without affecting another.
How this works in Hireo
A recruiter builds a shortlist for a job and generates a review link, which resolves to a page the client opens with no account. The page shows each candidate's CV, the AI-generated reasoning for why they match the role's requirements, and whichever screening questions the recruiter chose to make visible for that specific job. Name display and contact-detail visibility are set per link, independent of each other, so a recruiter can show a candidate's full career history without showing contact details until later in the process.
The client can rate each candidate, set an interest level (interested, maybe, not interested), flag that they want an interview, and leave a comment. That feedback is stored and shows up in the job's client-feedback view for the recruiter to read; nothing about it moves the candidate's pipeline stage or alerts anyone on its own. The link itself stays scoped to the organisation and job it was created for, so adding or removing candidates from an existing review does not silently expose a different client's shortlist through the same URL.
What can a client actually do with a candidate on the review page?
Rate them from one to five and set an interest level (interested, maybe, not interested): both are required on every submission. A comment and a flag that they want an interview are optional on top of that.
What happens to a review link once the role is filled?
A recruiter can remove candidates from an active review or stop sharing it; the link itself does not need to be deleted to lose its usefulness, since a client has no reason to keep opening it once a decision is made. Treat it the same way you would treat access to any other system holding candidate data: close it down once the purpose it was created for is done.