Fix the returns your product pages cause, first
Some returns are about the courier or a change of mind, and no product page touches them. Others are about a fact the shopper needed and could not find. This puts four Pulse products in order: find the facts your catalogue leaves out, see which of them go with returns, repair those first, and check the returns actually moved.
Built from Decision Audit · Return Verification · Decision Verification · Decision API
- 01Decision AuditThe facts your catalogue cannot answer
- 02Return VerificationWhich of those go with returns, from the reasons given
- 03Decision VerificationThe catalogue re-measured after the repair
- 04Decision APIRanking for purchases that stay bought
Each one works on its own. In this order a return reason becomes a repair, and the repair gets checked.
Your returns already say what the listing left out
Every return comes with a reason: too large, not as described, does not work with my device. Most teams read those as one rate to drive down, and the reasons sit in a report nobody joins back to the product page.
Meanwhile the catalogue team works through missing fields in whatever order the spreadsheet gives them, so the fact behind next month's returns may be the last one filled.
A return rate says something went wrong. The reason says what to fix.
- How many orders came backAnswered
- Which returns a product page could have preventedNot on the dashboard
- Which missing fact each one points toThe dimensions, the compatibility, the materialNot on the dashboard
- Whether last month's repair moved themNot on the dashboard
1 of the four is answered by a return rate.
Not every return is yours to fix
Each return reason is read for the product fact it names. The ones a listing could have prevented are compared; the rest are counted and set aside, and vague codes are measured rather than guessed.
- ✓Yours to fixThe reason names a fact the listing left out
- ✕Set asideTransit damage, a wrong item, a failed delivery, a change of mind
- ?UnclearVague reason codes, measured and reported, never guessed
Which products, in what order
Each step is a Pulse product you can use alone. The order is what turns a return reason into a repair that gets checked.
- 01Decision Audit
Find the facts the catalogue cannot answer
One category of your catalogue, measured against the questions shoppers ask in it. The missing facts come back ranked, with the products each one affects.
- 02Return Verification
See which of them go with returns
Send six to twelve months of orders with the return reason. Return rates are compared between products that record each fact and products that do not, within the same brand and price band.
- 03Decision Verification
Repair those first, then re-measure
Your team fills the facts that go with returns before the rest. The catalogue is measured again, and Return Verification compares the repaired products with similar ones that were not, over the same weeks.
- 04Decision API
Rank for purchases that stay bought
The same history can rank products by how often they come back for a fixable reason. It is off until you send history, and a share of shoppers never sees it, so the effect can be measured.
What changes about the repair list
Returns split into yours and not yours
Transit damage, counterfeits, a wrong item sent and failed deliveries are counted and set aside. Only returns a product fact could have prevented are compared.
A repair list ordered by returns
The missing facts the audit found, with the ones that go with returns at the top, each with an interval and the one sentence the result supports.
Proof a repair moved the right returns
A matched comparison against unrepaired products over the same period, so a season or a promotion does not take the credit.
Ranking that learns from returns
With the Decision API, products that keep coming back for a fixable reason rank lower until the listing is repaired.
What this does and does not do
What this does
- Find the facts your catalogue leaves out, and which of them go with returns in your own orders
- Order the repair list by the returns each missing fact goes with
- Verify whether a repair moved the returns it was meant to move
- Say when there are not enough orders to tell, instead of guessing
What it does not do
- Promise fewer returns. Nothing has been measured on your orders yet, and a result from another shop is not evidence about yours
- Treat every return as fixable. Transit damage, fraud and failed deliveries are not product information
- Write the missing facts for you. We say which are worth having and where they already live
- Predict which shopper will return something. It reads products and reasons, not people
The ones that decide it
- Do I need all four products?
- No. Return Verification alone shows which missing facts go with your returns. The Decision Audit finds the facts to look at, Decision Verification re-measures after a repair, and the Decision API ranks with what was learned. Most merchants start with one category.
- How is this different from the Return Verification page?
- Return Verification is one product: returns joined to your catalogue. This page is the goal, and shows where it sits next to the products that find the gaps before it and act on the result after it.
- What data do you need?
- One category of your catalogue and six to twelve months of orders: the product, the order date, the return date, the return reason, and the payment method if you have it. No personal data of any kind.
- How much will our returns fall?
- We will not give you a figure, because nothing has run on your orders yet. What it gives you is which returns your product pages could have prevented, and whether a repair moved them.
Send one category's orders and return reasons
Six to twelve months, no personal data, and a repair list ordered by the returns behind it.
It runs on exports. Nothing goes on your site.