Screen non-technical roles without losing the result

Technical assessment is a narrow, deep question: can this person write code that works. Screening a customer support hire, an account manager, a bookkeeper or a coordinator is a broader and shallower question, and it usually combines several small signals rather than one large one: a language level, a numeracy or attention-to-detail check, a situational judgement scenario, and sometimes a role-specific software skill.

That breadth is why these assessments are frequently used earlier in the funnel and at higher volume. They are a filter across a large applicant pool rather than a stage that three finalists go through, which changes what a good integration has to handle: batch invitation, visible completion rates, and a clear view of who has not started.

The provider designs the tests, validates them, and stands behind what they measure. Surhires requests one, tracks it, receives the outcome and stores it against the right candidate and submittal. It does not re-score, does not normalise across tests, and does not convert a result into a recommendation.

This is worth stating precisely because assessment results carry more weight in a decision than most other data on a record. If a candidate is rejected on an assessment outcome, the responsibility for that decision is the employer's or the agency's, and the record should show a human made it against a threshold that was set in advance.

The native assessments module inside Surhires covers a different case: structured evaluations your own team writes and scores, tied to a scorecard and an interview kit. Use it where a human judgement against a rubric is the right instrument, and use a specialist platform where a validated test is.

Out of Surhires: candidate identity and email to issue the invitation, and the assessment selected. Back into Surhires: the result, the report file, the status and the timestamps, attached to the candidate and submittal.

Not stored in Surhires: individual question responses, the test content itself, provider account configuration, or any anti-cheating telemetry the platform collects. Question-level data is part of the instrument and belongs to the provider. A CRM holding it would be protecting data it has no use for.

Any filter applied early and at scale deserves more scrutiny than one applied to three finalists, because it affects far more people and its effect is easy to miss. If an assessment is used to screen out candidates automatically, that is exactly the kind of tool that regulators have started to name.

Surhires records which candidates were scored, when, against which requisition, and what happened to them afterwards, using disposition codes from a fixed list rather than free text. That is the data an independent bias audit needs where an automated employment decision tool is in scope. Commissioning the audit, issuing candidate notice and deciding whether to use an automatic cut-off at all remain your responsibility, not ours.

Invite from the provider console, and record on each Surhires candidate record that an assessment was ordered, which one, and when. For cohorts, use a talent pool or a stage so the group is a list you can work rather than a set of open browser tabs. Attach the report when it arrives and record the outcome and threshold on the submittal.

One habit worth building now: write the threshold down before the results come back. A pass mark decided after seeing the scores is difficult to defend and easy to argue with, and it takes thirty seconds to record it in advance on the requisition.

The second habit is to record the outcome as a disposition rather than as a note. A note is prose that nobody queries. A coded disposition is a field you can report on, which is how you find out that a particular assessment is rejecting most of the candidates a particular client eventually wants to interview. That is a conversation about the brief, and you can only have it if the data exists.