Claims Workflow
How claims move through Claim Core from submission to resolution.
Claim lifecycle
A claim can be raised by a brand in its portal, by a shopper on the brand's claims page, by your team, or through the developer interface. Whoever raised it, it follows the same status flow. Transitions are logged in the audit trail and trigger email notifications to the brand.
The claim has been raised. Whoever is deciding it is notified and the first-response clock starts.
Your team is investigating. Warehouse evidence is surfaced and internal notes can be added.
You have asked the brand for something. The decision clock pauses while you wait on them.
You have upheld the claim and recorded what was granted: a refund (with an optional amount for the record), a replacement, or something you describe. The brand is notified; a shopper who raised the claim is emailed automatically in the brand's name.
Claim declined. The brand is notified with the decision note; a shopper is emailed that it was not approved. A decided claim can then be closed, or reopened.
Raising a claim
On the new-claim form, pick a brand and start typing in the Order reference field. After two characters Claim Core searches both your local order index and the connected WMS in real time, matching on:
- •Order reference (channel/Shopify reference or the WMS internal order number)
- •Customer name
- •Delivery postcode
- •Courier tracking number
A dropdown of matching orders appears; each row shows the reference, customer, postcode, dispatch date, and tracking. Selecting one auto-fills the claim lines from the order's contents - you only need to pick a claim type per line.
Claim lines
Each claim contains one or more lines. A line represents a single item or issue within the claim. Each line has:
- •Claim type: Missing item, Damaged item, Wrong item received, Not received, Late delivery, Quality issue, Packaging damaged, Lost in transit, or Other
- •SKU and description - pre-filled from the WMS when the order is matched
- •Quantity and unit value - used to calculate the total claimed value. Unit value pre-fills from the order's pricing data when available
The claim detail page
Once a claim is created, the detail page surfaces a structured sidebar pulled from the WMS:
- •Order details: reference, WMS internal ID, status, dispatched date
- •Customer: name, company, email, phone - plus a count of other claims from the same customer (matched by email or postcode)
- •Shipping address
- •Tracking & fulfilment: carrier, tracking number, the delivery status the warehouse system reports, picker, packer, dispatcher, and pack-station video where Helm has a recording
- •Prior claims for this order: status badges for any earlier claims on the same order, with links to past decisions
- •Rest of the order: lines on the original order that aren't being claimed - useful context when adjudicating
Missing fields render as N/A rather than disappearing, so the layout stays stable regardless of how much WMS data is available.
Reopening claims
Accepted, rejected or closed claims can be reopened by your team, with a reason the brand sees, if additional information comes to light. The claim returns to Under Review, the earlier granted resolution is cleared, and the shopper is emailed again when the new decision is made.
Who is deciding
Every claim records who is deciding it. Brand claims and team-raised claims are yours. A shopper claim is yours too unless you have routed that brand's shopper claims to the brand first, in which case the brand's admins decide it in their portal and it shows a With brand badge in your list. Any brand user can pass such a claim to you with a reason; from then on it is yours, its SLA clocks restart from the hand-over, and it cannot go back. You keep every power you have today on every claim in your organisation, whoever is deciding it.