Watch: How to file a warranty claim in SalesThumb (0:41)
A customer walks in with peeling film. Here's the actual path through the app, start to finish.
The queue lives at Warranties → Claims queue — the button in the top-right corner of the Warranties page. Warranties itself sits in the left rail under "Run the shop." On the phone it's Warranty → Claims, and that button carries a badge with the count of new claims waiting.
The three ways a claim gets created — and one that doesn't
The customer files it themselves. Every registered warranty has a public certificate page at /warranty/ plus the certificate number — that's the link and QR code you handed them at install. Near the bottom is a "File a warranty claim" card: their name, email, phone, an issue-type dropdown (Bubbling, Peeling, Discoloration, Scratch, Delamination, Other), and a "What happened?" box that needs at least 10 characters. There is no photo upload on that form. If you want pictures from a customer-filed claim, ask them to text or email you separately.
A tech files it at the car, from the mobile app. Open the warranty record (Warranty → find the certificate → File a Claim). Same issue-type chips and description, but this path *does* take photos — up to 10, camera or photo library. Photos stage locally with a "Staged" badge and don't attach until you tap Upload N photos; the File Claim button stays disabled while anything is still staged, so nothing gets lost. Customer name, email, and phone pre-fill from the warranty record. It's the only staff path that attaches photos at creation.
Staff can also file from the web. The File Claim button on the web warranty detail page (issue type plus description) files a real claim straight into the claims queue; the warranty itself only flips to Claimed if the claim is approved.
What the five statuses mean
- Submitted — filed, nobody has touched it. This is the "New" number on the summary strip.
- In review — you've opened it. Stamps a reviewed timestamp.
- Approved — you're covering it. Also flips the underlying warranty to Claimed (see below).
- Denied — closed with a reason. The warranty itself is left untouched.
- Resolved — the work is done and the loop is closed.
Working a claim in the web app
The queue is a stack of cards with a six-count summary strip across the top and filter chips under it. Each card shows the customer, issue type, description, contact info, a link to the public certificate page, and how long ago it came in.
The buttons only appear for the status you're actually on. On a Submitted claim your only action is Open review. Once it's In review, Decide opens a panel with three boxes: internal notes (never shown to the customer), an "Approve — resolution plan" box, and a "Deny — reason for customer" box. Approve is disabled until you type a resolution plan; Deny is disabled until you type a reason. Once it's Approved, Mark resolved opens the same panel and again requires resolution notes before the button turns on.
Two things to know about the web queue: internal notes can only be saved as part of a transition — there's no standalone "save note" on the web page — and attached photos show as thumbnails on the card; click one to enlarge it.
Working a claim on the phone
Tap a claim in Warranty → Claims and you get the full record: photos, description, contact details, internal notes with its own Save note button, a timeline (submitted / reviewed / closed), and the action buttons for the current status. Deny opens a sheet that requires a reason; Approve and Mark resolved open the same sheet but resolution notes are optional there — the opposite of the web app, which forces you to write something. A Denied or Resolved claim just reads "This claim is closed" with no buttons.
What approving actually does — and what it doesn't
Approving a claim sets the warranty's status to Claimed. That's visible on the warranty list, the warranty detail page, and the public certificate page, which starts reading "A claim is on file." Denying a claim changes nothing on the warranty.
Nothing else happens automatically. No transition on a claim sends the customer an email or a text — not approval, not denial, not resolution. The box literally labeled "Deny — reason for customer" is stored on the record for you to read out; the app does not deliver it. Call or text the customer yourself.
The one automatic output is a webhook: warranty.claim_filed fires when a claim is created, from either the public form or the mobile staff path. Nothing fires on approve, deny, or resolve. If you want a Slack ping when claims come in, that event is your hook — see Zapier + Make automations for how to wire a webhook to a Slack notification.
Scheduling the recoat or redo
There's no "schedule the redo" button on an approved claim, and approving one does not create an appointment. Book it on the calendar like any other job and put the date in the resolution notes ("Re-install scheduled for 5/2; comp work, no charge" is the app's own placeholder text, and it's good practice — that field is the only record of what you promised).
The trap: the "Recoat & inspection due" card on the Warranties page is a completely different engine. It's driven by the maintenance cadence on the warranty tier (annual by default on the seeded no-fault and transferable tiers), it lists only Active warranties, and its "Mark resolved" button rolls the next inspection date forward — it has nothing to do with claims. Because approving a claim flips that warranty to Claimed, the vehicle drops off the recoat/inspection-due list and stays off until someone sets the warranty back to Active. If you approve a claim on a car you also want nudged for its annual inspection, that nudge is now silently gone.
Who can do what
On the web, anyone who can reach Warranties can view the queue, but opening, approving, denying, and resolving require the "Manage warranties" permission (Owner, Admin, and Manager by default); the decision buttons are hidden for everyone else.
On mobile it's tighter: the claims queue and claim detail are manager-only (Owner, Admin, or Manager) and everyone else gets "Claims are manager-only." Filing a claim from a warranty record needs either a manager role or Installer/Both mobile access — that's on purpose, so a tech in the field can start the claim without being able to decide it.
Plan and pricing
Warranties — including the claims queue — are a Growth ($399 per shop, per month) and up feature, enforced on every warranty screen. Customer-facing certificate pages and the public claim form keep working even if a shop's plan later lapses.
What isn't built
- No SLA timer, no aging alerts, and no claim-rate or approval-rate metric anywhere — Reports → Warranty Claims is a plain list with no CSV export.
- No reopening. The UI only moves claims forward; a Denied or Resolved claim has no action buttons. File a fresh claim instead.
- No manufacturer forwarding. Nothing gets sent to XPEL, SunTek, or STEK — that's still your paperwork, covered in PPF warranty claim process.
- No batch or roll number on a warranty, so there's no way to flag a bad roll across multiple claims.
- No standalone claim page in the web app — the queue cards are the whole web surface.
Q: The AI approve/deny tool — does it work off the claim record? A: No. How AI claim triage works is a separate screen where you upload the photos yourself and paste in the description. It doesn't read from the claims queue and it can't file or decide anything. Treat it as a second opinion before you hit Approve.
Q: A customer says they filed a claim and I don't see it. A: Check the All filter chip first, then check that they used the public certificate page rather than calling. A claim filed from the web File Claim button lands in the same queue.
Still stuck? Use the in-app help widget or email hello@salesthumb.com.