Build a warranty claims app by describing it.
Which claims are open, who is on each one, and how long the customer has been waiting. Here's the prompt and the app it produced.
Ask for it in one go
This is the exact prompt we used. Copy it, change the words that don't match your business, and paste it in.
Track warranty and repair claims. A customer raises a claim against a product with a serial number, describing the fault, and we record the purchase date and whether it is in warranty. A claim goes from received to assessed to repaired or replaced or refused, and a technician is assigned to each one. Only a service manager can refuse a claim. Show me open claims and how long each has been waiting.
Built in 68 seconds, from that prompt alone.
What came back
Five collections, including notes
Claims, Claim Notes, Customers, Products and Technicians. Notes being their own collection means the history of a repair is a thread rather than one field that people overwrite.
A five-state outcome
Received, assessed, repaired, replaced, refused. Most tools would have made that a three-state workflow. Repaired and replaced are genuinely different outcomes and your warranty costs depend on the split.
Days waiting, front and centre
Open claims are listed by how long they have been sitting. A claim count tells you volume, ageing tells you which customer is about to phone and complain.
A repair claim is a promise with a clock on it. Somebody’s machine is broken, they have told you, and every day after that the goodwill drops. The thing that damages a service business is rarely refusing a claim. It is the claim nobody looked at for three weeks.
So the app is a register with an ageing column. What is open, who has it, and how long the customer has been waiting.
It did not flatten the outcomes
We listed repaired, replaced and refused as separate ends. Plenty of systems would collapse those into “closed” with a note. This kept all five states, and that matters commercially: replacing a unit costs you a unit, repairing costs you an hour, and refusing costs you a customer. A dashboard that cannot tell them apart cannot tell you which products are expensive.
It also made Claim Notes a collection rather than a text field, so a claim carries a thread. Anyone picking it up mid-repair can see what has already been tried, instead of one box that the last person overwrote.
Days waiting, not claim count
The prompt asked how long each claim had been waiting, and that phrasing produced the right screen. Open claims are ordered by age rather than by date raised, so the oldest thing sits at the top where somebody will see it.
It is a small difference in wording with a large difference in outcome. “Show me open claims” gets you a list. “Show me how long each has been waiting” gets you a queue that shames you into working it, which is the point.
Summary
A warranty claims app is a register, a five-state outcome and a clock, and the clock is the part that changes behaviour. This one took 68 seconds from a paragraph, kept notes as a proper thread, and preserved the difference between repaired, replaced and refused. Nothing needed correcting. If you want repair costs, per-technician views or photos of the fault, those are the next three sentences.
Then change it by asking
The assistant stays with the app after it is built. It proposes each change and a person approves it, so nothing moves on its own.
- Add the repair cost to each claim and total it by product.
- Let technicians see only the claims assigned to them.
- Add a photo of the fault to each claim.
- Give me the refusal rate by product for the last year.
Frequently asked.
Does it work out whether a claim is in warranty?
It records it, because that is what the prompt asked for. Deriving it from the purchase date and a warranty period is a further step you would ask for, and worth doing, because leaving it to a human is how claims get honoured that should not have been.
Why is refusing a claim restricted?
Because it is the decision with money and a customer relationship attached. Anyone can assess, only a service manager can refuse, which is one clause in the prompt and the kind of control that is usually a policy nobody enforces.
Can customers see the status of their claim?
Not from this prompt. This is an internal register for the service team. Customer-facing status would mean external access, which is a bigger decision than it sounds and worth thinking through separately.
How is this different from customer complaints?
A complaint is about something that went wrong and needs resolving. A claim is about a specific product, under a warranty, with a repair or replacement at the end. The shapes rhyme, and the vocabulary and the outcomes are different enough to be separate apps.
What does it cost?
Snill is free to start for solo operators, with a Pro plan for teams. Your data and the app's full model are yours to export at any time, as CSV or JSON.
Describe it and see
Free to start. The app is generated in about a minute, and you keep changing it in plain language.
Start free