IMEI and Warranty Lookup
A shop selling phones and electronics with warranty terms, where a customer returning with a fault produces a faded receipt or nothing at all, and staff decide warranty eligibility by judgement.
The problem
Warranty is an obligation that outlives the sale, and the shop has no searchable record binding a serial number to a sale date, a customer and a set of terms.
In scope
- Serial capture at sale
- Warranty terms per product or sale
- Instant lookup by serial or receipt
- Claim workflow
- Supplier warranty tracking
- Warranty exposure reporting
Out of scope
- Full inventory
- Purchasing
- Point of sale
- Repairs
- This is the smallest concept in the retail set and deliberately so — it does one thing and grows into the Retail & Electronics Operations Platform or sits alongside Repair Workshop Management.
What this would cover
Grouped by module — open the ones you want to read.
Serial capture
- Scan an IMEI or serial with the phone camera at the moment of sale and bind it to the transaction, customer and date
Warranty terms
- Duration and coverage by product, product category, or overridden per sale; exclusions stated
Lookup
- Scan or type a serial and see sale date, customer, warranty status, remaining term, prior claims and prior repairs
Claim
- Raised against the serial, assessed, resolved by repair, replacement or refusal, with the reason recorded and visible on any future lookup
Supplier warranty
- Tracked separately from customer warranty, because a unit sent back to a supplier under their warranty is frequently lost between the two records
Exposure report
- Units under warranty and remaining term, aggregate liability, and claim rate by product and by supplier
Data model
- StockUnit (by serial) → Sale → Customer
- Warranty → WarrantyTerm
- Claim → Resolution
- SupplierWarranty
- Product → Supplier
Invariants
- A serial can be sold once.
- A claim always resolves to an outcome with a reason — an open claim with no resolution is a work item, not a closed record.
- Supplier warranty status and customer warranty status are separate fields and never inferred from each other.
Offline behavior
Lookup works offline against a cached serial list, because the shop must be able to answer a customer during a network outage. Claim creation queues.
Hard trade-offs
The difficult decisions, stated plainly — not trimmed for length.
This system only works for units sold after it is installed, and the backlog is invisible to it.
Every device sold before go-live has no record, so for the first year most customers returning with a fault will still be handled by judgement. There are two honest options: accept the gap and let the record build forward, or backfill from existing sales records, which is only possible where serials were written down. Most shops find they were not. Say this before the sale, because a shop expecting instant coverage will consider the system broken on day one.
The value depends entirely on staff scanning every serial at the point of sale.
The software can make that fast; it cannot make it optional. A shop unwilling to enforce it should not buy this.
End state
What would be true about their day once this is running.
- A customer returning with a device is identified by serial in seconds, with sale date, warranty position and prior claims on screen.
- Warranty decisions are made from a record rather than from memory.
- The shop can see what it owes in outstanding warranty and which supplier's stock generates the claims.
This is a deliberate first step toward Retail & Electronics Operations Platform — its data model is designed as a genuine subset, so growing into it later doesn't mean starting over.
Let's map how your operation actually runs.
One session. We look at what's breaking, and what we'd build around it — whether or not you hire us afterward.
Start the operations review