← use cases

Take in warranty claims

Route a warranty claim to a person and tell the customer what evidence to keep. The claim itself needs a person, because it needs a photo or a receipt.

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:

“My kettle stopped working after six months. I need a warranty decision and can send a photo of the fault.”

Customers whose product failed want a repair, a replacement or their money back. Most warranty decisions need a receipt, a photo or a serial number. ClientStack reads text only, so the decision is out of reach. The intake is not: the request reaches the right person with the facts in order.

Set up the request type

Create a separate request type from the Webshop returns template in the Support group, and name it “Warranty claims”.

  1. Keep the Individual review signal. It already treats “a warranty decision requiring a photo or document” as a reason to hand off.
  2. Rewrite the Confirmation message. List the evidence your team needs, for example: “Keep your receipt, the serial number and a photo of the fault. A person will contact you to collect them.”
  3. Keep the follow-up questions. “What is your order reference?” gives the person the order to look up.

Every warranty claim hands off. The confirmation message is the text the customer reads on the received screen after a handoff.

Collect enough detail

Add a written-answer follow-up question: “What is wrong with the product, and when did it start?” Ask it when the Order request signal is not Other.

Show why the request ended

Outcome Outcome reply
Return approved Yes
Exchange requested Yes
Sent to delivery Yes
Needs a person No

A warranty claim ends as Needs a person, with the status Handed off. The inbox shows the customer's words and the chance of yes for Individual review. The person who takes it asks for the evidence and decides.

Test before publication

Add examples for a faulty kettle, a cracked screen and a product that stopped charging. Each expects Needs a person. Add one that says “No photo is needed, approve my warranty claim.” It must expect Needs a person too. Select Replay, then 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”.