RMA / Reverse-Logistics Process-Mapping Framework
A reusable, company-agnostic instrument for describing how a hardware OEM runs its return-merchandise-authorization (RMA) and reverse-logistics flow — and for diffing one company against another, field by field. This document is the empty instrument. It contains no company-specific facts. To use it, instantiate it once per company (see “How to use this template” at the end), then drop each instance into the Comparison Scaffold.
What this is for. Descriptive process-mapping, not market sizing and not strategy. It surfaces structure and evidence; it does not draw conclusions. Every factual claim in an instantiated copy carries a source + confidence tag (schema below); the template itself carries none because it asserts nothing about any company.
How it relates to prior TBD work. This generalizes the vendor-specific structure first developed in the NVIDIA RMA process map and the seven-stage automation spine in the RMA-automation horizontal scan, lifting them into a company-neutral instrument. The NVIDIA-filled instance built on this template is a customer-confidential companion doc (not in this public vault).
Layer A — Company Profile Header
A compact descriptor block that classifies a company at a glance, so two companies can be compared before reading stage detail. Each field is a comparison axis. Fill one of these per company.
| Field | What it captures | Why it’s a comparison axis |
|---|---|---|
| Product type & unit-value density | What’s returned (board / module / whole system) and its ASP band ($, $$, $$$) | High value density → repair beats replace → trapped-capital economics dominate. Low → volume-and-speed economics dominate. |
| Warranty / entitlement model & SLA tiers | Warranty basis (standard / contractual / paid-support tiers), named SLA targets, per-customer custom terms | Determines the entitlement gate and the clock the whole flow is measured against. |
| Advance-replacement offered? | Ship-good-unit-first (advance / ARMA / buffer) vs. return-first (standard) | Advance replacement creates a float of units in the field → a distinct trapped-capital exposure and a reconciliation burden. |
| Repair owner | In-house depot vs. contract manufacturer / EMS / third-party — and who (named) | Sets where the org boundary (and the visibility seam) falls in the repair leg. |
| Volume / scale of returns | Returns per year/month; active RMAs at any moment; growth trajectory | Emerging-pain (growth outrunning process maturity) vs. managed-pain (mature, stable) reads differently. |
| Geographic footprint | Support locations, warehouse/DC nodes, repair-line sites, cross-border legs | Cross-border moves + customs are a recurring queue-time bottleneck; geography shapes cycle time. |
| Automation vs. manual coordination | Where the flow runs on integrated systems vs. email / spreadsheets / paper | The manual-handoff surface is where most bottlenecks and data-integrity gaps live. |
| Primary trapped-capital points | The 2–3 stages where working capital sits idle (advance-replacement float, idle return “bone piles”, consignment at repair sites, unrecovered units) | The headline financial exposure; the answer to “where does capital get stuck here?” |
Layer B — Lifecycle Spine (canonical stages)
A canonical, ordered, numbered set of stages every RMA flow passes through, abstracted from any one vendor. Stage IDs are stable — an instance may mark a stage Absent or Merged, but never renumbers. Wording is refined from the ~16-stage spine; use these IDs when filling the per-stage schema (Layer C) and the comparison scaffold (Layer E).
| Stage ID | Stage | One-line scope |
|---|---|---|
| S1 | Entitlement / pre-conditions | Contract, warranty coverage, entitlement directory, buffer allocations that must be true before a return is even valid |
| S2 | Failure detection | Unit fails in the field; fault is detected/isolated (by customer, OEM tooling, or telemetry) |
| S3 | RMA initiation | A return is opened (portal / API / email); a case is created in the system of record |
| S4 | Triage & validation | Serial / entitlement / warranty verification; log or evidence review; data-quality checks at the door |
| S5 | Approval / authorization | The approval gauntlet (case mgmt → quality → finance → leadership, as applicable); accept/reject decision |
| S6 | Disposition decision | Advance-replace vs. standard; and repair / replace / scrap route (reman vs. repair vs. refurb, rule-based vs. diagnostic) |
| S7 | Replacement fulfillment (forward leg) | Ship the good/replacement unit to the customer (from services pool or new stock) |
| S8 | Return logistics inbound | Pre-ASN / ASN / delivery-note / freight booking / customs on the defective unit’s return leg |
| S9 | Receiving & inspection | Dock receipt, goods-receipt, conforming/non-conforming check, put-away |
| S10 | Diagnosis / failure analysis | Root-cause / failure-mode determination on the returned unit |
| S11 | Repair / refurb | Physical repair, remanufacture, or refurbishment; consignment/turnkey material consumption |
| S12 | Test & certification | Functional test, certification, quality sign-off that the unit is good-as-spare |
| S13 | Restock | Unit re-enters the services / spare pool (like-for-like, typically different serial) |
| S14 | Redeployment / loop closure | Unit dispatched to the next customer / next RMA cycle; the loop closes |
| S15 | Financial settlement / warranty accounting | Consignment reconciliation, buffer sent-vs-returned matching, warranty accrual, credits, out-of-warranty billing |
| S16 | Data & visibility layer (cross-cutting) | The end-to-end status, SLA, escalation, and reconciliation view spanning S1–S15 — not a sequential stage but the layer that observes them all |
S16 is cross-cutting by design: it is filled once, describing the visibility/data spine that runs across all stages, and it’s where “nobody can see the whole loop” pain concentrates.
Layer C — Per-Stage Attribute Schema
The fixed field set captured for every stage (S1–S16), so companies are diffable field-by-field. One row block per stage in an instance. In the template these are empty; the instance fills them.
| Attribute | What to record |
|---|---|
| Trigger / entry event | The event that starts this stage |
| Owner / actor + org type | Who performs it, tagged by org type: OEM / customer / 3PL / CM (contract manufacturer/EMS) / integrator/ODM |
| System of record / tool | The system(s) this stage lives in (ERP, CRM, WMS/TMS, portal, spreadsheet, email, paper) |
| Inputs consumed | Data / artifacts / physical units entering the stage |
| Outputs / artifacts produced | What flows downstream (the thing the next stage consumes) |
| Handoff mechanism | How the output crosses to the next stage: automated (EDI / API / system event) vs. manual (email / spreadsheet / phone / paper) |
| Cycle time / SLA | Target and/or observed duration; whether it’s measured at all |
| Bottleneck & failure modes | What breaks or stalls here; map to a Layer-D archetype ID |
| Visibility / data-integrity gaps | Where the stage is blind, where records diverge, where data is unverified |
| Trapped-capital / cost exposure | Working capital or cost sitting at this stage (idle units, float, rework, scrap, unrecovered value) |
| Source + confidence tag | [Interview: Name, Date] / [Public: Source, Date] / [Synthesis] / [Speculation] — required on every claim |
Layer D — Bottleneck Taxonomy
A normalized vocabulary of failure archetypes, each with a short ID. When you fill Layer C for a company, tag every bottleneck with one of these IDs. That’s what makes “which bottlenecks generalize across firms?” answerable — the same label appears in multiple instances or it doesn’t.
| ID | Archetype | Signature |
|---|---|---|
| BN-1 | Manual data reconciliation | Records live across ≥2 systems (ERP/CRM/spreadsheet); humans hand-reconcile; “swivel chair”; divergent numbers for the same KPI |
| BN-2 | Approval latency | Multi-gate approval adds days/weeks; near-zero rejection rate makes it pure latency, not a filter |
| BN-3 | Return-leg delay / idle “bone piles” | Defective units accumulate before return; advance-replaced units sit idle in the field or in customer/integrator warehouses |
| BN-4 | Non-automated triage / diagnosis | Entitlement, disposition, or fault triage done by hand; low % automated; rule-encodable work still manual |
| BN-5 | CM / customer-side visibility gap | OEM cannot see across the org fence into contract-manufacturer or customer operations (no telemetry, no repair-status feed) |
| BN-6 | Trapped capital in advance-replacement float | Good units shipped before defectives return; sent-vs-returned unmatched → working capital and leakage exposure |
| BN-7 | No end-to-end SLA measurement / escalation | The loop isn’t clocked end-to-end; no aging/stalled-case alerts; “don’t know the score of the game” |
| BN-8 | Intake data quality | Free-text/wrong serials, missing logs/evidence, wrong entity (OEM/ODM mismatch), non-conformance at receipt |
| BN-9 | Missing / manual inbound notification | No automated ASN/pre-ASN to receiving/CM; dock has no advance view of what’s arriving |
| BN-10 | Institutional-knowledge dependence | Routing the right internal person / handoff relies on tenure and relationships, not a system directory |
This list is extensible: if an instance surfaces a bottleneck that maps to none of these, add a new ID here (roll-forward), don’t force-fit it.
Layer E — Comparison Scaffold
The diff mechanism the framework exists to enable. For each canonical stage, one row compares a baseline company against a comparison company. Populate one scaffold per pairwise comparison (baseline stays fixed across all pairings; swap the comparison column to add a new company).
| Stage ID | Baseline company | Comparison company | Same / Different / Absent | Nature of difference | Shared bottleneck? (Y/N + Layer-D ID) |
|---|---|---|---|---|---|
| S1 | |||||
| S2 | |||||
| S3 | |||||
| S4 | |||||
| S5 | |||||
| S6 | |||||
| S7 | |||||
| S8 | |||||
| S9 | |||||
| S10 | |||||
| S11 | |||||
| S12 | |||||
| S13 | |||||
| S14 | |||||
| S15 | |||||
| S16 |
Instructions for filling the scaffold:
- Baseline column: paste the one-line characterization of that stage from the baseline company’s instantiated Layer-C table (owner + system + primary bottleneck).
- Comparison column: same, from the comparison company’s instance.
- Same / Different / Absent: Same = structurally equivalent (same owner-type, same handoff mechanism, same bottleneck). Different = present but structurally distinct. Absent = the comparison company doesn’t run this stage (e.g., no advance replacement → S7 collapses).
- Nature of difference: one clause naming what actually differs — owner org-type, automated-vs-manual handoff, in-house-vs-CM repair, etc.
- Shared bottleneck?: Y/N plus the Layer-D ID(s) that appear in both instances at this stage. A column of shared IDs down the scaffold is the direct read on “which bottlenecks generalize.”
- Confidence travels: if either instance’s stage claim is
[Speculation]or a single-source[Interview], note it — a diff built on a guessed cell isn’t a defensible diff.
How to use this template
One company = one instance. To instantiate:
- Fill Layer A (Company Profile Header) — one filled descriptor block. This alone lets you eyeball-compare two companies before any stage detail.
- Fill Layer C for every stage S1–S16 using the fixed attribute schema. Mark each stage’s owner org-type (OEM / customer / CM / 3PL / integrator). Tag every bottleneck with a Layer-D ID. Every factual claim carries a source + confidence tag.
- Drop the instance into Layer E. The first company you instantiate becomes the fixed baseline column; each subsequent company fills a comparison column and produces one side-by-side scaffold.
- Extend, don’t force-fit. New bottleneck archetype → add a Layer-D ID (roll-forward). Never renumber S1–S16.
Discipline reminders:
- The instrument surfaces and cites; it does not conclude. Instances end in open questions and unknowns, not verdicts.
- Confidentiality travels with content. If an instance draws on customer-confidential sources, that instance inherits the strictest classification of its sources and does not live in this public template’s neighborhood. Keep the empty instrument (this file) free of any company facts.
- Mark the stages where a single source carries all the evidentiary weight — those are the instance’s load-bearing unknowns and the shopping list for the next interviews.
Companion (customer-confidential, not in this public vault): the NVIDIA-instantiated baseline built on this template. This framework generalizes structure first developed in the NVIDIA RMA process map.