Create complaint form — respond in a structured way

Complaints arriving by email are rarely complete. Order numbers, dates or a concrete desired solution are missing — and answering starts with a clarifying question. A structured complaint form turns this around. You define from the start which fields you need to process: order number or contract reference, date of the incident, description of the situation, desired solution and an optional file upload for photos, screenshots or documents as evidence.

The advantage is twofold. First, completeness of the initial report increases significantly because required fields prevent missing details. Second, routing becomes more reliable: with structured fields you can automatically decide which team picks up a complaint — shipping, product, support or accounting. An email lands in the general inbox and is often forwarded several times before reaching the right handler. The form shortens this path to a single step and measurably reduces average processing time.

A sensible categorisation rests on three axes. The first is severity: is it a regular complaint, constructive feedback or an emergency, such as a security incident or a legally relevant matter. The second axis is the area: shipping, product, support or billing. The third axis is the priority derived from severity and area — critical, normal or low. These three values are best stored as hidden fields or calculated values in the record.

With conditional logic the form branches by selection. Whoever picks „shipping“ gets fields for tracking number and delivery date. Whoever picks „product“ sees fields for model, batch and defect description. The form stays short for each path while covering all cases. Routing is implemented downstream via webhook — emergencies go directly to executive management, normal shipping complaints to the logistics team, billing topics to accounting. That saves manual triage and ensures no report slips through.

Complaint data is particularly sensitive because it often contains personal circumstances and occasionally health or financial information. Data minimisation is therefore especially important: only ask for what is necessary to clarify the specific case. A date-of-birth field belongs in a complaint only when age is legally relevant — otherwise it is dispensable. Optional fields should be clearly marked as optional so customers consciously decide what to share.

Retention duration depends on the purpose. For warranty complaints in Germany, a period of typically three years applies, with longer warranties extending accordingly. After expiry, data is deleted or anonymised, while statistics on complaint reasons may still be kept. The data subject right of access applies at any time — they may request a copy of their complaint. Maintain a separate record of processing activities for complaints that documents categories, purposes, recipients in the routing and deletion deadlines cleanly. In audits, this separation is gold.

An incoming complaint should not stall in the form tool but move into the existing ticket system. Via webhook the submission can be handed to Zendesk, Freshdesk, Jira Service Management or a custom help desk — including category, priority and all structured fields. A ticket with correct routing is created directly, without anyone manually transferring data. Define a clear SLA model: for example 24 hours for first response, five working days for final resolution in standard cases.

Communicate every status change to the customer — received, in progress, resolved or rejected with reason. A short email at every transition significantly reduces follow-up questions because the customer knows the status at any time. For severity „critical“ an escalation rule applies: the ticket goes in parallel to executive management or an on-call lead with shortened response time. Record every step in the activity log — who performed which action when. This transparency helps internally during reviews and externally in legal matters.