Warranty claims triaged from photos, serial numbers and receipts before anyone opens them

A hundred and fifty claims a week, each one a small investigation

Picture an e-bike brand selling in Germany, the Netherlands and France, direct through its Shopify store and through about sixty dealers. Three people run the service desk in Freshdesk, and around 150 warranty claims arrive each week, each one an email, a few photos and a line like 'the motor cuts out on hills'.

None can be decided from the email alone. The frame number has to be read off a photo of the bottom bracket, often upside down and muddy, and half the claims need a sharper photo, the receipt or a video before anyone can judge them. The answer arrives days later, sometimes in a new thread, while a battery that 'smelled hot while charging' waits in the same queue as a scratched mudguard.

The fix is a workflow that does the checking before a person opens the claim: AI workflow automation with a vision model for reading, rules in code for anything that commits the brand, and a person for every decision. It never tells a customer no.

Six jobs inside every claim, all done by hand

What the desk does by hand, per claim:

1. Find the photo that shows the frame number, read it, guessing between O and 0 or 8 and B, and try it in the ERP until something matches.
2. Note model year, production date and battery serial, and check the battery lot against the sheet of known issues.
3. Find proof of purchase: the Shopify order, or a dealer receipt, which usually means asking for it.
4. Work out which clock applies: the brand's warranty for that component, the statutory guarantee against the seller, or neither.
5. Guess the fault from the photos, often by asking for another photo or a video.
6. Decide, create the RMA, order the part, arrange a pickup or brief the dealer, and write to the customer in their language.

Each step is reasonable. At 150 claims a week in three languages they are the job, and the decision gets what time is left.

From an email with photos to a claim a person can decide

A model reads and classifies. Code decides coverage by applying the brand's terms and the law as versioned data, and the outcome is a person's call.

Claim 20417: a muddy frame number, a dealer receipt and a motor that cuts out

A Dutch customer, three photos and a receipt. All of this ran before anyone opened the ticket.

Batteries, fires and falls are safety cases before they are warranty claims

Some claims describe a hazard, and for those the warranty question can wait. The claim leaves the warranty queue, the named safety person is paged with the photos and production history, and the customer at once gets a message that person approved in advance: stop using and charging the battery, keep it away from anything flammable, expect a call today.

The EU General Product Safety Regulation requires manufacturers to notify accidents caused by their products through the Safety Business Gateway, without undue delay, to the authorities of the country where the accident happened. Whether a claim describes one is a judgement, so the workflow's job is getting it to the right person within minutes. For products outside the EU's harmonized rules, such as most furniture, the regulation also requires manufacturers to investigate safety complaints and keep an internal register of them, which flagged claims feed directly.

Batteries also change the RMA. A damaged or defective lithium-ion battery is dangerous goods in transport and cannot go in an ordinary parcel on a standard label, so battery claims never get an automatic one. After approval they become a swap at a dealer that takes old batteries back, or a collection by a carrier that handles damaged ones.

Three markets, three sets of legal clocks

The statutory guarantee is owed by whoever sold the product: for dealer sales, the dealer. The rules compute it on every claim anyway, because the EU Sale of Goods Directive makes every commercial warranty statement say the buyer's legal remedies are unaffected, and 'your warranty has expired' on its own ignores them. As of September 2026:

Claims that break a naive intake pipeline

Is a claim form and a returns app enough?

For a handful of claims a week, often yes. A Freshdesk or Zendesk form with required fields for serial, receipt and photos, plus macros for the usual outcomes, removes most of the back and forth. Returns apps such as Loop and ReturnGO handle the portal, labels and exchanges well, and ReturnGO sells a warranty module too. If your terms are one rule and every unit sells through your own store, start there rather than with a build.

A custom workflow earns its cost when eligibility depends on data those tools cannot see: serials, production dates and component lots in NetSuite or Business Central, dealer sales proven by photographed receipts, statutory rules that differ by country, and battery claims that need a safety path. It also wins when claims arrive as free-form email in three languages rather than through a form.

At the other end, enterprise warranty platforms such as Tavant's suit large manufacturers whose dealer networks file claims and whose suppliers are charged back at scale; for a desk of three that is a long implementation. The build I would do keeps the helpdesk as the workspace and the ERP as the record, and adds the reading and the rules between them, with a review screen built on human in the loop patterns and every extraction under a strict schema, as in structured outputs.

How you would know it is working

A blueprint has no results to report, so here is what I would measure from the first week instead, on your own data.

Time to a complete claim

Hours from the first message until serial, proof of purchase and photos are all present. Most of the waiting was here, so measure it before the build.

Requests per claim

How many times a customer is asked for something. One precise request should replace two or three vague ones.

Proposed outcome accepted

How often the agent's decision matches the packet's proposal, per defect type. Each disagreement is reviewed weekly and becomes a test case.

Serial read accuracy

Readings the ERP confirmed against those a person corrected, split by photo quality, which also shows where the form's photo guidance needs work.

Minutes from safety flag to a person

Every flag, true or false. False alarms are fine; a missed safety case is reviewed like an incident.

What a build like this costs

This is built as AI Workflow Automation, which runs $3.5K - $60K overall. A build like this one usually lands in the multi-step workflow tier: $15K - $30K, 3-5 weeks. The first working version runs on your real data well before the end of that window.

What it costs to run

A few vision and text model calls per claim, usually cents rather than euros, more when a customer sends ten photos. Reverse image search is billed per image. The rest is hosting and the helpdesk and ERP quotas you already pay for.

What moves the price

• Where serial data lives, and whether the ERP exposes it through SuiteQL, an API page or only exports
• Sales channels: direct only, or dealers and marketplaces whose receipts must be read and matched
• How many countries and product lines, each with its own warranty terms per component
• Whether approved claims book pickups and dangerous-goods shipments, or hand the job to dealers

Who this is for

• E-bike, appliance and furniture brands with a small service desk handling claims from several EU countries
• Manufacturers selling direct on Shopify and through dealers, where proof of purchase arrives as a photographed receipt
• Brands whose warranty eligibility depends on serials, production dates or component lots in the ERP
• Service teams whose first reply to most claims is still a request for a clearer photo

Questions people ask about this