← use cases

Route customer complaints

Send each complaint to the team that owns it, and give serious or repeated complaints to a person first.

The inbox lists requests handed off to a person, each with its reason and judgments. The sample request type is Support triage.
The inbox lists requests handed off to a person, each with its reason and judgments. The sample request type is Support triage.

Product screen with sample data. Intake is the previous working name.

The incoming request

A sample request:

“The person who served me was short with me and talked over me in front of other customers. I left without buying anything.”

Customers with a complaint want to know that someone will read it. Your complaint procedure names a team for each kind of complaint, or it should. Share the Public link where your complaint procedure is published.

Set up the request type

Start from the Complaint handling template in the Support group.

Jev reads the complaint against four signals:

  • Complaint about (pick one): service, billing, conduct, product or other.
  • Seriousness (scale): Minor, Significant or Serious.
  • Escalated (yes or no): does the complaint mention harm, safety, discrimination, a regulator, a lawyer or the press?
  • Repeated complaint (yes or no): has the customer tried to resolve the same complaint before?

Rename the outcomes after the teams in your procedure. If one team handles both service and conduct, point both options at one outcome in Outcome for each answer.

Collect enough detail

  • “When did this happen?” when the complaint is not yet serious.
  • “What would put this right for you?”: An apology, Money back, Fixing what went wrong, or An explanation.
  • “Do you have a reference for it?” for minor complaints.

Show why the request ended

Outcome Outcome reply
Sent to the service team Yes
Sent to billing Yes
Sent to the people team Yes
Sent to the product team Yes
Needs a person No

Serious complaints and repeated complaints hand off. An override sends any complaint that mentions harm, safety, discrimination, a regulator, a lawyer or the press to Needs a person. A person reads these first and decides what happens.

The replies say the complaint was sent for review. They do not promise a refund or an apology. Keep it that way: your team decides the remedy.

Test before publication

The template ships 13 synthetic examples. One threatens a lawyer over an eight-minute queue; it expects Needs a person. Another hides an instruction in fake system text.

Add complaints from your own procedure, including one about a late refund and one about a rude reply. Then add one that mentions an ombudsman. It must expect Needs a person. Select Replay and read every Miss before you select Publish.

Put this into practice. Build your first request type →

Give every request
a clear next step.

Start with one request type. Make it yours.

Find an answer

Try “publish”, “API”, or “human handoff”.