Skip to content
Concept · retail-electronics · Tier 2System

Repair Workshop Management

A phone and electronics shop running a repair bench alongside sales, tracking jobs on a whiteboard and in the technician's memory, with customers calling to ask about their device.

The reality

A phone and electronics shop runs a repair bench alongside sales, tracking jobs on a whiteboard and in the technician's memory, with customers calling to ask about their device. A repair is a custody relationship, not a transaction — the shop is holding someone else's property, quoted a price verbally, and has no defence if the customer claims the screen wasn't cracked when they handed it over.

Where it breaks

  • The shop is holding someone else's property with no record of what it looked like when it arrived.
  • Pricing is quoted verbally and adjusted mid-job, so a dispute over what was agreed has nothing to point to.
  • Parts get consumed from stock without being recorded, so a repair's real cost is invisible.
  • A customer calling to ask about their device interrupts whichever technician answers the phone.
  • Devices sit uncollected indefinitely, quietly becoming a liability nobody is tracking.

The Afivox approach

Afivox treats a repair as what it actually is — a custody relationship with evidence, approval and cost attached to every step — rather than a job ticket. The system exists to protect the shop in a dispute as much as to organise the bench.

The system

Users

Front counter staff, technicians, customers

Application

Intake, job ticket, diagnosis, quotation and approval

Services

Parts consumption, technician assignment, notification

Data

RepairJob → Diagnosis → Quote → Approval, PartUsed → StockUnit, Device (by serial)

Integrations

Customer notification by SMS or message

Security

Immutable timestamped intake photos, append-only status events

What it looks like

Concept mockups — illustrative interfaces, not a built system.

Repair desk

JobDeviceTechnicianStatus
RJ-2214iPhone 13, cracked screenD. Okoro
RJ-2215Samsung A54, no chargeUnassigned
RJ-2209iPhone 11, batteryD. Okoro

Device record

Technician queue

Parts consumption

PartJobStock beforeStock after
iPhone 13 screen assemblyRJ-221465
iPhone 11 batteryRJ-220998

Customer status

Ticket RJ-2214

Uncollected ageing

JobDeviceReady sinceValue at risk
RJ-2180iPhone 1218 days ago
RJ-2191Samsung A346 days ago

How it flows

Received
Diagnosed
Quoted
Approved
In progress
Ready
Collected

Secure by design

  • A job cannot progress past quoted without a recorded approval.
  • Intake photographs are immutable and timestamped — evidence of the device's condition on arrival, not editable afterward.
  • Parts consumed always deplete stock — a repair that used parts without a stock movement is a data error, not a shortcut.
  • Status events are append-only, so a job's history can't be quietly rewritten.

Designed to improve

  • Evidence — a device arrives with photographed evidence of its condition and leaves with a recorded handover.
  • Dispute protection — no work happens without an approved quote.
  • Cost visibility — parts consumed are visible against the job and against stock.
  • Reduced interruption — a customer with a ticket reference gets an answer without a technician being pulled off the bench.
  • Liability control — devices sitting uncollected are visible with their value.

Before

  • A device is handed over with no record of its condition, so a dispute over pre-existing damage has nothing to settle it.
  • A price is quoted verbally and can shift mid-job, with nothing written down.
  • Parts leave the shelf without anyone recording where they went.
  • A customer calling for an update interrupts whichever technician picks up.

After

  • A device arrives with photographed evidence of its condition and leaves with a recorded handover.
  • No work happens without an approved quote.
  • Parts consumed are visible against the job and against stock.
  • A customer gets an answer from a ticket reference, without a technician being pulled off the bench.

Your operation probably has a workflow like this.

One session. We look at what's breaking, and what we'd build around it — whether or not you hire us afterward.

Tell us where yours breaks