Repair shop software that runs the bench
Every repair job follows the same six stages your bench actually uses, from received through to completed, with each move logged and nothing skipped.
A repair ticket that lives in a notebook or a spreadsheet is a repair ticket nobody can find when a customer rings asking where their phone is. Phone repair shop software has one real job: make sure a handset that comes in over the counter never becomes a mystery to whoever answers the phone an hour later.
A job, from counter to bench and back
In Mobile POS, a repair job is booked in either from the dedicated Repairs screen or directly from the till's repair-intake tab, capturing the customer, the device make and model, the IMEI or serial number, and a description of the fault. From that point the job is a single record that moves through a defined status lifecycle — received, diagnosing, awaiting parts, in repair, ready, completed — rather than a sticky note updated on a whiteboard.
Every status change is timestamped, so a manager can see not just where a job currently sits but how long it sat in each stage — useful for spotting a bench that consistently sits on diagnosed jobs for two days before quoting, which a paper system never surfaces until a customer complains.
Fault types, not free-text guesswork every time
Rather than typing a fault description from scratch on every job, technicians pick from a standard set of fault types — screen/LCD, battery, charging port, back glass, camera, speaker, microphone, water damage, software/firmware, and more — each with a default labour cost that speeds up quoting on the common cases, while still allowing a free-text diagnosis note for anything unusual. A job can carry more than one fault type, which matters for the handsets that come in with a cracked screen and a dead battery at the same time.
Quoting and deposits
A job carries an estimated cost at diagnosis and a final cost once the work is actually done, with a distinct quote status separate from the repair status itself — so a job can sit "quote sent, awaiting customer approval" without that being confused with the technician's progress on the bench. Where a shop takes a deposit before starting work, the deposit amount, payment method and paid date are recorded against the job, and a deposit can be refunded against that same record if a repair falls through, rather than being handled as an unconnected till refund with no link back to the original job.
Parts consumed against real stock
When a technician adds a part to a job, it's drawn from the same product catalogue and stock levels the till sells from, not a separate parts list kept in someone's head. A part used on a repair reduces the shop's actual stock count immediately, and the cost of that part at the time it was used is recorded against the job even if the part's list price changes later — so a repair's margin, once complete, reflects what the part genuinely cost the shop.
From completed job to till sale
A completed repair links through to the sale that collects payment for it, so the job and the transaction that paid for it are one continuous record rather than two things a bookkeeper has to match up by hand at month end. Each status change can also trigger a customer notification, so "is my phone ready" becomes a text message a customer reads rather than a phone call a member of staff has to take mid-repair.
Repairs on handsets bought in as a trade-in follow the same job workflow — see how a used handset is graded and logged before it reaches the bench — and every part or handset a technician draws on stays tracked back to the same IMEI-level stock record the till sells from.