A Bestselling Product Can Still Lose Money
Every retail owner we work with can name their top ten products without looking. They also know which products are sitting on a full pallet in the warehouse. Those two lists get attention every week because they are visible.
The margin leaks somewhere else. It leaks in the few hundred products in between: each one spending a little on ads, each one holding a little stock, each one selling a little. No single one of them is worth a meeting. Together they are the reason the company P&L looks fine and the bank balance does not.
A company P&L cannot see them. A channel dashboard cannot see them either, because the cost of each product is spread across five systems that have never been joined. Product-level P&L is the only report that tells a retail team what to change this week, product by product, and it is built from files the client already has.
What we joined
For an apparel brand selling on two marketplaces, the numbers needed for a product-level P&L already existed. They lived in five places.
| Source | What it contributes | Where it usually lives |
|---|---|---|
| Warehouse system | Stock on hand, inbound stock, receiving dates | The warehouse team's software, exported on request |
| Stock sheet | Cost price per SKU, restock lead time | An Excel file the founder maintains |
| Ad spend by product | What each product cost to promote this week | The ads manager on each platform |
| Orders per sales channel | Units and gross sales per product, per platform | Each platform's order export |
| Payout statements | What the platform actually paid after fees, commissions, returns | Each platform's finance or income report |
Nothing on that list is a new system. Nobody had to buy software. The new thing is the join: one row per product with units sold, gross sales, what landed, ad spend, cost of goods, profit, and weeks of stock cover.
What the first join showed
The day the data was connected, the table produced two findings before anyone asked it a question.
The brand's number one product by velocity had sold 2,280 units in seven days and had 16 units left. Restock lead time was six weeks. No platform dashboard shows sales velocity next to stock on hand, so nobody had seen it.
The same afternoon, the platform's statement was reconciled against the bank. RM413,000 billed, RM264,000 landed. A 20.4 percent effective take rate, on one screen, for the first time. The founder had been running the business on the first number.
Both findings came from joining two numbers that already existed. That is the whole method.
Why a human team cannot do this weekly
The brand carries 354 products across two platforms. Five sources, refreshed weekly, joined by SKU, is a full week of an ops person's time, done by hand, every week. So it does not get done. The winners get watched, the pallets get watched, and the long tail runs on memory.
Once the join is automated, the model does the categorising and the team does the deciding. One week's triage of 109 active products looked like this:
| List | Products | What the row says |
|---|---|---|
| Restock | 53 | Reorder quantity from velocity, lead time and cover target, minus stock on hand |
| Fix listing | 19 | Well stocked, traffic already paid for, converting below the shop baseline. The fix is on the product page, after the click |
| Campaign window | 6 | Stock cover decides what the campaign can still sell, because a new order cannot land before the peak |
| Pulled from rotation | 49 | Impressions fell below half the product's own run rate. Sales dropped because the product stopped being shown, so demand has not been tested yet |
Each row comes with the action already attached. The ops team reads the table on Monday and spends the week changing things, instead of spending the week building the table.
The weekly loop
This is where product-level P&L stops being a report and becomes an operating rhythm.
- Run the join on the last 30 days. One row per product, ranked by profit.
- Sort the long tail into moves. For each product with ad spend and no profit, pick one: change the content, change the creator (KOL), change the price, or cut the ads. One move per product per week, so the result can be read.
- Re-run next week. Compare the same products against last week's row. Velocity up, keep going. Velocity flat, try the next move.
- Four weeks, no movement, stop. Stop reordering and move the product into clearance. Your accountant will call that stock an asset on the balance sheet. It is cash that has stopped moving, and clearing it is the fastest working capital most retailers will ever find.
Only a product-level P&L can give instructions this specific. A dashboard tells you sales dipped. The table tells you which 49 products to put back in rotation and which 19 to fix on the page.
We have written before about why dashboards make decisions slower and why more data does not produce a point. This is the constructive half of that argument: the report that closes the gap is not prettier, it is one level more specific.
What it takes
Week one needs no build at all. Export the five files, upload them to ChatGPT or Claude, and use the analysis prompt at the end of our method post to get the first table. If the numbers surprise you, that is the sign the join is worth automating.
From there, the build is plumbing: connect the platform APIs, pull the five sources on a schedule, run the model, post the table to the team every Monday morning. The same brand's marketplace agency has written up how it reads two platforms in one model, including the restock the usual report nearly missed.
That is the shape of every retail AI project we take on. Audit the leak first, blueprint the join, build the loop. If you want to know what your own long tail is costing you, start with the audit.