A client portal your hiring managers will actually open

The first release is deliberately narrow. A recruiter shares a shortlist against a requisition, the client contact receives a link, and from that link they can read the candidate summaries, leave structured feedback on each one, and select an interview slot from the availability the panel has already offered. That is the whole scope, and it covers the part of the client relationship that generates the most friction per week.

Feedback is structured because unstructured feedback cannot be compared. A client who says both candidates were fine has told you nothing; a client who scores against the requirements the requisition actually listed has told you which requirement is doing the work. The scores land on the submittal record and roll into client reporting without anybody retyping them.

Blind masking removes name, photograph, contact details, graduation dates and other identity signals from the candidate summary a client sees, leaving the evidence against the brief. It is a default rather than a toggle because a default that has to be switched on is a default that gets switched on for the searches somebody was already worried about, which is the wrong half.

This is a capability statement rather than a compliance claim. Masking supports a structured, evidence-first first pass; it does not by itself make a hiring process defensible, and the identity data is revealed as soon as an interview is arranged because interviews are not anonymous. What the product does is record which fields were masked at the point the shortlist went out, so the process can be described accurately afterwards.

A hiring manager who reviews four candidates a quarter should not cost the same as a recruiter who lives in the system all day. Client contacts consume no licensed seat, so inviting the whole hiring panel does not change your bill.

It also does not change what they can see. A client contact is scoped to the requisitions and shortlists explicitly shared with them. They cannot search your candidate database, cannot see other clients, cannot see your rates or margins, and cannot see any candidate who has not been submitted to them. The isolation is enforced at the data layer rather than by hiding menu items.

Three capabilities people reasonably expect from a client portal are not in the first release. A requisition intake wizard, which would let a client raise a brief themselves with must-haves, salary band and interview stages captured up front. Embedded e-signature on fee agreements, so terms of business are signed inside the portal rather than in a separate tool. And pay-transparency validation on client briefs, which would check a salary range against the disclosure rules of the states the role will be advertised in before the brief is accepted.

All three are Wave 2. They are named here rather than left vague because a portal roadmap that quietly implies e-signature is a portal roadmap that loses a deal at the demo. Until they ship, terms of business are handled by your existing signature tool and briefs are captured by a recruiter.

Every action a client takes in the portal is an event on the submittal: opened, feedback left, slot selected, candidate declined with a coded reason. Once those events exist, client health becomes measurable. Which contacts respond within two days and which take a fortnight. Which clients reject on salary often enough that the brief is the problem. Which requisitions have had a shortlist sitting unopened for a week.

That data feeds the client relationship scoring and the pipeline exception views rather than living in a separate portal analytics tab. The portal is the input; the reporting you already have is the output.