Quality and analytics
Writing a quality standard your team can check
How to turn "a good conversation" into criteria that can be checked on every conversation, with weights, industry examples and a version history.
On this page
Every conversation is scored against the quality standard your team writes. That makes the standard one of the most useful documents in a deployment: it states, in plain sentences, what your organisation expects of every conversation with a customer. This page explains how to write criteria that can be checked the same way every time, how to weight them, and how to keep the standard in step with your business. Telonic works through it with your quality, operations and compliance teams during implementation.
Write behaviours, not impressions
A criterion is useful only if two careful reviewers, reading the same conversation, would reach the same answer. "Was polite" and "showed empathy" fail that test, because each reviewer brings their own idea of what they mean. "Acknowledged the delay before giving options" passes it, because you can point to the sentence where it happened or show that it did not.
Write each criterion as something observable: something said, something done, or something checked. Where a criterion depends on context, say so in the criterion. "Offered a person when the customer asked for one" is checkable. "Escalated appropriately" is not, until you say what appropriate means.
| Instead of | Write |
|---|---|
| Was professional | Greeted the customer and gave the company name |
| Protected the customer's data | Confirmed identity using the agreed checks before sharing any account detail |
| Gave accurate information | Answered from an approved source, and did not state a figure that is not in your systems |
| Was helpful | Gave the correct next step and when the customer should expect it |
| Handled the complaint well | Offered a person when the customer said they wanted to complain |
| Followed the rules | Gave the required disclosure at the point it is required |
Six behaviours most standards start from
Most standards we write with customers begin from the same six behaviours, then add what is specific to the industry and the queue.
- Greeted and identified. The customer knows who they are speaking to and which company.
- Confirmed identity. The agreed identity checks were completed before account details were shared.
- Answered from an approved source. Every factual answer came from your systems or your approved documents.
- Offered a person. Where the customer asked, or your rules required it, the customer was offered someone from your team.
- Gave the correct next step. The customer left knowing what happens next and when.
- Gave the required disclosure. Anything your regulator or your policy requires to be said, such as recording notices or product disclosures, was said at the right point.
Examples by industry
| Industry | Example criteria |
|---|---|
| Property | Gave the instalment amount and due date from the payment system, not from memory · Confirmed which unit the buyer meant before answering · Explained what happens next with a snagging item and who will contact the buyer · Did not give a handover date that is not in the project schedule |
| Travel and hospitality | Acknowledged the delay or cancellation before giving options · Offered only the rebooking options the fare permits · Confirmed the change back to the guest, with the new booking reference · Offered a person to any guest who raised safety, health or distress |
| Insurance | Checked the caller was safe before taking claim details · Asked the questions required for this claim type · Explained the excess from the policy schedule · Did not suggest whether a claim will be accepted · Told the policyholder which documents are still needed |
Weight what matters most
Some criteria matter more than others. A missed greeting and a missed identity check are both failures, but only one of them is a data protection problem. Each criterion carries a weight that reflects how much it matters to you, and the overall score is built from the weighted results.
Some criteria are too important to average. Mark these as critical: a conversation that misses a critical criterion goes to review whatever its overall score. Identity checks and required disclosures are the usual candidates. Keep the list short, so the review queue holds the conversations that really need a person.
Calibrate with your quality team
A standard is ready when your reviewers and the automated scores agree. Before go-live, two or more of your reviewers score the same set of conversations from testing, and we compare their results with the automated scores. Disagreement nearly always points to a criterion that needs tighter wording, not to a reviewer who is wrong.
Keep calibrating after go-live. A monthly session, in which your reviewers score a sample and compare, catches drift early. It also keeps your team's judgement at the centre of the standard. See Quality review on every conversation.
Version the standard
Your business changes, and your standard should change with it: a new product, a new disclosure, a change in how you handle refunds. Each change creates a new version. Every score records the version it was scored against, so a change in scores after a new version is visible as exactly that.
A new version is tested against past conversations before it is used, so you can see how it would have scored them. It goes live only when your team approves it. See How changes go live.
In practice
A Dubai property developer writes the standard for payment questions on one completed project.
- Its customer care lead, Huda, starts from the six common behaviours and adds three of her own, including "Gave the instalment amount and due date from the payment system".
- Her compliance colleague asks for one more: "Did not discuss any change to the payment plan", because changes to a plan stay with the collections team.
- They weight the identity check and the payment plan criterion highest, and mark both as critical.
- Two of Huda's reviewers score forty conversations from testing. They disagree with the automated result on "Explained what happens if a payment is late", because the developer's policy has two versions. The criterion is split into one for each version.
- The standard goes live as version 1. Three months later, a new service charge disclosure becomes version 2, tested against the previous month's conversations first.
What your team controls
- Every criterion, its wording, its weight, and whether it is critical.
- The threshold below which a conversation goes to review.
- Who approves a new version of the standard.
- When a new version goes live, after it has been tested.