← Back to Insights

Electronics rework & returns management system

This case study covers a bespoke rework and returns management system we built for an electronics manufacturer. The application runs on a Raspberry Pi and is accessed from standard browsers on the shop floor, replacing paper red tags, ad‑hoc spreadsheets, and email chains with a single, structured workflow.

1. High‑level description

The system is a dedicated rework and returns management tool for a PCB manufacturing environment. It provides one place to log faults, plan rework, print labels, track locations, and analyse performance over time.

It is not an off‑the‑shelf product; it is an example of a tailored digital workflow that can be adapted to a customer’s own processes, terminology, and data.

2. Core functional areas

2.1 Red‑tag creation & label printing

Operators create rework / red‑tag records directly at the line. The form captures job/RMA number, serial number (including support for non‑serialised assemblies), customer, part number, revision and date.

• Cascading selection for Customer → Part number → Revision, driven by the customer’s BOM data.
• Component‑level table: designator, component part number, description and action (Replace, Reflow, Remove short, FW update, PTO, etc.).
• Intelligent lookup of component data to minimise manual typing and errors.
• Repair difficulty / repair type fields for later analysis (e.g. Basic / Advanced, Conventional / SMA).
• Free‑text fault description with character limit and live remaining‑characters counter.
• Option to include or exclude the description on the printed label.
• Named user selection so every red tag is tied to a specific operator.

Submitting the form generates a print‑ready PDF label and stores the record in the database. PDFs are archived in structured folders for traceability.

2.2 Awaiting repair queue

A dedicated “Awaiting repair” view shows all units that have been logged but not yet completed. Repair staff can see their workload, sort/filter jobs, and pick the next unit to work on, reducing the risk of lost boards and hidden WIP.

2.3 History & search

Full rework history is searchable by job, serial, customer, part number, date range, user and more. This acts as a complete audit trail for customer returns analysis, 8D reports, and external audits.

2.4 Part search & statistics

• Part search quickly finds all rework activity involving a particular component or part number.
• Job statistics calculate rework rates per job (e.g. “X out of Y boards needed rework”), giving insight into process capability and first‑pass yield.

2.5 Location tracking & QR codes

The system tracks where units physically are within the factory – shelves, repair benches, quarantine racks, RMA cages and more. It generates QR codes for locations so a unit’s tag can be scanned and tied to a specific location, dramatically reducing “lost” units.

2.6 RMA booking‑in and BOM maintenance

• Customer RMAs are logged as they arrive and flow into the same tracking and reporting pipeline.
• BOM import/maintenance keeps the system’s configuration data synchronised with production reality so dropdowns and reports always reflect current products and revisions.

2.7 News feed & status monitoring

A simple news feed allows production or quality to publish shop‑floor alerts directly inside the app. Supporting endpoints expose counts and health metrics (CPU, memory, disk, network) from the Raspberry Pi host for quick diagnostics.

3. Typical end‑to‑end workflow

1. Fault is found on the shop floor and a red‑tag record is created from any browser.
2. A print‑ready PDF label is generated and attached to the unit.
3. The unit moves into the “Awaiting repair” queue and to a physical location (optionally with QR‑coded shelving).
4. Technicians carry out the listed actions, update status (repaired / scrapped / etc.), and the system updates counts and history.
5. Quality and engineering teams use reports and statistics to understand rework rates, common failure modes and opportunities for improvement.

4. Business benefits

4.1 Efficiency & throughput

• Centralised logging eliminates duplicate data entry, paper forms and scattered spreadsheets.
• Technicians receive complete, standardised instructions with every unit.
• Queues and QR‑coded locations shorten turnaround time and avoid the cost of lost or forgotten boards.

4.2 Quality, traceability & audits

• Detailed, searchable history by part, customer, job, revision and failure type makes it easy to spot patterns.
• Red‑tag PDFs and digital records provide robust documentation for ISO/TS/IATF and customer audits.

4.3 Data‑driven management

• Job statistics and summary reports provide KPIs for rework, scrap and common failure modes.
• Hard data supports CAPA and 8D investigations, supplier feedback and design changes.

4.4 Deployment model

• Raspberry Pi‑hosted, using standard web technologies – no heavy infrastructure required.
• Fully local hosting suits sites with strict data policies or weak internet connectivity, but the same architecture can scale to server‑class machines or integrate with ERP/MES.

5. Adapting this pattern for other manufacturers

This system was built around one customer’s processes, terminology and BOM structure, but the pattern is reusable. Fields, workflows and reports can be adapted to different product lines (PCBs, sub‑assemblies, finished systems) or to specific regulatory requirements.

If you run a lab or factory where boards, modules or instruments are still tracked with paper tags and spreadsheets, we can help design a similar system – or a fresh workflow tailored to your environment.

Want to explore a rework and returns system for your site? Start a project.