Identified by frame number
The bike and its available activation information provide context.
CLAIM SYSTEM · PRODUCT MANAGEMENT
Improving the claim experience.
From requirements to launch.
I defined the claim journey and coordinated development, after-sales, and an external front-end team to deliver a clearer process for submitting, reviewing, and tracking claims.
Launched · Web · Dealer PortalSee what I changed ↓
01 / OVERVIEW
An after-sales platform
for e-bike dealers.
Claim System lets e-bike dealers file warranty claims and order replacement parts, and gives the after-sales team one place to review, manage, and ship every case.
I joined when the project had only initial requirements. As Product Manager, I developed the flows and specifications, aligned the internal teams and external vendor, and supported testing through launch.
- Role
- Product Manager
- Timeline
- September 2023 – February 2024
- Platform
- Web · Dealer Portal
- Team
- Software, after-sales & external front-end vendor
03 / THE PROBLEM
Incomplete information
made claim reviews harder.
In the previous process, dealers did not always provide the information needed to assess a claim. Missing part details and unclear fault descriptions required additional clarification before the after-sales team could proceed.
The team also needed to verify the claimed part against the bike configuration, review the available warranty information, and keep a record of replacement parts. I brought these needs together in the product requirements.
Information needed to review a claim.
- 01
Identify
Establish which bike and part the request concerns.
- 02
Understand
Collect a clear description and photos of the issue.
- 03
Review
Check the configuration and available warranty information.
- 04
Resolve
Communicate the decision and record the replacement shipment.
Review needs summarized from the project requirements.
04 / KEY DECISIONS
Define a clearer submission
and review process.
I organized the experience around the information dealers needed to provide and the decisions the after-sales team needed to make. The specifications connected submission fields, review rules, and case progress.
01
Connect the request to the bike and part
I defined how the frame number identifies the bike and how a part serial number or part number brings in the relevant component information. Available purchase and activation dates give the service team context for its warranty review.
Bike, part, and issue information in one step.
Identified by its record
The part serial number and purchase date support review.
Described in set fields
Claim type, optional error code, and a required description.
02
Ask for evidence up front
I included required part photos, a claim type, and a description in the submission requirements. These give reviewers more useful information at the start and help reduce requests for missing details.
03
Explain the next step after review
For claims rejected because the warranty has expired, the notification specification includes a link to purchase parts through Order. When information needs correcting, the revision flow lets the dealer update the existing claim and resubmit it.
04
Give after-sales one place to run every claim
I defined the claim states, the actions available to each role, and the information shown at each step. The service team can review and update a case while dealers follow its progress.
A shared view of claim progress.
- 01
Pending
The service team reviews the request and can ask for revisions.
- 02
Picking
Approved replacement parts are prepared for shipment.
- 03
Shipped
Shipment details and outgoing part serial numbers are recorded.
- 04
Completed
The case is closed with its history available for reference.
Main claim path. Requests needing changes return to review after the dealer revises the original claim.
05 / PARTS PURCHASE
Support parts purchases
alongside warranty claims.
Order supports replacement-parts purchases, including cases outside warranty coverage. I specified the purchase flow, payment states, and review actions so dealers and the service team could follow each order through payment and shipment.
With the reworked purchase process, payment success rose from 63% to 92%.
Order status, parts, and next actions on one screen.
Where the order stands
Current status and progress sit with the order.
What is being bought
Parts and costs stay visible during review.
What happens next
Approve, return for revision, reject, or cancel.
View the order state specification
06 / DELIVERY
Coordinate the teams
from specification to launch.
01
Align requirements across teams
I worked with after-sales, software, and the external front-end team to clarify the required behavior and maintain a shared reference as development progressed.
02
Write a spec an external team could build from
I wrote the PRD with user stories, flows, state rules, and permissions, and split the delivery plan into dated milestones between our software team and the vendor. I followed up on implementation questions and progress throughout delivery.
Turn the scope into dated handoffs.
The delivery plan assigned API work to Hyena and front-end work to the vendor, with separate target dates for each part of the workflow.
Case API
Create an order and provide its details.
Create actions
Build the claim and purchase submission interfaces.
Overview screens
Build the claim and order overview interfaces.
03
Test before QA to protect the date
With limited QA capacity, I tested each release during development and logged issues in Notion so the team could address them earlier. During QA, I ran and recorded additional test cases in Testmo alongside the team to support release verification.
Check the expected path—and the cases that should stop it.
I recorded the starting conditions, user actions, expected behavior, and observed results. These examples show how the claim requirements became concrete checks during development.
01 / VALID FRAME NUMBER · TC 1-3-3-1
Continue to the issue details
- Given
- A dealer enters a frame number that exists in the database.
- When
- The dealer selects Confirm.
- Expected
- The app opens the Add Issue Parts page.
Recorded result: Pass · Same as expected.
02 / UNKNOWN FRAME NUMBER · TC 1-3-3-2
Stop an invalid submission
- Given
- A dealer enters a frame number that does not exist in the database.
- When
- The dealer selects Confirm.
- Expected
- The app stays on the current page and displays an error message.
Recorded result: Pass · Same as expected.
03 / DUPLICATE PART · TC 1-3-3-8
Explain why a part cannot be added again
- Given
- A dealer enters a part serial number already included in the form.
- When
- The dealer selects Add.
- Expected
- An error snackbar states: “This serial number already exists in the form.” It disappears after five seconds.
Recorded result: Pass · Same as expected.
07 / REFLECTION
Connect user needs
with operational requirements.
My contribution covered the full path from initial requirements to launch: defining the experience, documenting system behavior, coordinating delivery, and testing the product with the team.
01
Design for both sides of the claim
A clear submission helps the dealer explain the issue and gives the service team a better starting point for review. Progress and revision instructions help both sides understand what happens next.
02
← Back to selected work
Keep specifications connected to testing
Reviewing the implementation against the agreed flows helped surface gaps and gave the internal team and vendor a concrete basis for resolving them.