Give the repair desk a practical workflow for receiving a customer device, recording the problem, completing diagnosis, tracking work and payments, correcting records when needed, and preserving the repair history....
The workflow shows what is happening now and what the repair team needs to do next.
Each stage builds on the customer, device and commercial information already recorded for the job.
Record the receiving branch, customer, device type, brand, model, optional serial number or IMEI, reported fault, repair type and expected pickup date.
Record diagnosis notes, the internal repair cost where authorised, the expected customer charge and the expected completion information.
Add progress updates while the job is being worked on and retain the current repair status for the team.
Move an active repair to Waiting for Parts when the next action depends on availability, then resume the job when work can continue.
Confirm that repair work is ready, review the customer charge and payment position, and make the outstanding balance visible before release.
Once collection is completed, preserve the repair’s device, diagnosis, progress, payment and completion record for later review.
Hwɛso Ma Me supports a clearer commercial record without mixing internal costing with the amount the customer is expected to pay.
Maintain the internal repair cost, minimum allowed charge and default expected charge for the repair type.
Review the expected charge during diagnosis and retain the final customer charge used for checkout.
Track the deposit, amount paid and remaining balance as customer payments are recorded.
The minimum allowed charge helps the business protect the lower boundary it has set for a repair type, while authorised users keep internal repair cost visibility separate from customer-facing charges.
Repair details, progress actions, payments and corrections remain easier to understand when they stay connected to the same job history.
Review status movement, diagnosis activity, work updates, waiting and pickup readiness in context.
Retain deposits and balance payments, with controlled correction handling when a recorded payment must be voided.
Update supported repair information while keeping the job’s operational record available for review.
Keep the expected pickup date and completed activity visible alongside the repair details.
Use Enter or Space to open an answer. Arrow keys move between questions.
The repair record can include the customer, device type, brand, model, optional serial number or IMEI, device condition information, reported fault, repair type, receiving branch and expected pickup date.
Diagnosis records the confirmed finding and expected customer charge. Repair-type setup can hold internal repair cost, minimum allowed charge and default expected charge. The job can later retain the final customer charge used for completion and checkout.
The repair payment position shows the deposit or other payments recorded, the total amount paid and the outstanding balance. Payment history remains connected to the repair.
An in-progress repair can be marked Waiting for Parts so the delay is visible. When work can continue, the repair returns to In Progress and the movement remains part of its history.
Yes. Every repair keeps its receiving-branch context, and access to branch or all-branch views follows the permissions configured for the signed-in user.
