Warranty claims without phone tag: a claims portal and protection plans on Magento

For a retailer of big-ticket goods, warranties matter twice. Protection plans are sold with the product, and months later the same customer comes back with something damaged or broken. When plans are priced wrong online and claims arrive as phone calls and loose email photos, both the sale and the after-sale suffer.

We built both halves for a multi-location retailer on Mage-OS and Hyvä: protection plans sold on the product page at each store's real price, and a warranty claims portal with a store-by-store triage queue for staff.

The challenge

Plan prices differ by store: protection plans are priced in the retailer's ERP per location. The website had to offer the shopper's own store's price and never a price from another store.
A plan must never block the sale: if a plan product is temporarily unavailable, the customer still has to be able to add the product itself to the cart.
Different products, different plans: whole-order protection, single-product care plans and tiered plans each work differently in the cart.
Most claimants have no web account: many customers bought in a showroom, so the claim process could not depend on logging in.
Staff need evidence: photos of the damage, the serial number or law tag, and the original order, without chasing the customer for each one.
Claims belong to stores: each location handles its own claims, and staff should see only theirs.
The official process lived in a PDF: which path a claim takes (supplier issue, protection-plan provider, not covered) and what to do next was written down, but not in any tool.

What we built

Protection plans on the product page

A plan drawer on the product page: the right plans for the product type, whole-order protection for sets, care plans for single products and tiered plans by price.
Store-accurate pricing: plan prices come from the ERP for the shopper's selected store. A plan without a price at that store is not offered at all, so nobody is shown a free plan by mistake.
Cart behaviour that holds up: plans follow the quantity of the item they protect, switching plans replaces the old one rather than adding a second, and a plan picked while editing a cart line is added too.
Fail-safe add to cart: if a plan cannot be sold for any reason, the product is still added without it and the problem is logged for staff.

The warranty claims portal

A claim form for customers: contact details, the store, the order or invoice number, a description, an optional serial number with a hint to photograph the label, and photo upload by browsing, dragging or pasting. At least one photo is required.
Protection-plan routing: the form asks whether the customer bought a protection plan. If they did, it shows the plan provider's direct contact details, and still lets them submit the claim.
A status page with no account: customers check progress with their reference number and email, or with one click from a signed link in every email. The status text is written for customers, and internal notes never show.
A triage queue for staff: an admin grid with filters by store, status and claim type, where each user sees only their own stores' claims.
Clear outcomes: statuses that separate an approved repair from an approved replacement, internal notes, and an automatic note for every change.
A "what to do next" panel: the retailer's official claims procedure, built into the claim page as concrete steps for each claim type and status.
Age against a target: every open claim shows its age against a configurable target (15 days by default), shifting from green to yellow, orange and red as the deadline nears.
Order details from the ERP: staff see what the customer actually bought, from the ERP's open orders, posted invoices and shipments or from the Magento order, with any protection-plan lines highlighted and a clear banner saying whether the order includes a plan.

How it works

The plan is sold. On the product page the shopper opens the plan drawer, sees the plans and prices for their selected store, and adds one with the product. The plan rides along in the cart and the order like any other line.
Something goes wrong. The customer opens the claim form on the website (the store's chat assistant links to it too), fills it in and attaches photos.
The claim is checked and stored. The server validates every field and every photo (type, size and content, never trusting what the browser says), filters out bots, and saves the claim with a reference number. Photos are stored privately and are only ever shown to signed-in staff with access to that store.
Everyone is told. The customer gets a confirmation email with a status link, and the store's inbox gets the claim details. Emails go through the store's shared email queue, so a slow mail server never slows the form.
Staff triage. A team member opens the claim, sets its type, reviews the photos and the order details pulled from the ERP, and follows the "what to do next" steps for that path.
The customer stays informed. Each status change sends one email per transition, with the status link, and the status page always shows where the claim stands.
The claim closes. It ends as a repair, a replacement, resolved or denied, with a full history of notes and changes on the record.

Under the hood

Mage-OS (Magento 2 open source): custom modules for protection plans and for warranty claims, built on Magento's own cart events, view models, admin grids and access control.
Hyvä theme: the plan drawer, the claim form with its photo drop zone, and the status page are Hyvä templates with Alpine.js components. The pages stay fully cacheable, because customer-specific data loads separately.
The retailer's ERP (Microsoft Dynamics NAV): the source of per-store plan prices and of the order, invoice and shipment details shown on each claim, read through its web services.
The store-pricing layer: the same per-store context the rest of the website uses, so a plan's price always matches the selected store.
An email queue and cron: claim emails are queued, deduplicated per status change and sent by a scheduled job, using the store's branded email layout.
Store-scoped admin access: the claims grid uses the same access model as the retailer's other store reports. A user with no stores assigned sees nothing.
Abuse protection: rate limits on the form and the status lookup, a bot trap, and a lookup that gives one generic answer for every failed attempt.
Tests: the claims module was built test first and carries around 60 automated unit tests. The plan module has its own suite.

What it changed

The protection-plan work runs on the retailer's live store. On the live site, plan drawers that had shown no usable price now offer each store's real tier prices. The claims portal is built and tested in staging and goes live when the retailer is ready, so we have no claim-volume figures yet. This is what the retailer can now do:

Sell plans at the right price: every plan online carries the shopper's own store price, and a plan without a price is never offered.
Keep the sale safe: a problem with a plan can no longer stop a customer adding the product itself.
Take claims around the clock: customers file a complete claim with photos, at any hour, without an account.
Cut down on follow-up: customers check their own status, so staff spend less time answering "any news on my claim?"
Follow one process in every store: the official procedure is on the screen for each claim type, and the age badge shows which claims are at risk of missing the target.
Have the facts at hand: staff see the original order and whether it included a plan without switching systems.

Could this work for you?

This fits any business that sells products with a warranty or a service plan and handles claims afterwards:

retailers selling protection plans on big-ticket goods;
electronics, bike and outdoor stores with extended warranties;
multi-location retailers whose stores handle their own after-sales service;
manufacturers and distributors who receive claims from end customers and need photos and serial numbers up front.

We build these systems on Mage-OS and Hyvä, connected to the ERP you already run. If your store is still on Magento 1 or an older Magento 2, we can move it first: see our Magento 1 to Mage-OS and Hyvä migration, our Magento 2 to Mage-OS and Hyvä upgrade, or all migration options.

See everything we offer on our services page, or tell us how you handle warranties today and we will tell you how we would approach it.