Warranty registration in the after‑sales cycle
It was meant to be the digitisation of a post‑sale satisfaction form. The question “how do I know this is really the customer?” changed the course of the product. The end customer became the force that makes the franchise regularise the sale.
- My role
- Product Designer
- Duration
- 4 months
- Teams
- Design + Engineering
- Platform
- Web
Context
The response card was a paper post‑sale satisfaction form. Questions about the purchase and the installation, which the customer mailed back once the pool was finished. None of them had anything to do with warranty.
In 2025, the return rate of the paper card was 0.63%. The initial scope was to take that form off paper so it would no longer depend on physical mail to the franchisor.
My role
I was the only designer on the project and there was no PM. Prioritisation and product rationale were mine as well.
- I did
- Research · information architecture · flows · prototypes · handoff
- I shared
- Legal validation with the legal team; scope with leadership
The problem
The stated problem was small. Almost nobody sent the card back. But while designing the digital version a banal question turned up. How do we know the person answering is really the customer? The answer came from the warranty, through the number and the purchase date. That thread led to the real problem.
The warranty is a legal obligation and it starts at the sale, but it only came into force when the franchisee finalised and linked the sale in the system. In 2025, out of every 100 iGUi pools sold, 2 reached the state of a correctly linked warranty. 74.3% were never even registered.
Process
-
Listening
I talked to four internal areas and cross‑checked against the sales dashboards. The scope was still only taking the satisfaction form off paper.
-
The turn
The answer to identity was in the warranty. Number and purchase date became the key, and the project turned into another one.
-
The thread
Tying the answer to a real sale exposed how many sales were never finalised. The satisfaction form became the front door to an operations problem.
-
Handoff
Prototype in Figma, and the journeys specified in a document.
Decisions
-
The warranty itself identifies the customer
Warranty number plus purchase date tie the answer to a real, traceable sale. It was only an authentication solution, and it repositioned the whole product.
-
The warranty is the customer’s excuse to get the sale finished
Neither rules nor internal pressure made the franchisee finalise the sale. The customer wants their warranty working, and that is the strongest incentive in the chain. By answering, they trigger the check and force regularisation before moving on.
-
Fields open as the sale allows
The fields are progressive. The customer does not need to understand the internal complexity of the system to complete the flow.
-
The broken state became the main path
In the initial measurement, a finalised and consistent sale was the minority scenario. I treated inconsistency as the primary journey. Each message says what happens next, not just what went wrong.
Results
+85%
Monthly rate of responses
Paper 12 months vs. digital 5.5
~7x
Corrections per week
From fewer than 1 to about 7
92.3%
Conversion of those who enter the flow
Of every 100 who open the form, 92 finish · Jan to Jun 2026
What I took away
A small project can turn into another one along the way. Here, a question of identity changed everything, and it showed up while I was designing the screen. Studying the problem from a distance, I would not have reached it.
One thing I would do differently: I would have defined the metrics before launching. Ticket logging only came in weeks after go‑live, and that left a blind spot right at the start of the measurement.
An exception should not always be treated as a detail. The product created value precisely on the path of inconsistency.
Next project
Redesign of the self‑service kiosk