Asking only “was it fixed?” misses most of what a technical support evaluation should measure. One agent stumbles onto a fix after random restarts; another follows every approved step and still has to escalate because the fault sits with another team. A useful technical support QA scorecard looks at how the representative understood, investigated, handled, explained and documented the issue, so luck doesn't earn full credit and an unresolvable case isn't automatically a low score.
The criteria, definitions and weights below come straight from the Technical Support starter template in the BPO Scorecard calculator. They are configurable starter settings, not an industry standard; align them with the approved client rubric before real evaluations.
When to use the Technical Support template
The calculator recommends this template for “technical-support cases where diagnostic discipline, technically correct guidance, clear explanations, verified resolution, and complete case documentation matter.” Examples include application or software faults, connectivity problems, device or system troubleshooting, login and access issues, configuration problems, error investigation, and cases that end in escalation. These are illustrative; not every account handles them all.
For requests with no diagnosis involved, such as a billing question, the Customer Service template guide fits better. Either way, adapt the starter criteria to the approved client rubric, your technical environment and your operational policies.
The six starter criteria
| Criterion | Starter weight | Starter definition in the calculator |
|---|---|---|
| Verification | 10% | Confirms the user's identity, account or device context, permissions, and relevant environment before accessing or changing information. |
| Troubleshooting Process | 20% | Uses a logical diagnostic sequence, asks relevant questions, tests appropriate causes, and avoids unsupported or unnecessarily risky steps. |
| Technical Accuracy | 25% | Provides technically correct explanations and instructions aligned with approved documentation, product behavior, and known limitations. |
| Communication | 15% | Explains technical concepts in language suited to the user's knowledge level, checks comprehension, and sets clear expectations. |
| Resolution | 20% | Fixes or appropriately narrows the issue, verifies the result where possible, or explains escalation and the next agreed action. |
| Documentation | 10% | Records symptoms, checks performed, findings, changes, outcome, and next steps clearly enough for another technician to continue the case. |
| Total | 100% | Each criterion is rated out of 5. |
Troubleshooting Process and Resolution together carry 40%: the template weighs method as heavily as outcome.
What separates a 5 from a 3
A 5 means the approved behavior was fully demonstrated, with evidence. A 3 means a meaningful, non-critical gap the rubric allows partial credit for. Not every mistake is a 3: a minor slip may be a 4, and a critical failure goes under the critical-error rule, not the rating. Anchors must be observable: “good troubleshooting” can't be checked; “asked for the exact error text before suggesting a fix” can.
Verification — 10%
5/5: Verifies the user by the approved method, then confirms the affected device or account, the application or operating system version, the user's permissions and their network before accessing or changing anything.
3/5: Identity is verified but the technical context is assumed, so part of the call is spent on the wrong device or version. Accessing or changing information before verification belongs under the critical-error rule if the policy says so.
Evidence to capture: When verification happened relative to the first access or change, and which context questions were asked. Never copy passwords, codes or security answers into the evaluation.
Why it matters: Troubleshooting the wrong environment wastes the call, and in technical support, verification protects access to devices and systems, not just account data.
Troubleshooting Process — 20%
5/5: Establishes the symptom, asks focused questions (when it started, what changed, whether other services work), captures the exact error, and tests likely causes in the approved order. Risky actions, such as a reset that clears local data, are used only when the process calls for them.
3/5: Reaches the right area with gaps: repeats a step that has already failed before asking for the error details, or skips a required check. The issue may still get fixed.
Evidence to capture: The questions asked, the order of steps, and any step that was skipped, repeated or unsupported.
Why it matters: This criterion separates diagnosis from guesswork. Three restarts without asking why the application fails treat the symptom, not the root cause. If the problem then disappears, score the method here and the outcome under Resolution, so a lucky fix doesn't earn credit the process didn't.
Technical Accuracy — 25%
5/5: Instructions and explanations match current approved documentation, product behavior and known limitations for the user's version and platform. Knowledge base articles opened during the contact are applied correctly.
3/5: The core instruction is right but a material detail isn't: a menu path from an older version, a step missing on the user's platform, or a claim the documentation doesn't support.
Evidence to capture: The instruction given, the approved source it should match, and whether any error was corrected.
Why it matters: Checking the approved knowledge base is part of the job, not a weakness to deduct for. Deduct for guidance that is wrong, outdated or assumed, such as advice remembered from a previous release or a workaround the approved resources don't support.
Communication — 15%
5/5: Explains each step at the user's level, says what to click or look for, checks progress (“What do you see on the screen now?”), and says how long steps take and what happens next.
3/5: Technically correct but hard to follow: unexplained jargon, several steps at once with no check, or a user left unsure what the agent is waiting for.
Evidence to capture: Where the user was confused, asked for a repeat or did a step wrong, and whether the agent adjusted.
Why it matters: Technical knowledge and the ability to explain it are separate skills. An accurate instruction the user can't carry out doesn't fix anything.
Resolution — 20%
5/5: Fixes the issue and confirms with the user that the original task now works; or narrows it as far as the agent's authority allows, escalates through the approved route, and tells the user what happens next and when.
3/5: A likely fix is applied but never tested with the user, the case is escalated without the required initial checks, or the user isn't told what happens next.
Evidence to capture: The final test (or why one wasn't possible), the escalation route and reason, and what the user was told.
Why it matters: Resolution measures what the agent controlled, not whether one contact could solve the problem. A properly handed-over escalation after the required work isn't a failure; a transfer before those checks is. Agree in calibration whether skipped checks count here or under Troubleshooting Process, and score them once.
Documentation — 10%
5/5: Another technician could continue without calling the user back: the note records what was reported, checked, found and changed, the result and the next action, with no passwords, codes or unnecessary personal data.
3/5: The note leaves out something the next person needs, usually the change made, the result of the last step or what remains open. “Followed KB, resolved” is a typical 3.
Evidence to capture: The ticket note, compared with what actually happened.
Why it matters: The note is often the handoff: if a case is escalated or the issue returns, a thin note means repeated questions, repeated steps and a slower fix.
Critical errors and N/A in technical support
The template has no built-in critical-error list; the calculator lets you flag any criterion as critical and choose automatic FAIL (0%), a 79.9% cap that still counts as a FAIL, or no automatic effect. A technical support policy might treat as critical a destructive or unauthorized change made without the required consent, bypassing a security control, asking for or recording a password or authentication code, or disclosing information before verification. These are examples; use the client's documented list.
Mark N/A only when the approved rubric says a criterion doesn't apply to that contact type, such as Verification on a general how-to question that never touches an account or device. An escalated case still gets a Resolution score. The calculator excludes N/A criteria and rescales the remaining weights.
Worked example: an application that won't connect
Illustrative training case, fictional. A remote employee contacts the help desk because a company desktop application shows “Server not reachable (error NET-104)” at launch. They have already restarted the laptop twice. The representative verifies the user and confirms the laptop, application version and home connection. Rather than suggesting a third restart, they ask for the exact error text, confirm ordinary websites load, and open the approved knowledge base article for that error. Following it in order, they find the VPN client installed but not connected, explain that the application reaches company systems only through the VPN, and guide the user to connect it. The error clears, so no escalation is needed. At the sign-in screen, the representative says it should be working now and ends the call. The ticket note reads: “User unable to connect, error NET-104. Internet OK. Followed KB. Resolved.”
| Criterion | Weight | Rating | Contribution | Evidence / coaching focus |
|---|---|---|---|---|
| Verification | 10% | 5/5 | 10.0 | Verified by the approved method; laptop, application version and connection confirmed before any change. |
| Troubleshooting Process | 20% | 5/5 | 20.0 | Asked for the exact error instead of a third restart, ruled out general connectivity, then followed the article's sequence to the VPN. |
| Technical Accuracy | 25% | 5/5 | 25.0 | Steps and the VPN explanation matched the approved article. |
| Communication | 15% | 5/5 | 15.0 | Explained why the VPN matters in plain language and guided the user through connecting it. |
| Resolution | 20% | 3/5 | 12.0 | Call ended at the sign-in screen: a successful sign-in wasn't confirmed and no next step was given if the error returns. |
| Documentation | 10% | 3/5 | 6.0 | Note omits the finding (VPN not connected), the change made, the test result and the next step. |
| Total | 100% | — | 88.0% | Base weighted score; no critical error in this example. |
Each contribution is (rating ÷ 5) × weight, so Resolution adds (3 ÷ 5) × 20 = 12 points, and the six contributions total 88%, a pass at the calculator's default 80% threshold (How to Calculate a BPO QA Score explains the formula). The calculator's Pareto analysis attributes 8 of the 12 points lost to Resolution and 4 to Documentation, so both become coaching priorities despite the pass.
The missing next step counts once, under Resolution, not again under Communication; the incomplete note is a separate behavior, so Documentation is scored on its own.
Had the error persisted through every step, the right move would be to collect what the article asks for, escalate through the approved route with a complete note, and tell the user what happens next. That could still earn 5/5 for Resolution.
Turn the score into a coaching action
Both gaps happened at the close, so coach how the agent closes a technical case, not their troubleshooting, which was strong.
Observed behavior: Ended the call at the sign-in screen without confirming the user could sign in, then closed the ticket with a note that omits the cause and the fix.
Evidence: The closing statement, and the note: “Internet OK. Followed KB. Resolved.”
Why it matters: An untested fix is an assumption. If the error returns, the next technician won't know the VPN was the cause and may start from scratch.
Next time: Ask the user to repeat the task that failed before closing, then record what was reported, checked, found and changed, the result and the next step.
How it will be checked: For a week, the team lead reviews the agent's resolved technical tickets for a confirmed test and a complete note; QA re-scores both criteria on the next evaluation.
That meets the SMART test (specific, measurable, time-bound) and follows GROW's order; Turning QA Scores Into Better Coaching covers the wider method. After a properly tested close, the note would read:
Using the calculator responsibly
In BPO Scorecard, choose the Technical Support template, review or adapt each criterion's definition to your approved rubric, enter the ratings and adjust the weights if your rubric differs. Mark N/A or critical errors only as your policy allows, set the matching critical-error rule and passing threshold, and add QA and coaching notes to each criterion. The calculator then ranks weighted deductions in a Pareto analysis, suggests coaching priorities, drafts GROW and SMART feedback, and exports the evaluation as a PDF or Word file, or saved evaluations as a CSV.
It's a practical scoring utility, not a replacement for a client-approved QA system or technical support policy. Edit the coaching draft so it names the actual behavior, and calibrate these anchors with your evaluators first.
Open the BPO Scorecard calculator to try a technical support evaluation, or use How to Build a BPO QA Scorecard to write anchors for your own rubric.