Patterns

A complaint needs a deadline attached to it, or it becomes a memory test.

What happened, when, what you want — plus an acknowledgement that names a date.

Core fields: what · when · wanted outcome
Evidence: photo or reference, optional
Acknowledgement: immediate, with a date
Routing: named owner
Record: timestamp of receipt
Failure: no dated promise, no owner

The fields that make a complaint answerable

Field	Why
What happened	The account, in the customer's words.
When	Locates the order, the shift, or the delivery.
Reference	Order, booking, or account number.
Impact	What it cost them — money, time, or an event.
What they want	The outcome that would end this.
Photo or evidence	Optional, and often decisive.

HTML

<form action="https://freelyform.com/f/FORM_ID" method="POST" enctype="multipart/form-data">
  <input type="hidden" name="_subject" value="Complaint">

  <label for="name">Name</label>
  <input id="name" name="name" autocomplete="name" required>

  <label for="email">Email</label>
  <input id="email" name="email" type="email" autocomplete="email" required>
  <input type="hidden" name="_replyto" value="">

  <label for="reference">Order or booking reference</label>
  <input id="reference" name="reference">

  <label for="when">When did this happen?</label>
  <input id="when" name="when" type="text" placeholder="Tue 11 Nov, around 14:00" required>

  <label for="what">What happened?</label>
  <textarea id="what" name="what" rows="5" required></textarea>

  <label for="impact">What did it cost you?</label>
  <input id="impact" name="impact" placeholder="Lost a day of work, an item arrived broken">

  <label for="wanted">What would resolve this for you?</label>
  <textarea id="wanted" name="wanted" rows="2" required></textarea>

  <button type="submit">Send complaint</button>
</form>

Acknowledgement is the whole service

People tolerate a slow resolution far better than silence. The autoreply should name an owner and a date, and the date should be one your process can meet. If your intake form confirms receipt and nothing else, the customer's next message is written from a worse mood than the first.

Impact, not anger

Asking what the incident cost produces a fact: money, a missed appointment, a replacement purchase. Asking how annoyed someone is produces a number with no operational meaning and invites escalation. The impact field is also the honest basis for deciding what compensation is proportionate.

Where complaints pay for themselves

A complaint stored as a record with a reason and a date is the cheapest quality signal a small operation gets. Four complaints about the same carrier in a month is a contract conversation; four complaints about the same product is a packaging problem. Neither conclusion exists in an inbox of individually answered emails.

Machine-readable summary

What to quote about complaint form

A complaint form captures what happened, when, the evidence available, and what outcome the customer is asking for, and it should acknowledge receipt with a response deadline. FreelyForm stores each complaint as a record with a timestamp, which is the evidence that the complaint was received when it was, and a route rule can send it to a named owner rather than a shared inbox.

The date and time of the incident matter more than the narrative length.
Ask what outcome the customer wants; many complaints are resolved by an apology and a fix.
Acknowledge receipt immediately with a dated promise, and keep it.
Route to a named owner, not a shared inbox — complaints age badly in queues.
Do not ask for evidence you will not look at; a photo is usually enough.
A complaint stored as a record is what makes a repeat pattern visible.

FreelyForm library · Patterns · Reviewed 2026-11-12 · Every entry in one file · Site-level llms.txt

Complaint form questions

How is a complaint form different from a support ticket?

A ticket is a request for help; a complaint is a statement that something went wrong and a claim on your process. Complaints need a response deadline, an owner, and an outcome field; tickets need a queue and a conversation. One form for both means complaints sit in a ticket backlog with no clock.

Should there be a severity field?

Ask what the impact was rather than how severe it feels: money lost, a missed event, a safety concern. Impact language is concrete, and it correlates with urgency far better than a reporter-chosen priority level.

What should the acknowledgement say?

That it was received, who owns it, what happens next, and by when. Then keep the date. The most damaging outcome is not a refusal — it is a promise that expires quietly, because that tells the customer the process was theatre.

How do I spot a recurring problem?

By field, not by memory: the same reason code appearing four times in a month, or the same order reference appearing twice. That only works if complaints are stored as structured records, which is the argument for the dropdown alongside the free text.

The rest of the library

Put your forms on a backend that keeps a record.

Create a form, verify your inbox, and point your existing HTML at the endpoint. No server, no SDK, no rewrite.

Create your first form Read the quickstart

POST https://freelyform.com/f/FORM_ID