Every repair, from booked in to handed over — with the money still correct
A repair is not one event. It is an intake, a deposit, a part, an approval, a balance and a handover — and most systems keep those in different places. This one keeps them on the same record.
Where a repair and its money come apart
None of these are unusual. They are just what happens when the job lives on a board and the money lives somewhere else.
A deposit is taken at the counter and noted on the ticket, but never against the bill.
Extra work is agreed verbally, done, and then argued about at collection.
A part is fitted from the drawer and the stock count is corrected next week, or never.
The device is handed over before the balance is settled, and nobody can say who allowed it.
Two faults on one device become two half-finished tickets.
A repair is edited after it was paid, and the day's takings stop matching the invoices.
Intake to handover, on one record
Each step writes to the next. The job and the money move together because they are the same record, not two records kept in step by hand.
- 01IntakeDevice, fault and customer captured against a ticket.
- 02DepositPayment recorded against the job; the balance updates.
- 03PartsStock committed to this ticket, not just written down.
- 04ApprovalExtra work is quoted, and how the customer agreed can be recorded on the job.
- 05PaymentThe balance settles across card, cash or store credit.
- 06HandoverHandover closes the ticket and the stock movement.
- 07InvoiceThe document and the ledger carry the same figures.
The point is not that the steps exist. It is that a part used reduces stock, the stock movement lands in cost of goods, and cost of goods lands in the profit and loss — without anyone retyping a number.
One ticket, its whole timeline
Not a summary screen. The record a shop actually works from.
Everything that happened to this device, in order
The status flow, the technician who owns it, the parts committed to it and what the customer has been told — on one record, in the order it happened. When a customer asks why the bill changed, the answer is on the ticket rather than in someone's memory.
Booked in → handed over, with the money correct at every step.
What you get back at the end of the month
The operational gain is obvious. The financial one is the reason this matters.
- One version of the job
- No board, no notebook and no phone thread to reconcile against each other.
- Deposits that count
- Money taken at intake is money against the bill, not a note to remember.
- Parts that move stock
- Fitting a part reduces the shelf and lands in cost of goods automatically.
- Balances you can see
- What is paid and what is still due is a figure, not a conversation.
- A history that holds
- Financial changes leave a record, so last month still reads the same next month.
The awkward jobs, and what the system does about them
Any system handles the simple repair. These are the ones that decide whether the numbers survive the month.
- Multiple issues on one device
- Several faults stay on one ticket for one device, each with its own work and cost, so the customer gets one bill and you keep one history.
- Estimate only, not yet approved
- An estimate is a priced intention, not a job. It does not commit stock or create a charge until it is approved.
- Deposit taken at intake
- The deposit is recorded against the job immediately and reduces the balance due. It is money received, not a note on the ticket.
- Only part of the work approved
- The customer can approve some lines and decline others. The declined work leaves the bill rather than lingering as an assumption.
- A part added after the quote
- Added cost is quoted on the ticket and the price change is stamped and audited. It never quietly appears on the final bill.
- Additional payment required
- When approved work raises the total, the extra shows as a balance due rather than being absorbed into the original figure.
- Waiting for parts
- The ticket carries a waiting state, so a job held up by a supplier is distinguishable from one nobody has started.
- Outsourced repair
- A device sent out for specialist work stays on its ticket while it is away, so it is never simply missing from the shop.
- Cancelled before stock was allocated
- Cancelling early closes the ticket without touching stock, because nothing was committed to it yet.
- Cancelled after stock was allocated
- Committed stock has to be dealt with deliberately — returned to the shelf or accounted for — rather than silently released.
- Warranty claim on an earlier repair
- A warranty job links back to the original repair, so the return is attached to the work that caused it instead of looking like a new sale.
- Handing over before the balance is paid
- An unpaid handover requires a controlled override with a reason, and it leaves an audit entry naming who allowed it.
- A manager reverses something
- A reversal is a recorded action with its own history. A paid part cannot be removed silently, and an invoice cannot be reduced silently after payment — any post-payment change creates an adjustment, refund, credit note or approved write-off.
Every one of those leaves an audit history. That is the difference between a system that records what happened and one that records what someone last typed.
What the repairs module carries
One ticket per job
Device, fault, customer and history on a single record from intake to handover.
Owner and queue
Every job has an assigned technician and a place in the queue, not just a status.
Extra work stays visible
Added work is quoted on the ticket before it reaches the bill, and every change to the price is recorded.
States that mean something
Waiting for parts, outsourced and completed are distinct — not one vague 'in progress'.
Invoice from the same record
The document is generated from the job, so the bill and the ticket cannot disagree.
Audit history
Financial and stock changes are recorded with who did what, and when.
Warranty starts at handover
Not at booking. Change the length later and the expiry is recalculated from the same start date, so the printed note and the record agree.
Print what you need
Ticket, label, receipt or A4 invoice from one template — so the PDF and the paper never disagree.
A link the customer can check
The QR on the ticket opens a status page for that job. No login, no account, and search engines are told not to index it.
The questions owners actually ask
Including the one that starts “we already use a whiteboard”.
A whiteboard tracks the job but not the money. It cannot tell you that a deposit was taken, that a part was fitted from stock, or that a bill changed after payment. The board is fine until someone asks why the takings and the invoices disagree.
Yes. Several faults live on one ticket for one device, each with its own work and cost. The customer gets one bill and you keep one history, rather than two half-finished tickets for the same handset.
It is quoted on the ticket first, and you can record how the customer agreed. The added cost stays visible and the balance due updates, so the customer is never surprised at collection and the original figure is not quietly rewritten — every price change is stamped and audited.
Not silently. Once a payment is recorded, a change must create a controlled adjustment, an additional invoice, a credit note, a refund or an approved write-off. The original payment history is preserved either way.
Yes, but it is a deliberate act. An unpaid handover requires a controlled override with a reason, and it leaves an audit entry naming who allowed it — so it stays a decision rather than a habit.
It depends whether stock was committed. Cancelling before allocation closes the ticket cleanly. Cancelling after means the committed parts have to be dealt with deliberately, so the shelf and the system stay in agreement.
See the repair workflow on your own jobs
Bring the repair that always causes an argument — the part-paid one, the one with extra work agreed halfway through — and we will walk it end to end.