How to Automate Complaint Handling — Step by Step

Automating complaint handling is not about buying a tool and switching everything on at once. It's about understanding your own process first, and only then handing the machine those parts of it that are repetitive and predictable. This guide walks through six steps — from a sheet of paper with a process map to monitoring the results. The order matters: each step assumes the previous one is done.

Complaint handling automation means replacing the manual, repetitive parts of the complaints process — issuing numbers, sending notifications, tracking deadlines, generating documents — with rules the system executes whenever a defined event occurs.

Step 1. Map the process before you automate anything

The most common mistake during implementation is automating a process nobody has ever written down. The result is predictable: the system entrenches the chaos, only faster.

Start by listing the stages a ticket actually goes through in your company — not the ones it should go through in theory. For each stage, answer four questions:

• Who owns the case at this stage?
• What has to happen for the ticket to move forward?
• How long can this stage last at most?
• Should the customer be told anything?

A typical complaint workflow in an online store looks roughly like this: New → Verification → Awaiting goods → Assessment → Decision → Closed. Yours might have five stages or twelve — it isn't a contest. What matters is that every transition between stages has a clear owner and a clear condition.

While you're at it, mark which transitions require a human decision (do we accept this complaint?) and which are purely mechanical (sending a confirmation, issuing a number, reminding someone about a deadline). Only the latter are candidates for automation — and that list is exactly what you'll be configuring in step 4.

In Reklamator this map translates directly into configuration: a process consists of statuses (a dictionary of states), stages (phases of handling) and operations — buttons that move a ticket from one stage to another. Every stage has a maximum duration in business days, and every operation has permission groups defining who is allowed to perform it.

Step 2. Choose a system to fit your process, not the other way round

Once you have the process map, evaluating tools stops being guesswork. Instead of comparing feature lists from landing pages, check whether the system can reproduce what you have on paper.

Questions worth asking before you decide:

• Can I define my own stages and transitions? A rigid, imposed workflow is the single most common reason implementations get abandoned after three months.
• Can I run different processes for different case types? A warranty claim, a consumer return and an out-of-warranty repair are three distinct paths — forcing them into one process ends in fields marked "not applicable".
• Are the form fields configurable? Serial number, purchase date, invoice number — every industry has its own set.
• Does the system watch deadlines on its own? This is the single most important feature. A system that knows nothing about SLA or escalation is a prettier spreadsheet.
• Does it integrate with the couriers and mailboxes you already use?
• Is there an audit trail? A full change history — who, when, what — matters not only for accountability but for GDPR obligations too.

If you want to see how these requirements play out in practice, we went deeper into them in What Is an RMA System and How Does an RMA Number Work.

In Reklamator everything hangs off the ticket type. Each type has its own process, its own set of fields, its own numbering format (for example `RKL/{year}/{seq}`, with optional automatic counter resets), its own form and its own rules. That way a warranty claim and a consumer return can run side by side without getting in each other's way.

Step 3. Open a proper intake channel — a form, not an inbox

Automation begins the moment data enters the system in a structured form. A complaint sent by e-mail is a block of text somebody has to read and retype. A complaint submitted through a form is a ready-made record with populated fields — and rules can start working on it immediately.

Design the form to collect the minimum data needed to make a decision, not everything you can think of. Every extra field lowers your completion rate. In practice these are usually enough: contact details, order or proof-of-purchase number, product identification, a description of the problem, the desired resolution, and the option to attach photos.

Three things that are easy to forget:

1. The GDPR privacy notice. The form collects personal data — sometimes a bank account number for refunds. The notice has to be there, and if you require acknowledgement, it must be a deliberate tick, not a pre-checked box.
2. Field validation. Enforcing an order-number format or a valid e-mail address on the way in saves hours of clarification on the way out.
3. A confirmation for the customer. A "thank you" screen isn't enough — the customer wants a case number in their inbox. That's a job for a rule from step 4.

In Reklamator this is what remote forms are for — public forms accessible without login, shareable by link or embeddable on your own site as a widget. Fields are defined globally in application fields and then assigned to the form, where you can override labels and validations. Separate settings cover the GDPR notice and terms of service, each with a "required to tick" option.

If some complaints still arrive by e-mail — and they usually do — don't fight it. Connect a mailbox: the system fetches messages, matches them to existing cases by the number in the subject line, and can turn unmatched messages into new tickets of the right type.

Step 4. Configure business rules — the heart of the automation

This is where the map from step 1 becomes a working mechanism. A business rule always has the same shape:

triggering event → conditions (required and/or optional) → actions

The event can be ticket creation, modification, a stage change, assignment to a user, or an incoming e-mail being attached to a case. Conditions narrow the rule down to specific tickets — by stage, status, customer, product, source, or the value of any field. They come in two kinds: required conditions must all hold at once (a logical AND), while with optional ones a single match is enough (a logical OR). Both kinds can be combined within one rule. Actions include: sending an e-mail (optionally with a PDF attachment), sending an SMS, assigning the ticket to a user, assigning a customer, distributor or service point, and shifting the received date.

Start with the three rules that give the most for the least effort:

• Receipt confirmation. Event: ticket created. Action: an e-mail to the customer with the case number and a link to the status page. This one rule eliminates most of the "did you get my complaint?" phone calls.
• Stage change notification. Event: stage changed. Condition: stage equals, say, Decision. Action: an e-mail or SMS with the outcome.
• Case assignment. Event: ticket created. Condition: product category. Action: assign to the right specialist. The ticket no longer waits for somebody to pick it up.

Keep message content in templates, not in the rules themselves. A template can be multilingual and uses keywords that are substituted automatically with ticket data — that's how you insert a link to the public status page, a QR code leading to it, or a barcode carrying the case number, handy when the return shipment reaches the warehouse. The template editor itself lists the keywords available. PDF templates let you generate a report or confirmation and attach it to the message.

Deadlines and escalations work separately from rules and are configured at ticket-type level: the number of days allowed for resolution, the "approaching deadline" threshold, the highlight colours for overdue cases in the list, and the escalation message template. This is the mechanism that stops you from learning about a missed deadline from the customer.

A practical piece of advice: switch rules on one at a time and watch the effect for a week. Five rules launched on the same day can send a customer four e-mails within an hour, and then it's hard to work out which one was at fault. Every rule can be deactivated with a toggle anyway, without deleting its configuration.

The full list of events, conditions and actions is in the business rules documentation.

Step 5. Connect your couriers — no more retyping addresses

Reverse logistics is where automation delivers the most measurable time saving. Issuing a label by hand means copying the address from your system into the courier's panel, downloading a PDF and mailing it back to the customer. That's three to five minutes per ticket and at least one place to get the house number wrong.

Once integrated, the shipment is created straight from the ticket: address data is filled in from the case, the label is ready to download and print, and the tracking number lands in the Shipments section of the ticket. Sending the label to the customer can itself be an action of a business rule from step 4.

Reklamator supports DHL, DPD, GLS, Geodis and UPS. Each module is configured separately — courier account credentials, a default sender address, and a test mode worth running your first few shipments through before switching to production. If most of your parcels are similar in size, define parcel templates: weight and dimensions then become one click instead of a fresh entry every time.

It's good practice to couple this step with the workflow: a ticket moving into the Awaiting goods stage is the natural moment to generate a return label and send it to the customer.

Step 6. Monitor and refine — automation is a process, not a project

The implementation ends on go-live day. The automation does not. A configuration that worked beautifully at thirty tickets a month will expose bottlenecks nobody thought about at three hundred.

Four metrics worth watching from the first week:

• Time to first response — how long from a ticket arriving to the first real contact with the customer.
• Resolution time — from submission to closing the case, broken down by type and category.
• Overdue and escalated cases — if the number is rising, the culprit is usually one specific stage, not "the team being slow".
• Distribution of complaint causes — the most valuable data in the whole system, because it tells you not about complaint handling but about what generates complaints in the first place.

In Reklamator the day-to-day picture comes from the dashboard widgets: tickets by stage, status and category, the trend of created versus closed tickets over time, and a calendar of deadlines. Deeper analysis is what the reports module is for, and its columns are built from the same application fields you used on the form.

A rhythm that works well for our customers: once a month, review the cases that missed their deadline and ask a single question — which stage did they get stuck in? Nine times out of ten the answer points either to a missing notification rule or to a stage where the decision rests with someone who has too many other responsibilities. The first takes five minutes to fix; the second takes a conversation — but at least you know what the conversation is about.

FAQ

Where should I start when automating complaint handling?

With a process map, not with picking a tool. List the stages a ticket goes through, name the person responsible for each one, and mark which transitions are mechanical (confirmations, notifications, deadline reminders). Only that list tells you what is genuinely worth automating — and lets you judge whether a given system can do it at all.

How long does it take to implement complaint automation?

A basic setup — one ticket type, a form, two or three notification rules — is usually a day's work. A full rollout covering several processes, courier integrations and document templates spreads over two to six weeks, and most of that time goes not into configuration but into internal agreement about the process itself.

Does automation mean the customer stops talking to a human?

No. Automation takes over the repetitive parts — issuing a number, confirming receipt, announcing a status change, reminding about a deadline. The substantive decision on whether a complaint is upheld stays with a person. In practice, automation increases customer contact, because information goes out on schedule rather than whenever somebody remembers.

What's the difference between business rules and a workflow?

A workflow defines the path: which stages exist and how you can move between them. Business rules define the reactions: what the system should do when a given event occurs — for example when a ticket enters a particular stage. The workflow is the skeleton, the rules are the reflexes. Without a workflow, rules have nothing to attach to.

Can I automate complaint handling without changing systems, using e-mail and a spreadsheet?

To a limited degree, yes — reply templates, inbox filters, spreadsheet formulas. What you cannot automate is deadline tracking, nor can you guarantee a coherent case history, because a spreadsheet has no notion of an event and notifies nobody about anything. The limit usually appears as soon as more than one person handles complaints.

Can automated notifications do harm?

They can, if there are too many. A customer who receives seven e-mails about a single complaint stops reading them — including the one that mattered. That's why rules are best switched on one at a time and checked, and why notifications should be limited to moments when something genuinely changes for the customer: receipt of the complaint, a request for more information, the decision, and closing the case.

---

Complaint handling automation comes down to one principle: the system should remember, on your behalf, the things people forget under pressure — the deadline, the message to the customer, who is supposed to pick the case up. If you'd like to walk through these six steps in practice, create a free trial account and start with account registration in the documentation — you can take your first ticket through the entire process in about fifteen minutes.