Device repair & trade-in.
Harvey Norman — one of the largest electronics and home furnishing retailers in Ireland and the UK — needed a purpose-built system to run its entire after-sales service and trade-in operation. Deployed as two separate instances per country, each configured for its own stores, service providers and compliance requirements, but running on the same CloudCore platform.
Full repair lifecycle + trade-in programme, two countries, one platform.
- Client
- Harvey Norman · LoveTech
- Sector
- Retail · after‑sales service & trade‑in
- Region
- Ireland & United Kingdom
- System
- Repair lifecycle + trade‑in management
- Scale
- 2 country instances · 14 background processes 24/7
- Built on
- CloudCore VNext · Microsoft Azure
Results
Built on CloudCore, LoveTech now manages the full lifecycle of every service case — from online Bookeo appointment scheduling and in-store drop-off through POS purchase verification, warranty and insurance coverage approval, stolen-device blacklist checks, service-provider shipping, repair and customer collection. A dedicated mobile app for digital signatures, automated email notifications, QR-coded repair labels and a complete document trail covering service terms, data agreements, loan agreements, quotes, diagnostic reports, service summaries and collection dockets keep customers informed and staff accountable at every step.
1. What happens when a customer walks in with a broken device
The system already knows what they bought. LoveTech continuously imports every purchase transaction from Harvey Norman's point-of-sale system — more than thirty fields per transaction, including the customer's name, contact number, email, street address, store number, franchise, invoice number, invoice date, product code, brand, model and full product description. When a customer walks in with a cracked iPhone screen, the system matches the device to the original sale within seconds, links the invoice and determines whether the product is still within the manufacturer's coverage period based on the purchase date and product category. No receipt required. No manual lookup. The purchase history is already there before the customer finishes explaining the problem.
Missing receipts do not stall the process. Where a till match cannot be found — perhaps the customer bought the device at a different store, or the transaction has not synced yet — the system triggers a formal proof-of-purchase workflow. It generates a branded request email to the customer with a secure upload link, tracks the request status, and when the receipt is uploaded it attaches the document to the case and notifies the store that it is ready for review. A separate email goes to the store when the upload is received. A family with a faulty washing machine does not need to dig through drawers looking for a paper receipt — the system either already has the record from the till import, or it actively goes and gets it through a tracked, auditable process.
Appointments and walk-ins land in the same queue. Customers book repair appointments online through Harvey Norman's website. Each booking arrives in LoveTech automatically with the booking number, scheduled start and end times, customer name, email, phone number, the service product category and selected options — and appears alongside walk-in cases in a single queue per store. Staff can allocate, reschedule or cancel bookings without leaving the system. Each booking carries a tracked status — pending, confirmed, completed, rescheduled, no-show or cancelled — and every status change is logged. For a retailer handling hundreds of service requests across multiple stores every week, this is the difference between a managed operation and a chaotic one.
2. How the system diagnoses a device — and what it can do with Apple products
Every device gets a structured diagnosis. Once a device is accepted for service, the system creates a formal device record capturing the serial number, brand, model and device category, then links it to the parent service request and any related purchase record. The technician records the fault type, symptoms and recommended action — in-house repair, third-party service or replacement — and the system generates a service order tied to the case with its own status lifecycle, priority level and promise date. A customer with a laptop that will not charge does not wait for someone to decide what to do — the system classifies the issue, creates the service order and routes it immediately.
For Apple devices, the system runs diagnostics directly through Apple. From inside the service case, LoveTech connects to Apple's service platform using the device's serial number, fetches the available diagnostic suites for that specific hardware, initiates a remote diagnostic test and monitors it through to completion. The system retrieves detailed component-level results — pass, fail or inconclusive for each module tested — and then looks up replacement parts with manufacturer part numbers, pricing options and pricing descriptions, so the repair can be quoted accurately before any work begins. A diagnostic report is generated automatically and stored against the case. The customer gets a formal document. The technician gets a clear, auditable record. No separate login, no manual report writing.
When a repair is not worth doing, the system offers clear alternatives. If the cost of replacing a logic board exceeds the value of the laptop, the system presents clear alternatives: a fix-on-the-spot option for minor issues, a reimbursement path, or a documented closure. The diagnosis outcome feeds directly back into the service order — updating its status, recording the decision and triggering the appropriate next workflow step. The coverage type, service action type and diagnostic findings are all captured against the device's service record. Nothing sits unresolved without a clear next step, and the customer is never left wondering what is happening.
3. How the system decides who pays for the repair
Coverage is determined automatically from the purchase record. Before any repair work begins, the system cross-references the invoice date from the imported till transaction against the coverage rules configured for that product category. Each device's service setup record holds the coverage type — manufacturer warranty, extended insurance or no coverage — determined from the purchase date and product class. A laptop bought fourteen months ago with a two-year manufacturer warranty is still covered. A phone bought three years ago is not. The system knows this because it already has the invoice date, the product code, the supplier and the category-level coverage rules. No one has to look it up, estimate it or ask a manager.
Warranty and insurance claims are assembled and routed automatically. If the repair falls under manufacturer warranty or an extended insurance plan, the system generates a formal coverage approval request — bundled with the proof of purchase, the diagnostic findings and the service order details — and routes it to the relevant party for decision. The coverage approval record captures the approval status, the approver's identity, the decision date, any approval notes and the coverage type that was granted or denied. If coverage is rejected, the system pivots the case to a customer-charge path and generates a formal quote. The entire decision chain — who requested it, who approved or rejected it, when, and the reasoning — is permanently logged against the case. If a dispute arises six months later, the rationale is immediately retrievable. For a retailer handling thousands of warranty decisions across two countries, this consistency is not optional.
4. What happens from the workshop to the moment the customer picks up
Each case moves through enforced stages automatically. Intake, diagnosis, in-service repair, post-service review and customer collection — the system enforces the sequence. The case record itself carries more than forty tracked fields including the case type, customer, assigned store, creation date, current status and the full status history. Service orders within a case carry their own thirty-plus fields — including priority level, promise date, service action type, assigned technician and independent status lifecycle — so a single case can have multiple service orders progressing in parallel. A customer who dropped off a phone for a screen replacement and a separate battery issue does not need to wait for both to be coordinated manually — each service order tracks itself through its own sequence of statuses.
Parts, suppliers and costs are logged as the work happens. When a device needs a part replacement, the system records the supplier, the part source, the cost and the responsible technician against the service order. For Apple repairs, the system retrieves manufacturer part numbers, pricing options and component details directly from Apple's service platform, so the cost is accurate before the work begins. For manufacturer-authorised repairs that need to be sent to an external service provider, the system dispatches the service order with full case documentation — including the device serial number, brand, model, category, diagnostic results and coverage approval — and tracks it through submission, acceptance and completion. At every point, the system knows where the device is and what stage the repair has reached.
The device is not returned until everything is accounted for. At the post-service stage, the system generates a detailed service summary and collection document covering the work performed, the parts used and any outstanding items. It checks whether data services — backup, restore, transfer — still need to be completed. Accessories that were recorded at intake — a charger, a case, a stylus — are tracked individually, with each accessory's status maintained through a full history trigger, and reconciled against the original intake list before collection. The customer signs off on the collection docket through the in-store tablet app, and the case closes cleanly. No missing accessories, no unsigned documents, no loose ends.
5. How the system handles customer data on every device that comes through the door
Three options, three different agreements, all generated automatically. When someone hands over a phone or a laptop, LoveTech captures the customer's data preference at intake. The customer selects one of three options: they have already backed up their own data, the store will perform the backup on their behalf, or the device should be restored to factory settings. Each option triggers a distinct, versioned data agreement document — the system selects the correct template based on the customer's choice, renders it with the case and device details, presents it for signature on an in-store tablet and captures the signed agreement against the case. The three paths are enforced — no case proceeds past intake without a signed data agreement on file.
Backup completion, data-wipe certification and technician accountability are all tracked. The system records whether the customer's backup was already complete or whether the store performed it, logs data-wipe certification with the completing technician's identity and timestamp, and maintains the signed agreement as part of the permanent case record. This creates a full chain of accountability for every device in the workshop — who consented to what, when, what data option was selected, and who carried it out. For a retailer operating across multiple stores in Ireland, where data protection compliance is not optional, this is the minimum standard for handling customer devices responsibly. The system enforces it on every single case without anyone having to remember which form to use or where to file it.
6. How loan devices are managed without spreadsheets or paper forms
The system manages a pool of loan devices across every store. A customer's phone goes in for repair and they need something to use in the meantime. The system maintains a per-store inventory of loan devices, each tracked by device category, product model, serial number and assigned store. When a loan device is booked out, the system records the book-out date, links it to both the service case and the customer, and automatically generates a loan agreement covering the device details, its cosmetic condition at the time of issue and the customer's acknowledgement of terms. Every change to a loan device's status is captured through a full history record. The customer reviews and signs the agreement on a tablet — no paper form, no scanning, no filing.
Returns are checked against the original condition automatically. When the repair is complete and the customer returns the loan device, the system runs a condition check against the state recorded at book-out — so any damage that occurred during the loan period is identified immediately. The return date, the returning user and the condition assessment are all logged. The entire loan lifecycle — agreement, book-out, return, condition comparison and any accessories booked out with the device — is recorded against both the service case and the loan device inventory. A store manager can see every loan device that is currently out, who has it and how long they have had it, without maintaining a separate log. For a retailer lending out expensive phones and tablets every day, this is the difference between a controlled process and a liability.
7. How trade-ins are checked before anyone makes a commercial decision
The system runs automated safety checks before any valuation. A customer walks in with an old phone and wants credit towards a new one. Or they start the process online from home. Either way, the system captures the device's unique identifier, validates it structurally, and runs it through the MobiCode blacklist API automatically — MobiCode in turn checks against the GSMA stolen‑device register and Apple’s Find My activation‑lock status. If the device has been reported stolen, the trade-in stops immediately. The system then checks whether Find My iPhone or a device lock is still active — if it is, the trade-in is blocked and the customer receives a quarantine notification explaining exactly what needs to be removed before the process can continue. Separate duplicate checks prevent the same device identifier or serial number from being traded in twice. These checks run on both the in-store and online trade-in paths — the same validation, enforced identically regardless of channel.
Valuation, terms, shipping and gift card are handled in a single flow. The trade-in record tracks more than sixty fields per device — including the device category, model revision, cosmetic grade, valuation amount, the vendor who assessed it, the customer's details and the full status history. If the customer accepts the valuation, the system generates the trade-in terms for signature, produces a shipping label for the device and issues a gift card for the agreed value. Where a new device is being purchased as part of the trade-in, its identifier is validated separately — including its own duplicate and serial number checks — all within the same flow, without anyone re-entering data. The online trade-in path follows the same validation and assessment steps, but the system also sends reminder emails automatically for customers who start the process but do not complete it. A scheduled background monitor flags anything that has stalled. For a retailer accepting trade-ins across multiple stores, a single device slipping through without a stolen-device check would be a serious problem. The system makes that impossible.
8. How every document and email is produced without anyone pressing a button
A single repair case can generate more than a dozen documents over its lifetime. Service terms, setup request forms, diagnostic reports, quotes, loan agreements, data agreements, data-wipe certificates, service summaries, collection dockets, drop-off dockets, repair labels, trade-in labels and shipping labels. The system renders every one of them from a versioned template, populated with data pulled directly from the case, device and service order records, branded to Harvey Norman's specifications and stored as a formal document against the case for instant retrieval. No one selects a template, fills in fields or saves a file. Because templates are versioned, terms can evolve without affecting cases that were started under earlier versions — and the system manages the version selection automatically based on when the case was created.
The mobile app on in-store tablets handles signatures and document presentation. The app presents cases awaiting signature, retrieves the correct versioned document from the system, renders it for the customer to review, captures their signature digitally and uploads it against the case record. Service terms, loan agreements, data agreements, trade-in terms and collection sign-offs are all handled through the same app. Each signature upload is tied to a specific document type and case, creating a permanent, retrievable record. Staff do not need to print anything, find a form or chase a signature later — the system surfaces what needs signing, when it needs signing and who needs to sign it.
Email notifications fire at every significant status change. When a case is created, the customer gets an email. When it goes on hold waiting for parts, another email. When it comes off hold, another. When proof of purchase is needed, when the device is ready for collection, when it has been sitting uncollected — each one triggers a branded email automatically. Store notifications go out separately when new work arrives. Each template is managed centrally by case type, with the ability to toggle individual templates on or off per status transition, so messaging stays consistent across every store without each location managing its own communications. Trade-in emails follow a separate template set — case creation confirmations, quarantine notices, completion updates — imported and matched to the correct case automatically. Across hundreds of open cases at any given time, the difference between a customer who feels informed and one who doesn't is decided by whether these emails fire reliably at every stage — and they do.
9. How every device movement is tracked between stores, service providers and customers
Every handover is logged with what was sent, its condition and what came back. Not every repair happens in the store. When a device needs to be sent to a manufacturer's service provider — or returned to the customer by post — the system tracks every movement as a formal shipment record. Each shipment detail captures the courier, the device type, the shipping method, packaging details, reference numbers, the dispatching user and which accessories are included. The system generates a shipping label with store data, delivery address and case details embedded in a scannable code, and attaches everything to the case. When the device comes back from the repairer, the system confirms receipt, logs the condition and reconciles accessories against the original manifest — so if a charger went out with the device and did not come back, that is flagged immediately.
The same tracking applies to customer shipments and trade-in shipments. Each shipment type — service provider dispatch, customer return, trade-in device — has its own label generation, its own documentation and its own audit trail. Customer shipments track their own accessory manifest separately, so accessories sent to a customer are reconciled independently from those sent to a service provider. At every handover — store to courier, courier to service provider, service provider back to store — there is a logged record of what moved, what condition it was in and what arrived. Nothing is lost between handover points, and no one has to maintain the trail manually. For a retailer sending devices to service providers every day, a single missing accessory or unrecorded shipment creates a dispute that costs more to resolve than the accessory was worth. The system eliminates that problem.
10. What management sees without asking for it
A live operational view across every store, built automatically. A scheduled background process refreshes the master reporting warehouse on its own cycle, so dashboards always show current data without anyone running a query or requesting a report. A case status heatmap shows every store's open cases by status — rendered as a formal, shareable document that highlights bottlenecks, ageing cases and stores with unusual volumes at a glance. The master warehouse dashboard aggregates case data across all stores with filterable, exportable reports covering site performance comparisons, service volumes by device category, case-outcome summaries and turnaround time analysis. Performance data is pre-calculated and cached, so dashboards load instantly even across high case volumes.
Repeat repairs and customer satisfaction are tracked automatically. A loop rate report tracks devices that come back for the same issue within a defined window, filterable by date range, case type and store. This is how the system surfaces patterns that no individual store would spot: a batch of phones with the same screen defect, a service provider whose repairs do not hold, a product category with an unusually high failure rate. Post-service customer satisfaction surveys capture structured feedback — including communication scores and expectations scores — tied to individual cases by case number and customer name, then fed into a service quality dashboard. Average communication scores and expectations scores are calculated per month, per store, without anyone compiling them. Knowing which stores are falling behind before it becomes a pattern is the difference between managing service quality and reacting to complaints.
The power of automation
What makes this system work at scale is not any single feature — it is the fact that fourteen separate scheduled background processes are running around the clock, constantly watching the entire operation without anyone supervising them.
The promise-date reminder process checks every open case against its committed return date and fires alerts when deadlines approach or pass. The uncollected-device process flags cases where the repair is complete but the customer has not come back, and sends reminder emails automatically. The case-hold monitor checks how long cases have been waiting for parts, customer response or coverage decisions, and escalates them if they have been on hold too long. The back-order monitor tracks devices waiting on parts that are out of stock, so nothing sits forgotten in a queue.
The abandoned-case process identifies cases that have gone quiet — no updates, no customer contact — and flags them for resolution. Apple status updates on repairs and part orders are processed automatically, updating the case without anyone checking manually. Customer emails are imported and matched to the correct case automatically. Trade-in emails are imported separately. The Find My iPhone status verification runs on its own schedule. The MobiCode blacklist integration is monitored to ensure it stays active. The trade-in process monitor flags stalled trade-ins before they expire. Trade-in valuation pricing is refreshed automatically from the valuation partner. The master reporting warehouse is refreshed on schedule so dashboards always show current data.
Each process runs independently. A delay in one never blocks another. In a single-store operation, a good manager can keep all of this in their head. Across multiple stores, with hundreds of open cases at any given time, that is not possible. The system does not replace the manager's judgement — it makes sure nothing reaches their desk too late.
The commercial logic
Harvey Norman sells thousands of products every week across Ireland and the UK. A percentage of those products will develop faults, need servicing or be traded in. Without a system that manages this at scale, every faulty device becomes an ad-hoc problem — handled differently by different staff in different stores, with no visibility into what's happening across the operation.
LoveTech turns that into a managed operation. Every case follows the same enforced stages regardless of which store, which country or which technician is involved. Every warranty decision is made from the same data. Every loan device is tracked. Every shipment is logged. Every customer receives the same quality of communication. The result is consistency — across hundreds of open cases at any given time, across two country deployments, across every product category from phones to appliances.
The loop rate report catches products or service providers that generate repeat repairs. The satisfaction dashboard ties customer feedback to specific stores and service orders. Promise-date monitoring flags cases before they become overdue. These are not reporting tools — they are early warning systems that let management act before a single case becomes a pattern.
The system exists because after-sales is not a cost centre to be minimised — it is the part of the business that determines whether a customer buys from Harvey Norman again. Handling it well, consistently, at scale, across two countries, is what LoveTech is for.
Other production systems.
Procurement & Supply Chain
Multi-site procurement, three-way invoice match and four-tier dashboards for a national contract caterer.
Order Management & Logistics
Five order channels unified into one production pipeline; same-day delivery across two cities, plus three native apps.
Bookings & Resources
Booking-to-invoice in under a minute, with Xero sync, SnapScan reconciliation and WiFi voucher generation.