Deliver for six clients without mixing their data

An RPO contract is written in measurements: time to submit, submittals per requisition, submittal-to-interview ratio, time to fill, offer acceptance, and a response time on new requisitions. Those are not internal targets, they are obligations with commercial consequences, and at the end of the month somebody on the client side will check them.

Surhires tracks service levels against the terms configured per account rather than against a generic best practice. If one contract requires three qualified submittals within five working days and another requires first submittal within forty-eight hours, both are configured as they were signed. A requisition approaching a breach appears before it breaches, with enough time for the delivery lead to move resource.

Because the measurement runs on the working records, the monthly report is a report rather than a reconstruction. When a service level was missed, the record shows where the time went, which frequently turns a penalty conversation into a shared one about hiring manager response times.

An RPO recruiter is, to the candidate, an employee of the client. The email comes from the client's domain, the careers site is the client's, the interview invitation carries the client's name, and the candidate should generally never see the provider's brand at all. A system that stamps your logo on candidate-facing output is unusable in this model.

Surhires holds branding per account: sender identity and domain, email and message templates, careers-site capture forms, offer document templates and the portal a candidate logs into. A recruiter working two accounts sends from two identities without changing tools, and the identity follows the requisition rather than the person.

The internal view remains yours. Your delivery team sees the account structure, your own service level tracking and your own performance data behind whichever brand the outbound is wearing.

A single high-volume requisition may need forty submittals to close, and a hiring wave may run thirty of those at once. At that scale, the difference between a workable process and an unworkable one is measured in seconds per candidate. Opening each record to disposition it is not a process; it is a staffing cost.

Surhires supports bulk work throughout: resumes imported in bulk and parsed on arrival, duplicates detected during import rather than after it, candidates shortlisted against the requisition criteria with the scoring explained, and disposition, tagging, pooling and messaging performed on hundreds of records from the list view with a select-all that respects the current filter.

Scale also creates its own hazard. Bulk messaging without suppression produces two recruiters approaching the same person, and bulk rejection without coded dispositions produces a funnel nobody can explain. Both are enforced at the record rather than left to a campaign setting.

RPO teams flex. A wave starts, three recruiters are added to an account for six weeks, and then they move. Onboarding somebody onto an account has to take an hour rather than a week, and offboarding has to actually remove access rather than trusting them to stop looking.

Each account carries its own configuration: stage sets, templates, service levels, branding, hiring manager list and reporting. Adding a recruiter grants that configuration; removing them revokes it, including saved searches and exported list access. Their historical activity remains attributed on the records they touched, because an audit trail that disappears with a leaver is not an audit trail.

Capacity is visible across accounts. A delivery lead can see requisition load per recruiter and where service levels are at risk before moving people, which is a different decision from moving them afterwards.

Many RPO engagements run inside the client's own system: the client uses Workday or Greenhouse, and the requisition of record lives there. The provider still needs its own CRM for sourcing, nurture, pipeline management and service level tracking, because the client's system is not built for the outbound work and does not belong to the provider anyway.

Surhires is designed to sit alongside that rather than to replace it. Requisitions can be received from the client system, candidates worked in Surhires, and submittals pushed back so the client's record of the process stays intact. Each integration carries an explicit state of Live, In development or Roadmap, and where a connection is not yet live the honest answer on an evaluation call is that the flow is manual today.

Where an engagement has no client system, Surhires runs the whole process for that account on its own.

An RPO provider does not report to itself. Every account has a reporting pack with an agreed shape and a monthly or weekly deadline, and building it by hand across several accounts consumes a person.

Surhires derives account reporting from the working records inside the account boundary: requisition status, submittal volume, funnel conversion at each stage, service level attainment against the contracted terms, source of hire and diversity of the funnel where you collect that separately from the hiring record. The pack can be shared through a client portal so a stakeholder can look at the current position between reporting cycles rather than emailing for an update.

Where a figure is not reliable yet, the report says so. An attainment number computed from four requisitions is not evidence, and presenting it as though it were is how a provider loses an argument in month six.