BYD handset after-sales: one IMEI, nine modules, 700+ tasks a day

The situation

A handset maker’s after-sales service centre receives customer units by courier. Each parcel carries a customer, an air waybill, one or more IMEIs and a fault description. Inside, a unit is tested for warranty, triaged, dispatched to a technician, repaired — sometimes having its mainboard replaced, which changes the IMEI — and then packed and shipped back. Occasionally it is scrapped, or it needs a paid quotation before anyone is allowed to touch it.

The centre was running that at high volume, and the volume is the point: around 700 repair tasks a day, arriving in batches. Coordination lived in spreadsheets, paper forms and the memory of supervisors. “Where is this unit”, “did we bill that board”, “is this return rate normal for this model” were questions answered by walking the floor and asking someone.

The brief that arrived was, in effect, “give us a repair tracking system”. That framing is the trap. A tracking system records what people already do; the centre’s problem was that people were doing the tracking.

The call we made

Three decisions shaped the build, and the first is the one that determined whether the system would hold.

The IMEI is the record, not the ticket. A repair ticket is an administrative object. A unit is a physical object that customers call about. We made the IMEI the primary identity of the whole system, so every event — receipt, test, dispatch, repair, parts issue, QC, packing, shipment — hangs off the unit rather than off a job sheet that gets reopened. When a mainboard is swapped, the new IMEI is fetched through the interface and becomes the current identity while the old one is retained as history. That transition is the one place a repair system can quietly lose a unit, and a system built around tickets loses it by design.

Irreversible actions get their own sub-flow, not a button. Board swap, scrap and quotation are the three points where a repair centre leaks money: the wrong part consumed, the wrong write-off recorded, the wrong price promised to a customer. None of them is a single click on the workbench. Each routes into its own approval path, which also means the technician is never asked to make a commercial decision in the middle of a repair.

Reports are queries on the operational tables, not a separate data mart. The three management reports — stock, technician productivity and workload — read the same rows the floor writes. At this volume there is no capacity to reconcile two numbers that disagree; a report that needs its own ETL is a report that is wrong on the day it matters.

The underlying intent was to move the trigger from a person to the system. Receiving should not require someone to remember which stock location a parts code belongs to, and warranty should not depend on a supervisor’s judgement of a purchase date.

What we built

Nine modules in one chain, receipt to despatch:

Receiving — customer, air waybill and IMEI captured per batch, with the stock location assigned automatically from the parts code and the fault description entered as structured data rather than free text.
Warranty check — an interface call against the warranty database decides in or out of warranty, removing a manual judgement step from a high-volume desk.
Dispatch — assignment by skill and current load, with every node of the repair timed and recorded.
Board swap and quotation — separate approved flows; a swap obtains the new IMEI from the interface, a quotation goes out before work continues.
Parts and store — requests, issues, scrap and returns connected to the store record, so consumption is deducted at the point of use instead of being reconstructed later.
Packing and shipment — batch packing, despatch registration and back-fill of logistics information.
Status tracking — any IMEI queried by multiple conditions with its full history, which is what supervisors actually use all day.
Performance statistics — volume, turnaround and return rate by technician and by model.
Interfaces — IMEI and warranty databases, with receiving data exportable for reconciliation and settlement.

Two details are worth calling out because they change daily behaviour. Receiving into stock is the same action as booking the unit in — there is no second entry step where a parcel is recorded twice and eventually recorded differently. And the quality check result is bound to the technician who did the repair, so the performance report is a by-product of the work rather than a monthly reconstruction.

Result

The centre now manages 700+ repair tasks a day in the system, and the after-sales department is out of the business of chasing data. Any unit is locatable by IMEI at any point between receipt and despatch, including across a mainboard swap. Response time and repair throughput are tracked continuously rather than reconstructed at month end, and the three reports — stock, productivity, workload — are used to adjust the production line rather than to explain last month.

What the system deliberately is not: it is not a customer-facing portal, and it is not a business-intelligence product. Both were discussed and both were out of scope for the reason that the bottleneck was internal coordination, not customer visibility. Adding a dashboard on top of a process that is still run by memory would have made the reporting better and the process no faster.

Why this one matters

Because it is the clearest example of the kind of problem we are actually good at: a high-volume operation where the process is the product, where the data already exists but lives in people’s heads and spreadsheets, and where the value comes from making the system the source of truth rather than from a new interface on top of the old one.

If your operation runs at a volume where one lost unit costs more than a week of development, this is the conversation to have.

Screens from this system are not published. It runs on client infrastructure with client data, so we show it live instead: a short screen-share walkthrough under NDA, on a system we demonstrate rather than a screenshot we sanitised. Ask for it in the first call.

Technology

Stack	B/S web application · Oracle · IMEI and warranty interfaces · Barcode label printing · Excel export for reconciliation
Delivery model	Private deployment, B/S application, source delivered
Client	BYD — handset after-sales service centre
Status	Delivered

What we cannot show

Screens are from the delivered system with unit-level data removed. Pricing rules, warranty logic, customer commercial terms and daily volume detail are not published.