Complaint management software, built around the deadlines it has to keep

A complaint is a dated obligation before it is a ticket. Whoever regulates you decides when the answer is due, what the record has to hold, and who receives a report about it at the end of the period. Software that models a complaint as a ticket with a status field loses on all three.

This page is for two buyers: a regulated team whose complaint system cannot hold its own deadlines, and a product team building complaint handling into something they sell. Bles Software builds custom software, AI agents and integrations from Israel for clients in the US, the UK, the EU and Israel. We do not sell a complaint product. We build the one your process needs, or fix the one you already own.

Four different products hide behind one phrase

Intake takes a complaint from whatever channel it arrived on and makes one record of it. Case management holds the investigation, the owner, the evidence and the dated obligations around it. Response drafting produces the written reply, in your language and inside your policy. Reporting pushes the result into whatever the regulator, the board or the quality system expects. Most products are strong at one or two of those and thin on the rest, which is how a team ends up running a platform plus a shared mailbox plus a spreadsheet of due dates.

So the useful question is not which complaint management software is best, it is which of the four your process breaks on. Hours lost writing the same reply is a drafting problem. Missed final responses is a clock problem. A return the regulator sends back is a data problem. An investigation nobody can reconstruct a year later is a records problem. Each costs a different amount to fix, and only one of them is a rewrite. The sections below are the constraints any of the four has to satisfy, taken from the rules themselves.

If you make medical devices, the section you are looking for was deleted

Searches for 21 CFR 820.198 still run every month and the section is gone. FDA published the Quality Management System Regulation on 2 February 2024 at 89 FR 7496, and it took effect on 2 February 2026. Part 820 now carries that name, Subparts C through O are reserved, and the standalone complaint file section no longer exists.

The obligation did not weaken, it moved. 820.7 incorporates ISO 13485:2016 by reference, 820.10(a) requires a documented quality management system that complies with it, and complaint handling now lives in Clause 8.2.2 of that standard with 820.35(a) adding record requirements on top. 820.10(b)(3) handles the other direction: for Clause 8.2.3 the manufacturer must notify FDA of complaints that meet the reporting criteria of part 803. Build against that text, not against an article written about the old one.

The record requirements in 820.35(a) read like a schema somebody already wrote for you. For a complaint reportable under part 803, one you decide to investigate, or one you investigated anyway, the record must carry the name of the device, the date it was received, any unique device identifier or universal product code and any other device identification, the name, address and phone number of the complainant, the nature and details of the complaint, any correction or corrective action taken, and any reply to the complainant. Two parts of that catch teams out. The identifier is the device's, not the order's, so a complaint has to resolve to a UDI at intake rather than during the investigation. And 820.35(a) lets you skip an investigation where one has already been done for a similar complaint, but only where the record documents the justification, which makes the similarity decision a stored field rather than something a reviewer remembers.

If the FCA regulates you, the clock starts the day it arrives

DISP 1.6.2R gives a respondent until the end of eight weeks after receipt of a complaint to send either a final response or a written response explaining the delay. Payment services and electronic money complaints run faster: DISP 1.6.2AR sets a final response within 15 business days, and in exceptional circumstances a holding response within 15 business days and a final response within 35 business days. DISP 1.6.1R, in the version effective 1 June 2026, requires the acknowledgement itself to tell the complainant which of those applies, so the system has to know the answer at intake and not at review.

There is a faster path, and it changes the data model. Under DISP 1.5.1R the complaints time limit rules and the complaints forwarding rules do not apply to a complaint resolved by close of business on the third business day following the day it is received, and DISP 1.5.4R then requires a summary resolution communication instead. That is two states, not one, and deciding which state a case is in needs a working business day calendar. Counting calendar days here is a compliance defect, not a rounding error.

The regulator's return is a feature, not a report somebody types up

DISP 1.10.1R requires most firms to give the FCA a complete report on complaints received from eligible complainants twice a year, and DISP 1.10.5R requires it within 30 business days of the end of the reporting period. DISP 1.10A.1R then requires a firm whose return reports 500 or more complaints to publish a summary of that data, by 31 August for a reporting period ending between January and June, or by 28 February of the following year for one ending between July and December, under DISP 1.10A.3R.

One dated change belongs in your plan now. DISP 1.10.4BR, in force from 7 April 2026, ends every firm's reporting period on 31 December 2026, and the report for it is a partial return covering only the period since the previous report. A system that derives its period from the firm's own accounting reference date will build the wrong return for that one cycle unless the override exists before the period closes.

In the US consumer market the record is public

A complaint routed through the Consumer Financial Protection Bureau arrives with its own expectation. Companies generally respond in 15 days, and in some cases tell the consumer the response is in progress and give a final response in 60 days. The complaint is then published, without information that directly identifies the consumer, in the public Consumer Complaint Database.

That makes the consistency of your written answers a public artifact rather than an internal quality metric, which is the strongest practical argument for drafting from policy language held in the system, with an approval step, instead of free text typed by whoever picked the case up.

Where AI helps, and where it must not decide

The useful applications are narrow and real. Classifying an inbound message into the right category and owner. Drafting a first reply from your own policy language and the case record. Flagging that a draft promises redress the policy does not allow, before it is sent rather than after. Reading the open backlog and naming which cases are closest to their deadline this week.

What it must not do is decide the outcome. Whether a complaint is upheld, what redress is offered, whether an investigation can be skipped under 820.35(a), and whether a case counts as resolved for the purposes of DISP 1.5.1R are decisions a person owns and signs. Build the approval step, the authorship record, and the log of what the model suggested against what a human kept. That log is also the only honest way to answer a regulator asking how the answer was produced.

What a first engagement looks like

The honest first question is whether to build at all. An established platform that fits your process is cheaper than anything custom and it stays supported, and we will say so if that is what your requirements describe. Custom earns its cost when the process is genuinely yours: a return in a format no product produces, complaints arriving through your own product, an investigation workflow tied to your quality system, or a complaint feature you intend to sell.

Where a build is right, the first paid step is small and yours whether or not we continue: a written map of the complaint journey as it runs today, the integration surface against the systems that already hold part of the case, the record and clock model for your own rules, and a delivery sequence with the reporting dates in it.