32-Question Complaint Management Maturity Test

Why we ask: Most organizations today are "multichannel." Customers can reach them through many channels, but each channel lands in a separate queue, a separate team and, more often than not, a separate tool. When email is handled in one system, social media by an agency and WhatsApp on a mobile phone, the same customer appears to have three separate problems; in reality, they are usually describing a single problem through three channels.

What good practice looks like: In an omnichannel approach, the channel is just one attribute of the ticket. Whichever channel it arrives from, the ticket is linked to the same category tree, the same workflow and the same customer record. Customer identity is matched across channels; duplicate tickets on the same issue are automatically deduplicated and merged into a single timeline. The agent sees the customer's entire cross-channel journey on one screen.

Why we ask: "How many people have I explained this to?" is one of the most common sources of customer dissatisfaction. Losing context at a channel handoff wears the customer down and wastes the agent's time re-collecting information that was already gathered.

What good practice looks like: A customer asks about a pending request in live chat; the agent starts looking into it, but the customer has to leave. When they later call the call center from the road, the agent who answers sees the chat transcript, the details of the request and where the earlier investigation left off on their screen, and the conversation picks up where it stopped. What makes this possible is keeping the conversation tied to the customer and the ticket rather than to the channel. The same principle applies to bot-to-human handoffs: when the bot hands over, the conversation history, the category it identified and the information it collected are passed to the agent in full.

Why we ask: Self-service that offers nothing more than a form shifts the burden onto the customer: the wrong category gets selected, information is left out, and the ticket bounces back to an agent at the very first step. The value of self-service lies not in having a form, but in being intelligent.

What good practice looks like: The customer describes the problem in their own words; AI predicts the category, brings up the form specific to that category and asks for any missing information before the ticket is even created. Questions whose answers are in the knowledge base are answered instantly; requests such as status inquiries, document requests and address updates are completed without ever reaching an agent. The customer sees all their requests on the same screen, including tickets opened by phone, email or WhatsApp. If the organization connects the self-service portal to its own web application via single sign-on (SSO), the customer does not have to verify their identity again.

Why we ask: Today's customers may prefer to leave a comment under a product or rate you on a review platform rather than fill out your form. This content is public, and it usually sits outside the organization's complaint system. An unanswered marketplace question is a lost sale; an unanswered review is lost reputation.

What good practice looks like: Marketplaces and review platforms are connected to the system as channels, just like email. AI filters out irrelevant content, categorizes relevant messages and converts them into tickets, and drafts a reply in the brand's voice; the reply is sent to the platform from the system. Cases that require a return, an exchange or a shipment check trigger the relevant workflow; questions that can be matched against the order system are resolved automatically. Every ticket receives a sentiment tag, so negative comments piling up under a product become visible the same day, not in a report.

Why we ask: The root cause of a customer complaint often lies with a dealer, a shipping company or an internal department. When requests from these parties get lost in email traffic, the promise made to the customer gets lost with them. Dealer and branch requests are also early warning signs of customer complaints.

What good practice looks like: A separate portal, category tree and SLA are defined for each party, such as dealers, branches, suppliers and employees; but all of them run on the same platform, with the same workflow engine. When a customer ticket is assigned to a dealer as a task for resolution, the dealer responds through its own portal and the customer ticket automatically moves forward with that response. Authorization ensures that each party sees only its own tickets.

Why we ask: Follow-up contacts made just to "check on the status" account for a sizable share of call center volume. When customers are not kept informed, they call again and write again; and if every contact is logged as a new ticket, your statistics are distorted too.

What good practice looks like: Notifications are triggered automatically by the steps of the workflow: ticket received, forwarded to the relevant department, awaiting additional information, resolved. Message templates vary by category and channel but are managed from a single place, so the same organization never sends messages in different tones. The customer's preferred channel is used first, and every message sent is recorded in the ticket's timeline.

Why we ask: A significant share of the emails landing in the support inbox is not work: auto-replies, irrelevant messages from mailing lists, correspondence that belongs to another department but was sent to the support address, spam. Having a person open, read, sort and close each of these is both costly and demoralizing. The real problem is that genuine complaints wait in line inside this noise.

What good practice looks like: Every incoming email passes through a pre-screening layer before it becomes a ticket. This layer (we call it PRIME) decides whether the message is truly a customer ticket that needs to be processed; irrelevant content is filtered out at the door or flagged as low priority. Every valid message is typed as a complaint, request, information, thank-you or spam; it is assigned urgent, high, normal or low priority based on the tone, subject and impact of the content, and every decision is produced together with a confidence score. Rule-based features, a sentiment model and a language model's context assessment combine into a single decision. The system starts with a general model; as examples verified and corrected by agents accumulate, it specializes in the organization's own email traffic. Only real work remains in the team's queue.

Why we ask: The vast majority of what lands under a social media post is not a customer ticket: emojis, "great", mentions meant only to tag someone, hundreds of one-word comments on campaign posts. Hidden among them is a genuine complaint (an undelivered order, a product that does not work, a request left unanswered), and because it is public, it is more urgent than on any other channel. On campaign days this flood cannot be screened by human effort; and when it is not screened, the genuine complaint gets lost in the noise.

What good practice looks like: Social media accounts are connected to the system as channels; comments, mentions and direct messages are gathered into a single stream. The same pre-screening layer runs here too: emojis and context-free content are filtered out or flagged as low priority; every valid message is typed (complaint, request, information, thank-you, spam) and prioritized by its tone, subject and impact. Even if ten thousand comments arrive on a campaign day, the team works with the genuine tickets among them and sees the most urgent one at the top of the list. Genuine tickets are categorized and enter the workflow; a reply draft is prepared in the brand's voice, passes through an editor preview and is sent back to the platform as a comment or message. A sentiment tag is added to every ticket.

Why we ask: The category is the backbone of the process: it determines which team will handle the ticket, which form will be filled in and which SLA will run. In systems where agents pick the category by hand, the same issue is assigned to five different categories by five agents; reports become unreliable and tickets sit with the wrong teams.

What good practice looks like: Using what it has learned from past tickets and the organization's category tree, AI determines the ticket's type, subject and context; it assigns the category and routes the ticket to the team, SLA and workflow tied to that category. Email, social media, live chat, WhatsApp, call center or self-service; whatever the source, the same classification logic applies. Instead of different teams' different interpretations, this creates a shared, learning and consistent foundation for categorization. Every category an agent corrects improves the model's next decision.

Why we ask: A significant share of tickets are questions whose answers are already known: where is my order, when will my refund reach my account, how do I get my invoice. Having an agent read each of these and answer from a template means doing the same job hundreds of times every day.

What good practice looks like: For a ticket whose category is known, AI prepares the reply using the knowledge base, approved templates and data from integrated systems (order status, shipment tracking, transaction history). In categories the organization has approved, the reply is sent directly and the ticket is closed; in the others, the agent previews, edits if necessary and approves. Tickets that cannot be answered or that require action are passed to the relevant workflow. What the agent sees is not an empty reply box but a ready draft.

Why we ask: A survey measures satisfaction after the work is done. Yet the customer has long since expressed their dissatisfaction within the conversation, in their own words. If the only person who notices it is the agent reading that conversation, the manager sees the customer who is about to be lost only in a report.

What good practice looks like: Every ticket and every message receives a sentiment tag regardless of channel; a satisfaction score is also maintained at the customer level. When sentiment shifts negative over the course of the conversation, the ticket is moved up the queue and, if necessary, an alert goes to the manager. When an agent picks up the phone, they see the sentiment of the customer's most recent interactions and speak accordingly. Sentiment trends by category, in turn, show which product or process is systematically angering customers; this is the earliest signal for root cause analysis.

Why we ask: Automatically answering a shipment status question is low risk; automatically closing a damage claim or a credit card dispute is high risk. An organization that cannot draw this distinction either never turns AI on, or pays the price when it does.

What good practice looks like: The level of automation is defined category by category: in some categories the reply goes straight to the customer, in others the agent previews and approves, and in others AI only classifies and prioritizes. Every decision AI makes (type, category, sentiment, priority, suggested reply) is recorded in the ticket's history along with its confidence score; when an agent corrects it, the correction remains visible and is fed back into the model's training. The boundaries of AI are drawn by the organization, not by the software.

Why we ask: A chat window that goes silent after business hours, or a bot that answers every sentence with "let me connect you to an agent," shows the difference between opening a channel and managing one. A bot's value lies not in how many questions it answers, but in never handing an agent a question it could have answered itself.

What good practice looks like: Two kinds of bot work together. A rule-based (guided) bot greets the customer with menus and runs structured tasks without error. A language-model-based bot understands free text; because it is trained on the organization's knowledge base, documents, product manuals and past case experience, its answers rest on the organization's own knowledge. Whether a question is frequently asked does not matter: if the answer exists in the organization's knowledge, the bot answers it. The same bot runs on the website, the authenticated web application, the mobile app and WhatsApp with the same knowledge; there is no need to train a separate bot per channel.

Why we ask: A bot that is not connected to the order system can only answer "where is my order" with "let me connect you to an agent." A bot that informs but cannot act puts the customer back in the queue one step later; the time it saves exists only on paper.

What good practice looks like: The bot checks status in integrated systems, creates tickets, updates existing tickets and resolves many requests end to end within the chat. When an approval, a missing document or a step from another department is required, it starts the relevant workflow itself. When it hands over to an agent, the full conversation, the category it identified, the information it collected, the customer's order and product context, the cross-channel ticket history, sentiment analysis and satisfaction score are already on the agent's screen. The customer never explains anything twice.

Why we ask: Having a knowledge base and using it are two different things. An agent under pressure does not search; they write what they know. The result is five different answers to the same question from five agents, and know-how that walks out the door when an experienced agent leaves.

What good practice looks like: The knowledge base stops being a place the agent searches and becomes an assistant that sits beside them (what we call the supervisor bot). The assistant knows the ticket's context, the category, the customer's history, the integrated data and company policies; it suggests a draft reply or internal note, shows what was done in similar cases, flags the steps that must not be skipped and the risks, and reminds the agent which questions to ask. Because the suggestions rest on the organization's own documents, they are auditable; the agent has the final say. The same assistant supports not only the front-line agent but also supervisors and back-office teams in exactly the same way.

Why we ask: An agent switching between three screens to identify the customer is the main source of "please hold the line" time. And an agent who takes notes during the call and says "I'll log it later" opens the ticket either incomplete or in the wrong category.

What good practice looks like: When a call comes in, the customer is recognized by their number; the cross-channel ticket history, open requests, order, policy or account data from the ERP or CRM, sentiment analysis and satisfaction score open on a single screen. While the agent listens to the customer's problem, the system categorizes the topic and brings up the script specific to that category. By the time the call ends, the ticket is either resolved directly or routed to the right workflow.

Why we ask: A ticket opened with incomplete information is the biggest enemy of resolution time. Calling back to ask "could I have your order number?" wears out both the customer and the team, and the first contact resolution (FCR) rate drops.

What good practice looks like: Once the category is identified, a script specific to that category appears in front of the agent: the questions to ask, the fields to fill, the documents to request and the validations to apply. The script runs with the same logic not only in the call center but also in the self-service form and the bot; whatever the channel, the ticket is opened with the same data. The number of tickets that back-office teams send back as "information missing" drops noticeably.

Why we ask: Without a defined process, every ticket is resolved only as well as the experience of the agent who receives it allows. The question "Who should we forward this to?" is asked anew every time, and the answer varies from person to person.

What good practice looks like: The category tree is the backbone of the process. For every category and subcategory, the responsible group, the resolution steps, the target time per step, the form to be used and the template sent to the customer are defined. A ticket is automatically linked to these definitions based on its category; the agent does not have to decide. The same problem follows the same path no matter who handles it. This standardization is also a core expectation of standards such as ISO 10002.

Why we ask: Many tools call forwarding an email to the relevant department a "workflow." Yet forwarding is not the same as starting a process. Once a ticket starts waiting in an inbox, its visibility ends as well.

What good practice looks like: Consider a return request: a task is assigned to the warehouse to inspect the product, the warehouse completes a checklist, manager approval is requested if the amount exceeds a certain threshold, a refund instruction goes to accounting, and the customer is informed at every stage. Each of these steps is defined in the workflow; every step has a known owner, duration and required data. The next step cannot begin with missing data. The process lives in a traceable flow, not in an email chain.

Why we ask: A target such as "We resolve complaints within 5 business days" does not tell you at which step the time was used up. When the total time is exceeded, everyone points at everyone else. Without a step-based SLA, the delay has no owner.

What good practice looks like: Each step has its own time limit; the moment a ticket lands with a team, that team's clock starts running. As the deadline approaches, the owner receives a warning; when it expires, the ticket escalates to the next-level manager with its full context and is reassigned if necessary. The end-to-end SLA is tracked separately as well. The manager's screen shows in real time how many tickets are waiting at which step and which ones are at risk. Escalation depends on rules, not on someone remembering.

Why we ask: A fixed flow cannot handle exceptions, and exceptions are always the most expensive tickets. In organizations where exceptions are handled by email or by "asking the manager," the process looks defined but does not work.

What good practice looks like: Business rules are defined with "if/then" logic: if the customer segment is VIP, the flow takes the short path; if the amount threshold is exceeded, an approval step is added; if the ticket comes from a specific region, it lands with that region's team; within the team, distribution is based on workload or expertise. The rules determine not only "who gets it" but also the next step, the timers and the automatic actions (scheduling a courier pickup, initiating a return, opening a corrective action).

Why we ask: If a ticket marked "normal" at opening is still "normal" after waiting three days and a second call from the customer, prioritization is not working. With static priority, the queue is ruled by whichever ticket was opened earliest, not by the one shouting loudest.

What good practice looks like: Priority is recalculated throughout the ticket's lifecycle. As waiting time grows, as repeat tickets arrive from the same customer, as sentiment turns negative or as the customer segment changes, priority rises automatically and the ticket moves up the queue. The priority and sentiment tags assigned by AI at intake feed into this calculation. The agent does not waste time on the question of "which one should I look at first."

Why we ask: A campaign, a regulatory change or a new product means a new category and a new flow in customer service. If that change requires opening a change request, getting a quote from the vendor and waiting for budget, the system is running at the vendor's pace, not the organization's.

What good practice looks like: The category tree, forms, workflows, business rules, SLA definitions, agent scripts, bot scripts and message templates are designed and updated in visual editors, without writing code. The customer service manager defines a new category in the morning, and by the afternoon tickets are already flowing into that workflow. The IT team focuses on the work that is genuinely its own: integration, security and data.

Why we ask: No-code flexibility does not mean uncontrolled flexibility. In a system where anyone can change anything, the process soon turns into something nobody understands; and when the audit asks "who set this rule?", there is no answer.

What good practice looks like: Change permissions are role-based; who may edit the category tree, workflows and rules is clearly defined. Every change is logged with who made it, when, and what was changed. This gives business units their freedom without compromising the organization's auditability.

Why we ask: When an agent has to log into three separate systems to answer a single question, it both lengthens handling time and produces errors. For bots and automated replies in written channels, integration is the difference between merely existing and actually being useful.

What good practice looks like: The integration is set up once, by the IT team (two-way, via REST APIs and webhooks). From then on, business units use that data in forms, workflows and screens without touching the integration. The agent sees the customer's order, policy or account right next to the ticket; a workflow step writes the return instruction directly to the ERP; the bot pulls the status query from the order system and answers it. Enterprise identity management (SSO, LDAP, user provisioning) is part of this definition as well.

Why we ask: Customers do not want to leave your app and go to another site to submit a complaint. A self-service channel that does not live inside the organization's own portal and app is a self-service channel nobody uses.

What good practice looks like: The self-service form, ticket view and chat window are embedded into the organization's own interfaces as ready-made components (iFrame, JavaScript, mobile and web SDKs). If the customer is already signed in to the organization's app, self-service starts with their identity; the bot and forms know the customer's context from the outset. The same experience is delivered on web and mobile with minimal development effort.

Why we ask: Without an audit trail, the question "who is holding up this ticket?" turns into an argument. In regulated industries, this is not a preference but a requirement. Once AI enters the picture, the question grows: Who wrote that reply, who chose that category?

What good practice looks like: Every action, decision and timestamp is recorded in the ticket's history: who opened the ticket, how long it spent at each step, who wrote what, which document was attached and when, which type, category and sentiment the AI predicted and with what confidence score, and whether the agent corrected them. An auditor can reconstruct the entire process from a single ticket. This traceability feeds quality management, compliance and agent training all at once.

Why we ask: A weekly Excel report shows last week's delays; it does not prevent this week's. When measurement happens after the operation rather than inside it, management can only react to events.

What good practice looks like: Built-in dashboards show in real time how many tickets are waiting at each step, which team is building a backlog and which tickets are approaching their SLA limit. First contact resolution rate, step-based SLA compliance, volume by channel and category, and team and agent performance are tracked through ready-made reports; managers build their own dashboards without writing code. For deeper analysis, data flows through ready-made interfaces into the organization's own business intelligence tools such as Power BI, Tableau or Qlik.

Why we ask: An annual satisfaction survey does not tell you which ticket cost you a customer. The ISO 10002 standard expects measurement to be embedded in the process; certification expects you to be able to prove it.

What good practice looks like: When each ticket is closed, the customer is asked for brief feedback, and the result is linked to the ticket, the category and the agent. A low score can automatically trigger a review workflow. Sentiment analysis within the conversation provides a satisfaction indicator even for customers who do not answer the survey. The recording, informing, follow-up, closure and corrective/preventive action steps required by the standard are defined in the workflow itself; at the certification audit, pulling a report from the system is enough instead of preparing a separate file.

Why we ask: A volume report tells you how many tickets a category has; it does not tell you why. Finding out why requires someone to read the hundreds of tickets and resolution notes in that category. When that work is not done, root cause analysis rests on impressions from the few cases people talk about most.

What good practice looks like: AI reviews the tickets and resolution notes in each category together; it highlights common problems, recurring patterns and likely root causes, and suggests preventive improvements. The output is not a data table but a readable summary that management and quality teams can turn directly into action: "In this category, most tickets cluster around this product, at this step, for this reason; this fix is recommended." Summaries are refreshed periodically and create a shared language for SLA, team capacity and process improvements. Category summarization works together with sentiment analysis and dashboards.

Why we ask: A campaign period, a seasonal shift or a product launch means a volume spike in customer service. When that spike is not planned for, SLA breaches and overtime arrive together; when it is, it is usually just a matter of adjusting shifts.

What good practice looks like: Using historical ticket data and seasonality, AI forecasts next period's ticket volume by category. Managers see in advance which categories will be busy in which weeks and adjust staffing needs, shifts and bot coverage accordingly. SLA risk shows up in the plan before a breach happens, not in a report afterward.

Why we ask: A root cause does not disappear when it is found and discussed in a meeting; it disappears when it is tied to an action and the result is measured. A corrective action that is not measured is a well-intentioned note.

What good practice looks like: A root cause spotted in a category summary or on a dashboard is turned into a corrective/preventive action (CAPA) record; the action's owner, steps and deadline are defined as a workflow. Once the action is complete, ticket volume and sentiment trend in the same category are monitored; if there is no decline, the action is not closed. This is where the loop closes: the complaint is not just answered, its source is fixed.