Support hiring profile
Most support hiring processes overweight likability and prior brand names and underweight job-relevant task performance. The result is a pipeline that feels rigorous — multiple interviews, culture questions, scenario chat — and predicts ramp speed and quality poorly.
What people screen for and what predicts performance are often different things. Charisma in an interview correlates weakly with sustained QA scores, adherence under occupancy, or learning a ticketing system. Structured work samples correlate better, when they resemble the actual job and are scored consistently.
This skill does not prescribe universal traits ("empathy", "resilience") as facts. It helps you derive and validate predictors for your work, then build a profile around what you can defend.
Step 1: define success in role — for your operation
Pick 2–3 outcomes you hire toward, measured after enough tenure to be fair (typically post-ramp, not week two):
- Sustained QA score (or equivalent quality measure)
- Time to Independent on primary work (see skills-matrix skill)
- Attrition in first year (if you track it ethically and aggregate)
Split by channel and language where the job differs. A single "support agent" profile across voice, async chat, and technical tiers hides real predictor differences.
Step 2: audit what you currently screen for
List every current step: CV screen, phone screen, values interview, manager interview, etc. For each, ask:
| Step | Claimed signal | Evidence it predicts success here? |
|---|---|---|
| e.g. "years in BPO" | experience | Only if you validated against your QA/ramp data |
| e.g. "culture fit" | collaboration | Undefined unless operationalised |
Mark steps as validated, ** assumed**, or ** decorative**. Decorative steps consume panel time and can introduce bias without improving selection.
Step 3: build structured work samples
Replace or anchor the process on tasks that look like the job, scored with a rubric before anyone meets the candidate.
Examples by work type (adapt to your stack):
- Async — respond to a written customer scenario with policy and KB provided; score clarity, accuracy, tone, and next-step ownership.
- Voice — role-play or recorded response to a scenario; score structure, verification, and resolution path (not accent or "energy").
- Technical — troubleshoot from a ticket history snippet; score diagnosis, comms, and escalation judgement.
Rules:
- Same scenarios for all candidates in a cohort, with rubric weights fixed in advance.
- Score blind where possible — graders see the response, not the CV.
- Rubrics on behaviours, not gut feel. "Acknowledged constraint before offering options" beats " seemed empathetic".
- Time-box to realistic handle-time pressure, not unlimited take-home polish.
Work samples are not free of bias (written vs voice favours different candidates) but they are inspectable and improvable in a way vibes are not.
Step 4: validate predictors — do not claim universals
After hires land, backtest your scores against outcomes:
- Correlate work-sample rubric dimensions with post-ramp QA and time-to-proficiency.
- Drop dimensions that do not predict; weight those that do.
- Check whether CV screens add signal on top of work-sample scores. Often they do not.
Report honestly:
- "In our last two cohorts (n=…), scenario score correlated with ramp length; phone screen did not." — valid if true.
- "Empathy predicts support success" — not valid as a universal claim.
If n is too small, say the validation is preliminary and the profile is a hypothesis to retest — do not freeze the rubric as science.
Step 5: adverse impact and fairness
Structured hiring reduces some bias and can introduce others. Before scaling:
- Review pass rates by stage across protected groups where you legally and ethically can — large gaps at the work-sample stage suggest the task or rubric, not "candidate quality".
- Avoid proxies for protected characteristics — "cultural fit", neighbourhood, commute distance, "native speaker" where job requires language proficiency not native birth.
- Language requirements — test proficiency with a defined standard (e.g. CEFR level for the markets served), not accent or informal judgement.
- Accommodations — extra time, alternative format, or assistive tech for work samples where disability law or policy applies.
If you cannot run disparity analysis, state that as a limitation and avoid high-stakes automation on unvalidated scores.
Step 6: assemble the hiring profile document
One page the panel uses:
- Role outcomes — what success looks like at 90 days and six months
- Must-have validated predictors — from work sample + any validated screens
- Trainable vs hire-for — e.g. product knowledge trainable; reading comprehension under time pressure less so
- Red flags that are evidence-based — failed verification on work sample, not "bad vibe"
- Panel rules — no override of work-sample score without documented reason; no unstructured compensation for "star" candidates
Traps
- Interviewing for the interview — social ease mistaken for customer skill.
- Unstructured manager veto — undoes blind scoring.
- Scenarios that do not match the job — trivia tests, brainteasers, or essays.
- Copying another company's profile — predictors do not transfer without validation.
- Claiming personality types or universal traits without local evidence.
- Using ramp failure to blame hires when onboarding or mix assignment failed.
Present results to the user
- Role success definition — outcomes and tenure window used.
- Current process audit — validated vs assumed vs decorative steps.
- Work sample design — scenarios, rubric, timing, blind-scoring method.
- Hiring profile — must-haves, trainables, evidence-based red flags.
- Validation plan or results — correlations with ramp/QA if data exists; explicit n and limitations.
- Fairness review — disparity checks done or deferred, with stated risk.
- What not to claim — universal traits, unvalidated predictors, or precision you do not have.