Why a defined process beats good intentions
Most organisations do not lack the will to handle complaints well — they lack a repeatable process. When each complaint is handled from memory, quality depends on who happened to pick it up and how busy they were that day. A defined complaint handling process removes that lottery: it fixes the same sequence of steps for every complaint, so a busy Tuesday and a quiet Friday produce the same discipline, and so a new hire handles a complaint the way your best engineer would.
The value of a written procedure is not bureaucracy. It is that each step has a clear entry and exit condition — a complaint is not "assigned" until it has a named owner, not "resolved" until corrective action is recorded, not "closed" until a supervisor has verified it. Those gates are what make a complaint desk auditable and, more importantly, reliable. This guide walks the full procedure that sits underneath the broader complaint management discipline.
The eight steps, in order
Every disciplined complaint process runs the same backbone. Compressed, it looks like this.
Six boxes, eight steps — categorise-and-prioritise are one habit, and resolve-and-verify are two halves of the same gate. The next section takes each in turn.
Each step in detail
Where service requests branch off
Teams that handle complaints usually handle service requests too — installations, breakdowns, preventive visits, after-sales work. A service request follows the same capture-to-close backbone, but the middle changes shape. Instead of root-cause investigation, steps four and five become schedule and execute: the ticket is assigned to an engineer, a visit is scheduled and followed to completion, and where the work is chargeable it raises a service invoice at closure.
The distinction is worth keeping crisp. A complaint asks why did this happen and how do we stop it recurring? A service ticket asks who does the work, when, and is it done? Running both on one ticket engine — a single entry screen with a different ticket type — means a "complaint" that is really a service request still gets scheduled, and a "service call" that is really a recurring defect still reaches the quality team. The full comparison is in complaints vs service tickets.
Want your own complaint handling procedure on screen?
We can map your eight steps into Fast Complaint Software in a 30-minute demo — your categories, your SLAs, your verification rules.
The three steps teams skip
When a complaint process fails, it almost always fails at one of three steps — and they are the same three every time.
- Capture is skipped when a complaint is handled verbally and never logged. It felt resolved, so nobody wrote it down — and now it cannot be counted, and the same defect will surprise you again.
- Verify is skipped when handlers self-close their own tickets. Closure without an independent check is just an opinion, and it is the first thing an auditor probes. Read why helpdesk tools stop here.
- Feedback is skipped because the ticket already looks finished. But a closed ticket with an unhappy customer is a lost customer in waiting, and skipping feedback is how you never find out.
Software helps precisely because it can make these steps mandatory: a ticket cannot close without a verification record, and feedback is scheduled automatically rather than left to whoever remembers.
The process in Fast Complaint Software
Fast Complaint Software, built by Improsys in Pune, implements the whole procedure on one platform.
Frequently asked questions
What is the complaint handling process?
The complaint handling process is the defined sequence a customer complaint follows from the moment it is received to the moment it is closed and the customer's satisfaction is confirmed. In a disciplined process it has eight steps — capture, categorise and prioritise, assign, investigate, resolve, verify, close and capture feedback — with each complaint carried as a numbered ticket that has an owner, a due date and a full audit trail rather than living in an inbox.
What are the steps in a complaint handling procedure?
There are eight steps: (1) Capture the complaint as a numbered ticket against the customer; (2) Categorise and prioritise it so a category and priority set the SLA; (3) Assign it to a named owner; (4) Investigate what actually went wrong, escalating real defects into 8D root-cause analysis; (5) Resolve it by applying and recording corrective action; (6) Verify the resolution through a supervisor before closure; (7) Close the ticket with its full history retained; and (8) Capture feedback and roll the rating into a Customer Satisfaction Index.
Why should a supervisor verify a complaint before it is closed?
Supervisor verification separates the person who did the work from the person who confirms it is done, which keeps the record credible. Without it, a handler can quietly self-close a difficult complaint and the closure means nothing. With a controlled verify-before-close step, an auditor can trust that a closed complaint was genuinely resolved and that its corrective action was effective — which is what ISO 9001 clause 10.2 expects.
Where does 8D fit in the complaint handling process?
8D sits inside the investigate and resolve steps, and only for complaints that reveal a genuine product or process defect. Minor issues get a quick check and correction; serious ones escalate into a structured 8D investigation — contain, find the root cause with a fishbone diagram, apply corrective action, verify it and prevent recurrence — so the underlying cause is removed rather than the symptom patched. The complaint ticket remains the customer-facing anchor while the 8D carries the analytical work.
How is the complaint handling process different for a service request?
A service request follows the same capture-to-close backbone but replaces root-cause investigation with scheduling and execution: the ticket is assigned to an engineer, a visit is scheduled and followed to completion, and where the work is chargeable it raises a service invoice. A complaint asks "why did this happen and how do we stop it recurring?", while a service ticket asks "who does the work, when, and is it done?" Good software runs both on one ticket engine.