---
title: Quality Control
description: Build reusable scorecards — weighted criteria, "critical" criteria that fail an evaluation on their own, a pass threshold — then score a person, a call, an order or anything else against them. A failed staff evaluation can automatically assign a remedial training program. Off by default.
product: TSync Intelligence 11.3.6
language: en
canonical: https://docs.tsync.pro/modules/tsync-qc/
source: https://docs.tsync.pro/llms.txt
---

# ✅ Quality Control

**Quality Control** lets you check work against a written standard instead of a gut feeling. You build a
**scorecard** once — a list of criteria, each with its own maximum score and weight — and from then on anyone
with the right permission can **evaluate** a person, a phone call, an order or any other subject against it.
Every evaluation gets a percentage, a **passed / not passed** verdict, and a record you can go back to.

You'll find it in the sidebar as **Quality Control**; it opens at **/admin/tsync_qc**.

## Turning it on

Quality Control is **off by default** — the sidebar item doesn't even appear until an administrator switches
it on. There are two doors:

- **Quality Control → Settings** (`/admin/tsync_qc/settings`) — set **Module status** to **On**.
- The **Quality Control** card in the **Configuration Center** — always available, even while the module is off.

Only an administrator can change this. Scorecards and evaluations are safe to prepare at any time; nothing is
shown to anyone else until the module is **On**.

## Who can do what (permissions)

Three separate rights sit on the **Quality Control** permission row (set them per role under **Setup →
Roles**), so you can let team leads evaluate without letting them redesign the standard:

| Right | What it allows |
|-------|----------------|
| **View quality control** | Open the console, see scorecards, evaluations and results. |
| **Manage scorecards** | Create, edit and delete scorecards and their criteria; delete evaluations. |
| **Perform evaluations** | Fill in and submit an evaluation. |

A right granted **on a role** works exactly like one granted to a person directly. Administrators have all three.

## Step 1 — build a scorecard

Open **Scorecards → New scorecard** and fill in the header:

| Field | What it does |
|-------|--------------|
| **Scorecard name** (required) | What you're measuring — "Inbound call quality", "Installation checklist". |
| **Subject type** | What is being evaluated: **Staff member**, **Call**, **Interaction**, **Order** or **Custom**. |
| **Pass threshold (%)** | The score an evaluation must reach to count as passed. Starts at **80 %**. |
| **Description** | A short note on when to use this scorecard. |
| **Active** | Uncheck to retire a scorecard without deleting its history. |

Save, and you land straight in the **scorecard builder**, where you add the criteria.

### Criteria — the actual questions

Each criterion has:

- a **label** — the thing being judged ("Greeting & tone", "Paperwork complete");
- a **maximum score** — the top mark for that line (5 by default);
- a **weight** — how much this line counts relative to the others (1 by default; put 2 on a criterion that
  matters twice as much);
- a **critical** flag — see below.

**How the percentage is worked out:** every criterion contributes `score × weight`, and the maximum possible
is `maximum × weight`. The percentage is the first divided by the second. So weights change the *importance*
of a line, not its maximum mark.

> **Critical criteria.** Tick **Critical** on a line that can't be got wrong — a safety step, a legal
> disclosure, a mandatory check. If a critical criterion is scored **0**, the whole evaluation **fails**, no
> matter how good the percentage is. That is the only way a passing percentage can still come out as *not
> passed*, and the result page says so plainly.

## Step 2 — evaluate

From the console (or the **Scorecards** list) click **Start an evaluation** on the scorecard you want.

1. Pick the **subject**. For a *Staff member* scorecard you choose from a list of active staff; for every
   other subject type you type a free-text label ("Call 14:20 — ACME", "Order #4417").
2. Score each criterion with its slider. Critical lines are marked so you can see them while scoring.
3. Add a **comment** on any line that needs explaining, plus **overall notes** at the end.
4. Finish with **Submit evaluation**, or **Save draft** if you want to come back to it.

A **draft** is not counted anywhere — only **submitted** evaluations appear in the totals, the report and the
dashboard tile. Submitting stamps the date and computes the verdict.

## Reading the result

The result page shows the score (points and percentage), the **pass threshold** it was measured against, the
**passed / not passed** verdict, and every criterion with its score, its weight and your comment. If a
critical criterion caused the failure, that's stated explicitly.

The **Quality Control** console home gives you the running picture: how many evaluations were submitted, how
many passed, the average score, your active scorecards and the latest evaluations.

### The evaluations list

**Evaluations** lists them all, built for reading a lot of them:

- **Sort by any column** — click the header: id, scorecard, subject, evaluator, source, score, status,
  outcome or date.
- **Filter** by scorecard, status, evaluator and date range, plus a **search box** that also matches an id —
  typing `#13` finds evaluation 13, because that is what people actually type.
- **Sorting keeps your filters, and filtering keeps your sort order.** Narrowing to one scorecard and then
  clicking a header does not quietly hand you back the whole table.
- **Choose which columns you see** in **Quality Control → Settings**. **Id** and **subject** always stay —
  a list whose rows can't be identified isn't a list. Tick nothing and you get the standard columns, never
  an empty table.

A filtered list that matches nothing says exactly that, separately from "no evaluations yet" — the first is
something you can fix by widening the filter.

Someone with **Manage scorecards** can delete an evaluation. Deleting a **scorecard** removes its criteria,
its evaluations and their scores together — so you never end up with results whose questions no longer exist.
Both actions ask for confirmation first.

## Turning a failure into training

This is the part that closes the loop. On a scorecard you can name a **remedial training program** (from
[Academy](tsync-academy.md)) and tick **Auto-assign this program to a staff member who fails the evaluation**.

From then on, when a **staff** evaluation is **submitted** and **fails**, that person is automatically
enrolled in the program — it shows up in their **My learning** list, marked as coming from Quality Control.
Nothing is deleted, nobody is notified punitively; the person simply gets the training that addresses what
went wrong.

Conditions, so there are no surprises:

- it only applies to a **staff** subject (you can't enrol a phone call);
- **Academy** must be installed with **structured training** enabled, and the program must exist;
- the scorecard must have a program selected **and** the auto-assign box ticked;
- it happens once per failing evaluation, and it's recorded in the audit log.

An administrator can switch the whole mechanism off system-wide without touching each scorecard:
**Settings → Automatically assign training after a failed evaluation**. Scorecards keep whatever remedial
programme they are configured with — only the automatic enrolment stops, and you can still assign by hand.

## Where the results show up

- **Reports** — the **QC pass-rate** report (in the [Reports console](../reports.md)) gives you evaluations,
  passed count, pass-rate and average score per scorecard, with a chart and CSV/Excel export. Rates in the
  totals row are **weighted**, so the grand total is a true overall pass-rate.
- **Dashboard** — a **QC summary** tile is available on the [dashboard](../dashboard.md); switch it on from
  **Customize widgets**.
- **Automations** — the moment an evaluation is submitted is a system event, so
  [TSync Automations](tsync-automations.md) can react to it (notify a manager, create a task…).

## Are your evaluators scoring the same way?

Two people can review the same call and score it 58% and 91%. When that happens, the scores say more about who
did the review than about the person reviewed — and no amount of coaching built on them will help.

**Calibration** measures it. Open **Calibration**, start a session on one item (a call, a ticket, an order),
and have several evaluators score it independently. The session then reports:

- the **raw spread** — "5 evaluators, 58% to 91%" — which is the number most managers read first;
- an **agreement score (ICC)** — a statistical measure of how closely the evaluators track each other, banded
  as poor / moderate / good / excellent using the published thresholds;
- **agreement on the yes/no criteria** separately, because those often hide the real disagreement.

Calibration evaluations **never count towards anybody's official numbers**. Neither do self-evaluations. They
are an exercise about the scorecard, not about the person.

If agreement is poor, the fix is almost always the scorecard, not the people: a criterion that two reasonable
evaluators read differently needs rewording.

## If someone disagrees with their evaluation

An evaluated person can **contest** an evaluation, in writing, from the evaluation itself. The person who
**wrote** that evaluation cannot be the one who rules on the appeal — the system will not let them. A right of
appeal decided by the same person who made the decision is not a right of appeal.

The outcome is recorded on the evaluation, so the history stays visible.

## The conversation afterwards, and whether it worked

An evaluation on its own changes nothing. What changes something is the conversation that follows it — and the
usual problem is that nobody can later tell whether it helped.

From an evaluation, record a **coaching session**: what you agreed together, and by when you will check. Then:

1. **The person coached confirms it happened.** Only they can — a manager ticking it on their behalf would turn
   a two-way conversation into a form field. They will find it in their own **Coaching** list.
2. **Later, you close the session against a follow-up evaluation** of the same person, carried out after the
   conversation. The system checks this: an evaluation about somebody else, or one dated before the
   conversation, is refused with the reason shown.
3. **The board then shows before → after** — average score before coaching, after it, the difference, and how
   many of the sessions actually improved.

It also tells you **on how many sessions the figure was computed**. Sessions closed without a follow-up review
prove nothing and are not counted. An average without its denominator is just a claim.

The default follow-up window (14 days) is in **Settings**; each session can move its own date.

### Coaching without a call

A session usually starts from an evaluation. It does not have to. On the **Coaching** page, **Assign** opens a
session that has no call behind it — for a pattern you have noticed, or for something that is not on any
scorecard at all, like service in the showroom.

You pick the person, a **topic**, what you agreed, and when you will check. The criteria from your scorecards
are offered as suggestions, but you can type any topic: a criterion belongs to a scorecard, and the cases that
need this most are exactly the ones with no scorecard to belong to.

Everything after that is the same — the person confirms, you close it later, and a follow-up evaluation is
optional.

**The person is told.** When a session is assigned, they get a notification linking straight to their Coaching
list. Assigning a session to yourself sends nothing, deliberately.

## Keeping the trend without keeping the transcript

A quality trend is worth keeping for years. The free-text note about one particular phone call usually is not —
and in many places should not be.

**Settings → Keep evidence (days)** deletes the **notes and links** of evaluations older than that, while the
**scores stay**. Set it to 0 (the default) and nothing is ever removed, which is exactly how the module behaved
before this option existed.

## Deciding what gets reviewed, instead of hoping

An evaluation only happens when somebody remembers to do one — so the reviews that get done are the ones
nobody was busy for, which is rarely the ones that mattered. **Plans** fix that. A plan says WHAT gets
reviewed, WHEN and on which trigger, separately from the scorecard, which says what it is measured with.

Open **Evaluation plans** and create one of three kinds:

- **On an event** — the useful one. Pick something that happens in the system: a ticket is reopened, an SLA is
  breached, a call is missed, a delivery is returned. The moment it happens, a review lands in the queue. The
  list of events comes from the platform's own registry, so anything any module reports can be a trigger.
- **Scheduled** — a quota per person, weekly or monthly. Use this for routine coverage.
- **Manual** — a plan you queue work into yourself.

The page shows **which events are actually being listened to** right now, under the plan list. If a plan looks
active but its event is not in that line, it is not firing — which is worth knowing before you wonder why no
reviews appear.

## The review queue

**To review** is the board of what plans have queued. Each item says which plan put it there and why, who or
what is to be reviewed, and by when.

- **Evaluate** opens the scorecard with the person and the item already filled in — the trigger identified
  them, so you should not have to look them up again.
- The queue item closes itself when that evaluation is **submitted**. A draft does not count: unfinished work
  should not report coverage.
- **Skip** requires a reason. A skip without one cannot be told apart from a review that simply never happened,
  and the whole point of a plan is to make that gap visible. Skipped items stay on the board with their reason.
- Items nobody got to are marked **overdue**, and eventually **expired** — still visible, never deleted.

### Evaluating straight from a call

On the call list, the evaluate button beside a recording opens the scorecard with the **agent, the date and
time, and the call's duration** already filled in. It reads them from the call itself rather than from the
link, so it works from wherever you reach the evaluation.

Duration is not a detail: it is how you later recognise **which** of the conversations on a lead's card was
the one that was evaluated.

Anything you filled in yourself is never overwritten, and a resumed draft keeps its own values. On a missed
call, where nobody answered, the agent is left blank — the system does not guess a person, because an
evaluation attributed to the wrong one is worse than one you complete by hand.

Coverage is always shown as **done out of total**, never as a bare percentage. "80% complete" on a plan with
five items would be a claim, not a measurement.

Who sees what: anyone who can evaluate sees their own queue; a manager sees everything — because for a manager
the valuable part of the queue is precisely the work that is *not* being done.

## What to open during the review

An evaluation can carry links to the things behind it: the call it is about, the lead that was handled badly, a
task, a document. You add them on the evaluation form, under **Causes**, and they appear on the evaluation card.

This exists for one moment in particular. "You are not filling these fields in properly" is an argument. The
same sentence with the lead open on screen is a demonstration — and you are both looking at the same thing.

Two details that matter later:

- Causes are saved on a **draft** too, so you can collect them while you are still listening.
- The label and the address are stored **as you wrote them**. If the lead is renamed next year, or the
  recording is rotated out, the line still says what was discussed. An evaluation is a record of a conversation
  that happened, not a live view of the system.

## Your own words for outcome and channel

Two small lists on the evaluation form are yours to define, in **Settings**, one value per line:

- **Interaction outcomes** — how it went. Ships as *progress · neutral · negative*, which came from one
  company's own sheet. Replace them with yours.
- **Channels evaluated** — how the interaction happened: call, chat, e-mail, meeting…

Leave either box empty and the shipped list is used, so a field can never end up with no options at all.

Note the difference between the **channel** and the **source**: the channel says *how* it happened, the source
says *which record* the review points at. A chat about lead #4412 is source = lead, channel = chat.
## Good to know

- **Nothing is thrown away on uninstall.** Removing the module keeps your scorecards and evaluations in the
  database; reinstalling brings them back.
- **Subject types are extensible.** The five built-in types cover most cases; a developer can add your own
  (for example "Vehicle inspection") without changing the module.
- **Scores are deterministic.** The same answers always give the same percentage — there's no hidden rounding
  of the verdict, and the threshold comparison is exactly the number you typed on the scorecard.

## Where to go next

- 🎓 Build the training a failed evaluation assigns → [Academy](tsync-academy.md)
- 👥 Employee records and departments → [HR Records](tsync-hr-profile.md)
- 📊 See pass-rates over time → [Reports](../reports.md)
