Taking an assessment rather than buying one? This page is written for employers. Here is the page for candidates.
Inbound customer support · Mid level
How to assess a Technical Support Representative
The quiz tests recall of a product the candidate will be retrained on in week one, which is the most perishable thing you could possibly select for. What it never observes is the diagnostic loop, which is the durable skill and the one that transfers between products: does this person form a hypothesis and ask the one question that discriminates between two causes, or do they issue instructions in sequence until something works? The two look identical on a CV and identical in a competency interview, and they produce completely different average handle times and completely different escalation quality. The second thing nothing observes is the moment the candidate does not know the answer. In this seat that moment arrives daily, and the difference between "I don't have that yet — here's what I'm going to check and when I'll come back" and an authoritative-sounding guess is the difference between a retained customer and a support ticket that becomes a churn event.
The technical support representative sits at the point where a customer's description of a symptom has to be converted into a statement about a cause. The customer says the app is broken. What they mean might be an expired token, a permissions change made by their own administrator, a genuine defect, or a misunderstanding of what the product does. Only one of those four is fixed by following the troubleshooting article, and three of them are made worse by it. This is why the seat is filed under customer operations rather than engineering: the hard part is not the technology, it is extracting an accurate account of events from someone who is not a reliable narrator of their own system and is mildly embarrassed about it.
The separator is diagnostic economy. Give two candidates the same ambiguous symptom and the median one will start issuing instructions — clear your cache, try a different browser, log out and back in — collecting negative results in no particular order until the customer either gets bored or gets lucky. The top quartile forms two or three candidate explanations within the first minute and then asks the question that eliminates the most of them at once: did this start for everyone on your team or just you, and what changed on Tuesday? Same product knowledge, same script access, radically different resolution rate. Diagnostic economy also travels: an advisor who reasons this way is productive on a new product line in a fortnight, which matters enormously in an industry where product refreshes outpace hiring cycles.
The second separator is calibrated candour. Every advisor in this seat will routinely reach the edge of what they know, in front of a customer whose business is currently interrupted. There are three available moves and only one of them is acceptable. Guessing authoritatively is the worst, because it is confident, it is wrong, and the customer will act on it. Retreating into process — "I'll have to escalate that" with no content — is safer and still costs the relationship, because the customer learns nothing and loses their sense of momentum. The correct move is to name the boundary precisely, state the next specific check, and give a time. Hiring processes that reward confidence in interview select directly against this, because the candidate who says "I wouldn't know yet" sounds weaker in a competency interview and performs better on the floor.
The third thing worth screening, and the one operations directors raise first when asked, is escalation quality. A tier-one advisor who escalates with the customer's words copied into a ticket has moved the problem without reducing it; engineering or tier two now repeats the entire diagnostic conversation. An advisor who escalates with a reproduction — what was attempted, what happened, what was ruled out and how — has done most of the work of the fix. This is a written artefact, produced under time pressure, immediately after a live call, and it is one of the cleanest pieces of evidence available anywhere in customer operations because it is either specific or it is not.
Savvanta's design pairs a live diagnostic call against an AI customer whose described symptom does not match the underlying cause — with a system record the candidate can query — and the escalation note written straight afterwards. The rubric scores whether the discriminating question was asked, whether an unknown was named rather than guessed at, and whether the note lets a colleague continue without recontacting the customer. It deliberately does not score product familiarity, because that is what onboarding is for, and it does not score accent, dialect or manner of speech: the criterion for the explanation is whether a non-technical customer could act on it, judged from the content.
What the job actually needs
- hypothesis-driven diagnosis
- asking the discriminating question
- explaining a technical cause without condescension
- admitting uncertainty without losing the customer
- writing a reproduction that engineering can act on
How people fail in this seat
- runs the troubleshooting script top to bottom regardless of what the customer already said
- asks the customer to try things at random instead of testing a hypothesis
- over-attributes to user error
- escalates a ticket with no reproduction steps
- explains the mechanism when the customer only needs to know what to do next
What most employers do instead
CV screen for prior support tenure and named products, a technical quiz or certification check, and a competency interview about a difficult customer.
The assessment
About 25 minutes end to end.
The systems it runs in
Three surfaces, which is what this seat is: a ticketing agent workspace with a queue, a severity or priority field and a knowledge base attached; a read-only product record the candidate can query by account, user and date, holding both an error log and an account change log; and a separate engineering issue tracker that tier two works from, into which the escalation is written. Zendesk and Salesforce both describe the first surface — a unified agent workspace over a ticket or case, with knowledge and internal collaboration on the record; Jira and its equivalents are the second half of the handover in most software support operations. The fixture reproduces the objects: ticket, public reply, linked knowledge article, query log, escalation issue.
- Zendesk
- Salesforce Service Cloud
- Freshdesk
- Jira Service Management
Any ticketing system with a queue and a knowledge base, any queryable product or telemetry record, and any engineering tracker the escalation lands in. This design deliberately does not measure competence in the buyer's ticketing system, which the hitl note states plainly and which the adverse_impact section explains: selecting on named-product recall advantages candidates who happened to work somewhere using the buyer's stack, which is prior access rather than ability. What is scored is the content of the reproduction, wherever it is typed.
What the candidate actually does
| Task | What happens |
|---|---|
| The symptom that is not the cause live_call · 12 min | A live spoken call with an AI customer who reports that the product's export function stopped working on Wednesday and who is impatient, moderately technical, and wrong about what happened. The candidate has two things open — a public troubleshooting article and a read-only system record they can query by account, user and date. The true cause is that on Tuesday an administrator on the customer's own team changed a permission set, which the record shows if the candidate looks at the account's change log rather than the user's error log. The customer does not know this and will not volunteer it, because from where they sit nothing changed. The cheap path is fully built out and genuinely attractive: the troubleshooting article's steps are visible, the customer accepts each instruction cooperatively, clearing the cache and re-authenticating takes six minutes of the twelve, and the customer is grateful throughout for the sense of progress. A candidate can run the script to the end of the call and never be contradicted. The discriminating question — whether it broke for everyone on their team or only this user, and what changed around Tuesday — is available from the first minute and eliminates most of the candidate causes at once. A second fork sits at roughly minute nine: whichever path the candidate is on, the customer asks whether a deprecation notice they received last month is related. Nothing in the record answers this. It is a designed unknown, and the three available moves — a confident guess, a contentless "I'll have to escalate that", and naming the boundary with a next check and a time — are all natural to reach for. |
| The handover written_artifact · 8 min | Straight after the call, in the same monitored window, the candidate writes the escalation into the engineering tracker tier two works from, including the severity they assign it, plus the short message that goes back to the customer as the public reply on the original ticket. Writing it into a tracker rather than into a text box is what makes the severity an observed act: a candidate who reproduces the fault well and files it at the wrong severity has produced a good document that will be read too late, and the two failures are separable only if the field exists. The fork is that the customer's own words are right there in the transcript and pasting them is fast and feels faithful, while a reproduction — what was attempted, in what order, what was observed each time, what has been ruled out and on what evidence — has to be reconstructed and costs most of the eight minutes. Both tickets are accepted by the system and both close the contact. Only one of them means tier two does not have to phone the customer and start again. The customer-facing message is included because the same candidate frequently writes a good ticket and then tells the customer nothing they can act on. |
| One question each judgment_scenario · 5 min | Four short cases, each a customer's opening description of a fault, each with four plausible next questions offered. The candidate picks one and writes what each possible answer to it would rule out. The items are built so that the intuitive question is the one that confirms the leading hypothesis while the discriminating question is the one that splits the candidate space roughly in half, and so that at least one item has no good question among the four and expects the candidate to say so and supply their own. This exists because diagnostic economy is the durable, transferable skill in this seat and a single call samples it once, in one product context, against one temperament. Four cases in five minutes cost little and turn a one-observation competency into a five-observation one. |
The mark scheme
Each criterion is scored 1 to 5 against written anchors, and every score is reported with the excerpt that earned it. A criterion marked floored is reported as a finding rather than averaged into the total. The first is open; open any other to read its anchors in full.
Diagnostic economyweight 0.3States or clearly works from two or more candidate causes inside the first two minutes, asks the question that separates them before issuing any instr…
Calibrated candourweight 0.2Names precisely what is not known, states the specific check that would settle it and who would run it, and gives a time by which the customer will he…
The customer can act on the explanationweight 0.2States what is wrong in one plain sentence, says who has to do what next — here, that the customer's own administrator must restore the permission — a…
The handover stands aloneweight 0.3States the symptom, the steps taken in order with the result of each, what has been eliminated and on what evidence, and the current leading hypothesi…
How it is scored
Weighted mean of the four criteria, each scored 1-5 against the anchors, reported with the excerpt that earned it. Diagnostic economy draws on both the call and the four judgment items, and the two are reported separately as well as combined, because a candidate who reasons well on paper and reverts to the script under a customer's impatience is a specific and coachable profile that an averaged score conceals. The call is scored from its transcript rather than its audio, deliberately, for the reason given under adverse_impact.
Integrity
- monitored window for the written handover, written immediately after the call with no interval in which to draft elsewhere
- the ticket must reference session-specific details generated live — the randomised account reference, the specific error string returned during the call, the order in which steps were run — which a generic or externally drafted ticket does not contain
- a 90-second spoken follow-up asking the candidate why they ruled out the cause they ruled out, answerable only from their own reasoning during the call
- system record queries are logged, so whether the change log was ever opened is a fact rather than an inference from the transcript
- t3 cases and the true cause in t1 rotated per session, so a leaked description of the exercise does not give away the answer
The log describes what happened. It does not produce a cheating verdict — the follow-up conversation is the control, because a statistical accusation is not something we would ask a reviewer to defend.
What you receive
- call transcript with the discriminating-question window and the designed unknown marked
- log of which system records the candidate queried and when
- the escalation as filed in the tracker, with the severity assigned, and the customer-facing reply as posted on the ticket
- four judgment cases with the chosen question and the stated eliminations
- per-criterion score with quoted excerpt
Who decides
Required on two decisions and recommended on a third. A reviewer must confirm any diagnostic economy score of 5 by checking the query log against the transcript, because a candidate who happened to guess the cause early looks identical in the transcript to one who reasoned to it and is a materially worse hire. A reviewer must read every calibrated candour score of 1, since the distinction between a confident wrong answer and a correctly hedged one can turn on a single clause. Recommended: a reviewer decides whether a strong diagnostician with a weak handover is a hire, because that trade depends on whether the buyer's tier two is co-located and can ask, which the assessment does not know. What the ranking does not entitle a buyer to conclude — it does not measure knowledge of the buyer's own product, which is what onboarding is for and is deliberately excluded; it does not measure competence in the buyer's ticketing system; and it does not predict handling of a genuine outage, where the job changes shape entirely.
What this does not measure
This design does not score accent, dialect, pace, first language, fluency or manner of speech. There is no clarity criterion and no professionalism criterion, which are the two labels under which those things conventionally re-enter a rubric. The nearest criterion — whether the customer can act on the explanation — is scored on content only, from the transcript, and its anchors are written as things present or absent in the text rather than as qualities of delivery. The reviewer's default surface is the transcript, not the audio, so the scoring act is one step removed from voice by construction rather than by instruction. The design also deliberately does not measure product familiarity or certifications. That is a fairness property as well as a validity one: selecting on named-product recall advantages candidates who happened to work at a company using the buyer's stack, which is a proxy for prior access rather than for ability, and it is the most perishable thing in the role. Technical vocabulary is not scored either — a candidate who says the permission was changed rather than naming the entitlement model scores the same. Deployers should monitor pass rates by first language and by prior employer type, and should treat a gap concentrated in the calibrated candour criterion with particular suspicion, since directness norms around admitting uncertainty vary culturally and the anchor must catch the substance of naming a boundary, not the confidence with which it is named.
The premise of this design is that technical support is a diagnosis job wearing a conversation job's clothes, and that the conventional screen — a product quiz and a competency interview — measures the two most perishable things available while observing neither the diagnostic loop nor the moment the candidate runs out of knowledge. Both of those are performable, both are observable in twelve minutes, and neither has ever been watched before a first week on the floor.
The call is built so that the script works socially and fails technically. That combination is the whole point. Clearing the cache and re-authenticating will never fix a permission change made by the customer's own administrator, but the customer cooperates with every instruction, sounds encouraged by the momentum, and never contradicts the candidate — so a representative can burn half the call on the article and end it feeling it went well. The cheap path here is not lazy; it is the path that produces the better in-call experience, and it is the one most candidates will take. What separates the top quartile, per the role file, is diagnostic economy: forming two or three explanations early and asking the one question that eliminates most of them, which in this scenario is a scope-and- change question that is available from the first minute and costs nothing.
The designed unknown at minute nine is the second half of the argument. Every person in this seat will reach the edge of what they know, in front of a customer whose work is currently interrupted, most days. There are three moves and only one is acceptable, and the scenario is constructed so all three are natural: the deprecation notice is real, plausibly related, and unanswerable from the record. Hiring processes that reward confidence in interview select directly against the correct move, because "I do not know that yet, here is what I will check and when I will come back" sounds weaker in a room and performs better on a queue. Putting it in a scored scenario inverts that pressure.
Twenty-five minutes buys three minutes more than the voice design, and the justification is the handover. The escalation note is the cleanest single piece of evidence in this family — a reproduction either contains what was ruled out and how, or it does not — and eight minutes is the least that a reconstruction can honestly be written in, where the cheap paste takes ninety seconds. Cutting it to five would systematically favour the paste and destroy the criterion.
What the budget gives up is depth of technical range. One fault, one product shape, one customer temperament: this predicts diagnosis of an ambiguous configuration fault reported by an impatient moderately-technical user, and infers everything else. It does not sample a genuinely defective product, where the job becomes evidence-gathering for engineering, nor a customer who is non-technical and frightened, nor the multi-customer pattern recognition that turns three similar tickets into an incident. A longer design would sample two faults of different kinds and would be a better instrument. It would also be run by fewer buyers, and an instrument that is skipped predicts nothing at all.
Sources
Every figure on this page is traceable. Where a claim could not be sourced it is stated qualitatively instead.
- US Bureau of Labor Statistics, Occupational Outlook Handbook, Customer Service Representatives, 2025, https://www.bls.gov/ooh/office-and-administrative-support/customer-service-representatives.htm
- US Bureau of Labor Statistics, Occupational Outlook Handbook, Computer Support Specialists, 2025, https://www.bls.gov/ooh/computer-and-information-technology/computer-support-specialists.htm
See what the employer actually receives. A full report for one role, with every score shown beside the excerpt that earned it, conduct findings reported rather than averaged, and a reviewer sign-off required before any decision. No form.
Read a sample reportOr talk to us about this role