Configure complaint taxonomy

Complaint detection has no built-in idea of what counts as a complaint at your firm. It works entirely from the categories you define: a ticket is compared against them, and a case is opened only when one of them fits. The taxonomy therefore decides what your complaints register contains. Too few categories and real complaints go undetected; overlapping categories and every case arrives carrying several tags. The taxonomy lives under Knowledge > Complaints, alongside scorecards and regulations, rather than under Compliance with the cases themselves.

​

Before you start

• You need an Administrator or Quality Analyst role. New and Edit are visible but disabled for everyone else, including the Compliance Analyst role, so ask an administrator if you cannot click them.
• Decide whether a category applies across the whole organization or to one workspace before you create it. Detection only considers categories that apply to the ticket’s workspace.
• If your firm already reports complaints against a published taxonomy, use those names here. The category name is what appears as the tag on every case.

​

Add a category

1. Go to Knowledge > Complaints.
2. Click New.
3. Fill in the Name and Description.
4. Leave Workspace as All workspaces, or pick the single workspace the category applies to.
5. Add the wording customers use with Add keyword, one phrase per row.
6. Set the Risk level.
7. Click Save.

The new category appears as a card with its description, its workspace scope, and its keyword count. Each card carries an Edit action that reopens the same form, with a Delete action at the bottom of the dialog.

​

What each field does

• Name — the category as it appears on a case and in the Category filter. Short and recognisable.
• Description — the definition detection classifies against. This is where the work goes: say what belongs in the category and, where it helps, what does not. Complaints about a fee, charge, or interest amount the customer did not expect or believes was applied incorrectly gives the model something to judge; Fee issues does not.
• Workspace — All workspaces, or one connected help desk. A workspace-scoped category is invisible to tickets from anywhere else, which is the way to run a different taxonomy for a separate brand or entity.
• Keywords — the phrases your customers actually use, such as payment blocked or cannot withdraw. They are supplied to the model alongside the name and description as hints about wording.
• Risk level — Low, Medium, High, or Urgent. It becomes the priority of any case matched to this category.

​

How risk level drives the case

The risk level you set here is the same value the complaints list calls priority. When a ticket matches more than one category, the highest risk level among them wins. Alerting for high and urgent cases is configured once for the organization in Configure notifications, so the risk level you choose here decides which cases trigger those alerts.

​

Keep the taxonomy working

Aim for a small set of categories that a person could sort complaints into without hesitating. When two categories overlap, detection tends to apply both, and the case’s priority quietly follows the more severe one. Changes take effect on future detection only. Editing a description does not reclassify complaints that have already been raised, and Delete takes a category out of detection from that point onward while cases already tagged with it keep their tag. If a category is producing cases you do not consider complaints, tighten its description rather than deleting it, then check the next few days of detections on the complaints list. A category with no keywords still works. A taxonomy with no categories does not: detection has nothing to match against, and no cases are created at all.

​

Related

• Work a complaint case
• Configure notifications
• Rulebase glossary