28 July 2026
A dedicated complaint system or a module in your ERP? Six questions that settle it

Companies running an ERP almost always have some form of complaint handling inside it. A complaint document, a status, a link to the invoice, sometimes a credit note. Given that it is already there, the natural question is: why a second system?
It is a good question and there is no single answer. Sometimes the ERP module is entirely sufficient and adding another tool would waste both money and someone's time. Sometimes a company spends three years trying to fit something into a module it was never designed for.
Below are six questions that settle it — no guesswork, no list of advantages.
A complaint module in an ERP is built around the document: the order, the invoice, the credit note. Its job is to close the case for accounting and inventory. A dedicated system for complaints and service is built around the process: who does what, when, and against which deadline, before the case can be closed.
When the ERP module genuinely is enough
Let us start from this side, because it is the most common case and the one least often discussed.
If, in your company, a complaint means in practice: the customer returns the goods, the warehouse receives them, accounting issues a credit note, case closed — the ERP module is the right tool. It does exactly what it was designed to do, your data does not drift between systems, and you are not paying a second subscription.
This typically applies to retail, distribution and e-commerce with consumer returns. The case is short, there are two participants, and the outcome is a document.
In that situation, looking for a separate system is solving a problem you do not have.
When the module stops being enough
Things change when a case ends in a repair rather than a return.
Between intake and closure a dozen things happen that a document does not describe: inspection, diagnosis, quotation, the decision to accept the claim, ordering parts, a technician visit, a second visit, a report. Each one has an owner and a deadline.
This is not a question of how many fields the form has. It is a different unit at the centre of everything: not the order, but the device.
Six questions
1. Does someone have to do something physical between intake and closure?
If so — inspect, diagnose, repair, replace a part, travel to the customer — you have a process, not a transaction. Processes have stages, stages have owners, and owners have deadlines. An ERP document has nowhere to record that, other than a free-text "notes" field.
2. Do you need the history of the device, not the history of the order?
This question settles the most. When a customer calls for the third time about the same pump, the question is "what have we already done to it", not "which invoice was it on".
The ERP knows the document number. To know the history of an individual unit — serial number, previous repairs, parts replaced, who attended last — you need a device record, not a sales record.
3. Do you have more than one kind of case?
A consumer complaint, a distributor claim, a service order, a scheduled inspection, an out-of-warranty repair — that is five different processes. Different deadlines, different people, different documents at the end.
An ERP module usually gives you one scheme and a list of statuses to choose from. You can handle everything in it, but everything looks the same, and the differences end up in people's heads. That works right up until someone leaves the company.
4. Is the deadline attached to the case, or to the stage?
Most modules can show how many days a case has been open. Far fewer can answer where it got stuck.
The difference is practical: "case open 19 days" tells you nothing, "waiting for a part for 11 days against a 7-day limit" tells you everything — and lets you act before the customer calls. That requires a deadline tracked on every stage and escalation once it is exceeded, not a single counter on the whole case.
5. Who is supposed to see the case?
A field technician, a subcontractor, a distributor, the end customer. A service process usually has more than two participants, and not all of them may see the same thing.
ERP access is granted rarely and reluctantly — and rightly so, because it holds purchase prices, margins and financial data. That is often a real constraint: not because the module cannot be configured, but because nobody will give a field technician an account in the accounting system.
6. How many times in the past year did someone ask "what stage is this at" and the answer required a phone call?
This is the control question. If the answer is "once a quarter", your process is in good order and you do not need anything else. If it is "every Monday", the state of your cases does not live in a system — it lives in people.
The third path, worth knowing about
This is not an either–or choice. The arrangement most often seen in companies with substantial service operations looks like this: the ERP remains the financial and inventory system, while the case-handling process runs alongside it, exchanging data at the key moments — on intake, on parts issue, on document creation.
Nobody migrates their accounting. The point is to give the process somewhere to run, while documents keep being created where they are created today.
What each mistake costs
A separate system when the module would do: a second subscription, an implementation, two places to check, data in two systems. A real cost, but a reversible one — after a year you go back to the module.
The module when you needed a process: deadlines tracked in a spreadsheet on the side, device history in a technician's head, no trail when a case is disputed. A cost that is spread out and invisible, because it appears on no invoice — until a complaint goes to court, or the person who "knew everything" leaves.
Summary
| Situation | The right tool |
|---|---|
| Return, credit note, case closed in days | ERP module |
| Repair, parts, technician visit | Dedicated system |
| One case type, two participants | ERP module |
| Several case types, different deadlines | Dedicated system |
| The document is what matters | ERP module |
| The device history is what matters | Dedicated system |
If this list points you to the ERP module — stay with it. Genuinely.
If it points somewhere else, see what a service process with a deadline on every stage looks like. The largest process running for one of our customers today has 138 stages — but it starts at five, and that is usually enough to begin with.
Reklamator
See where the module ends and the process begins
Book a 20-minute demo — we will run the system on a process close to yours and tell you plainly what it will not do. If it turns out the ERP module is enough for you, you will hear that too.
Start for free