Turning Warranty Claims Into Product Improvements
By building a structured RMA data system from the ground up, I turned customer warranty claims into actionable product insights — identifying recurring failure modes, prioritizing improvements, and creating a data foundation that informed years of product, testing, and quality work.
The Challenge
There was no shortage of customer feedback: Away had an in-house CX team, a NYC retail store 10 minutes from HQ, and a consistent flow of customer photos. I had access to substantial qualitative information, but the quantitative data was missing.
Seeing a huge opportunity, I built data infrastructure for RMA reasons from scratch. Without a way to pull data, it was impossible to quantify the frequency of different defects, understand the business impact, or begin solving real product problems. To do this, I had to find a level of detail specific enough to act on, but not so specific that it slowed the CX team down or stopped being practical. The reasons were broken down as follows:
Quality RMAs - Product defects and failures
[Component] Zipper
Puller Broken
Coil Broken
Other failure modes
Non-Quality RMAs - Customer preference or expectation
Color
Size
Material preference
Operational RMAs - Fulfillment and delivery issues
Incorrect product
Delivery issue
Transit damage
Analysis & Actions
Steer the team from feelings to facts.
A picture may be worth a thousand words, but the most dramatic looking failures aren’t necessarily causing the greatest business impact.
How we looked at the data
Frequency by RMA reason independently
Analyze RMA reason by size or style. For example, could there be more wheel failures on larger luggage sizes, presumably packed heavier by customers? Or were wheel failures distributed consistently across all sizes?
Analyze time to failure- the period of time between purchase and the RMA claim. Defects that occur within the first 30 days, 1 year, or 5 years are all important pieces of information, but need to be managed differently.
What we did with the data
This data was used for a number of things that steered the direction of work for the next 3-5 years for Away’s luggage.
Identified the defects and sorted them into an impact vs complexity matrix.
Audited existing measurement, inspection, and QC methods. Some items were being visually inspected, but not measured or tested appropriately.
Distinguished design failures from manufacturing and assembly issues, then modified or completely redesigned components where necessary.
Audited the assembly process. We unified assembly methods, created assembly specifications, added jigs, adjusted materials, and tested, tested, tested.
Shared non-quality and operational insights across functions. For example, non-quality RMAs helped identify opportunities to improve online product information around size, weight, materials, and other characteristics that contributed to customer expectations and returns.
What began as a way to categorize warranty claims became a quality intelligence system — informing improvements to existing products while shaping testing, specifications, and design decisions for new ones.
The Implementation Challenge
Build the system around the people who have to use it.
RMA data comes with inherent limitations. The data is as good as the input, and, as always, there is push and pull between teams. On the quality side, I wanted hundreds of specific defect and failure types to make my filtering extremely easy. The CX team is incentivized to process claims quickly. On a practical level, customers were often vague, did not provide specific reasons, or photos. It wasn’t realistic for the CX team to continue the exchange each time an RMA reason might not have been clear.
The theoretically perfect RMA system isn’t necessarily the operationally successful RMA system. The final taxonomy was a deliberate compromise. I reduced 176 potential reasons to 115, combining distinctions that were technically different but operationally represented the same underlying problem. Did every type of hardware need its own RMA reason, or could “Hardware” capture the issue while product images and returned samples provided the additional detail needed for diagnosis?
The Impact
The RMA system transformed warranty claims from individual customer anecdotes into a measurable source of product intelligence. It gave the team a way to prioritize the problems that mattered most, distinguish design issues from manufacturing and assembly problems, and track failure patterns over the life of the product. Several identified failure modes were significantly reduced in subsequent product iterations, while the resulting specifications and testing protocols became part of the standard development process for future luggage.
You can't manage what you don't measure. This work emphasizes that quantitative and qualitative data complement each other.
Key Takeaways
Design the system with CX, not for CX. Understand what customers actually provide and what the team can realistically capture without slowing claim resolution.
Standardize Terminology. Account for synonymous component names, ambiguous descriptions, and varying levels of specificity.
Interrogate anomalies before acting. In one instance, a seemingly frequent failure turned out to be the first alphabetical option automatically selected when an agent left the reason blank. Data collection behavior can look like a product signal if you don't investigate it.
Have a return or warranty problem like this one?
Most companies are sitting on more product intelligence than they realize. If your returns data isn't telling you anything yet, that's usually a structure problem, not a data problem.