Claims (INR / damaged / missing)

The claims use case covers "my package never came" (INR), "the item arrived damaged" (damage claim), and "an item was missing from the box" (missing-item claim). These are typically paid out in CX as returnless refunds, so when they're false they're a direct dollar-for-dollar loss. Pinch runs a dedicated Claims workflow — separate from Orders and Returns — that combines the claimant's inputs (photos, address, claim amount), carrier signals (proof of delivery), and the identity graph (claim history across the customer's emails and addresses) to decide whether to pay out, deny, or route for human review.

Setup

1. Claims workflow

In Workflows, open the Claims tab (next to Orders and Returns) and click Edit flow. Add Decision blocks on the lanes you want to populate (Allow / Review / Deny). Claims have their own variable set — the ones you'll reference most often:

Variable	What it is
Claim Type	INR, Damage, Missing Item, etc.
Were Photos Provided by Claimant	Yes / No
Num accessible photos provided by Claimant	Count of usable photos the customer uploaded
Claim Address vs Order Shipping Address	Match / Mismatch
Were POD photos provided by Carrier	Yes / No — proof-of-delivery evidence from the carrier
Claim Order Ratio	% of this customer's orders that have become claims
Num Claims per Email	Running claim count on this email
Claim Amount	Dollar value of the claim
Days Between Delivery and Loss Discovered	How long after delivery the customer noticed

A typical Review branch (review-claim) fires when any of the following are true: Claim Type = Damage, Were Photos Provided by Claimant = Yes, Claim Address vs Order Shipping Address = Mismatch, Num accessible photos provided by Claimant ≥ 1, Were POD photos provided by Carrier = Yes, Claim Order Ratio ≥ 0.1, Num Claims per Email ≥ 1, Claim Amount ≥ $100, or Days Between Delivery and Loss Discovered ≤ 5. The default decision for most new accounts is review-claim — safer to route to a human than auto-deny until the model has seen enough of the merchant's data.

Add Deny branches above it for high-confidence abuse (e.g. Num Claims per Email ≥ 3 AND Claim Address vs Order Shipping Address = Mismatch, or Claim Type = INR AND Were POD photos provided by Carrier = Yes). Preview & Save to dry-run before publishing.

2. Playbook to tag Shopify

In Playbooks → + New Playbook, create one playbook per Sub Decision you want enforced downstream:

Playbook	Segment (Sub Decision)	Action chain
Claim Deny	deny-claim (your high-confidence deny label)	Shopify Tag → Customer → Add pinch-deny + Notify on Slack #claims-escalations
Claim Review	review-claim	Shopify Tag → Customer → Add pinch-review
Claim Approve	allow-claim	Shopify Tag → Customer → Add pinch-allow

3. (Optional) Email the claimant

For the Review branch — especially the "we need photos" case — add an Email action to the Playbook using an Email Template sent through your Dixa or Gorgias connection. Typical templates:

• Claim Review — Please upload photos — closes the loop automatically for the Were Photos Provided by Claimant = No branch.
• Claim Policy Change — hard notice when a customer is moved to the deny list because of repeat false claims.

4. Enforcement happens in CX

Because claims are typically processed as returnless refunds in your support tool, not via the RMS portal, the enforcement point is CX:

• pinch-deny customers get blocked in Dixa / Gorgias macros, or routed to a supervisor queue, before any refund macro fires.
• pinch-review claims land in the Review queue so your CX lead can look at the photos, POD, and identity-graph signals before paying out.
• pinch-allow is the quiet default — payouts proceed on the agent's normal workflow.

5. (Optional) Dispute signal back to Pinch

If a denied claim turns into a chargeback, send a /v1/dispute event to Pinch. The outcome (won / lost) feeds the model and sharpens scoring on future claims from the same identity graph. See Send a Dispute.

What you'll see once it's live

• Returnless-refund payout rate on INR and Empty Box claims drops the moment Pinch starts tagging.
• The Review queue filters by Claim Type and Claim Order Ratio so CX can batch-process claim reviews.
• Analytics shows Abuse Impact in dollars for the three claim categories separately.