Somewhere in your data, the same product goes by four different names. In Shopify it’s PFT-15. In Amazon it’s AMZ-PFT-15. At the retailer it carries their item number, not yours. In the 3PL export it’s whatever someone typed into a form two years ago.
Every one of those rows describes one physical product sitting on one pallet. No system you own knows that. Which is why most consumer brands forecast by product family instead of by SKU, and why demand planning so often lives in a spreadsheet beside the financial model rather than inside it.
Today we’re launching product mapping in Drivepoint. It reads the product rows across your connected channels, consolidates them into one clean list, shows you its work before it commits anything, and writes the result to your data warehouse where every model, report, and forecast can reach it.
How it works
1. It maps
Point it at your connected channels and it groups the product rows into products. On a recent run for Simply Fuel, 179 source rows came back as 40 products. It handles the things that break hand-built mappings: channel prefixes, size and flavor variants, and bundles.
2. It shows you the work
You get the proposed mapping as a reviewable list before anything is saved. Correct what is wrong, and re-run the pieces you do not like. Nothing is written until you approve it, because a product list that silently reorganizes itself is worse than no product list at all.
3. It saves somewhere useful
Approve the mapping and it goes into your data warehouse, not a file on someone’s desktop. A new import option appears in the Drivepoint Excel add-in, so your model pulls the clean product list directly. Your VLOOKUPs point at something real, and your demand plan and financial forecast finally reference the same products.
From there you can sort, filter, and group your full product list by type, status, SKU, family, category, or variant in the products view.
What this unlocks
The mapping is not the point. What sits on top of it is.
SKU-level forecasting instead of family-level
We work with a brand where 80% of revenue comes from twelve SKUs. Forecasting them as a product family tells you almost nothing you can act on. It hides which twelve are carrying the business, which are quietly dying, and which is about to stock out in the channel with the best margin. Once the product list is clean, the forecast can go one level down, and it can live inside the financial model rather than beside it.
Demand planning that spans channels
Total demand for a week or a month is unanswerable when the same product has four names. With one list, it is a query.
Sell-in versus sell-through you can actually compute
Knowing what you shipped a retailer is easy. Knowing what moved off the shelf requires their product names and yours to be reconciled. That reconciliation is exactly this.
Map your products, use a demand planning template, and most of the work is already done.
Why an agent is good at this specific job
SKU reconciliation looks like a data problem. It is really a pattern recognition problem, which is the kind of thing agents handle well. An agent reads AMZ-PFT-15 and recognizes the channel prefix for what it is. It sees size variants of the same product as variants rather than as separate products.
The best illustration came mid-run. The agent was working through a top-SKU list, stopped itself, and flagged that one of the SKUs it had just listed was actually a bundle rather than a single product. It caught its own mistake and broke the bundle into its components.
Bundles are exactly where hand-built mappings go wrong, because a bundle looks like a SKU in every export and behaves like three SKUs in your inventory. Catching that unprompted is the difference between a tool that saves you an afternoon and a tool you would trust with a number you are taking to your board.
Could I just do this in Claude?
Partly, and we would rather say so than pretend otherwise. Paste an export into Claude and you will get a reasonable first pass at grouping product names.
But grouping names is the easy half. The hard half is knowing what the names mean.
Retailers do not treat SKUs the same way as each other. Each has its own item numbering, its own fields, its own conventions for how a product gets identified in the data they send back. We integrate that retail data, so the structure is not something an agent has to reverse-engineer from a string. It is already known.
Brands run the same problem in the other direction. A SKU is rarely just an identifier. It usually encodes something: flavor in one segment, pack count in another, size in the middle, channel on the front. Two brands can use the same character in the same position to mean entirely different things. Reading that correctly is the difference between 40 clean products and 40 confident mistakes.
That knowledge came from doing this work by hand across a lot of consumer brands, and it lives in the platform rather than in a prompt you would have to rewrite every time.
Then there is everything after the mapping. It has to persist somewhere your model can read from, which means a warehouse and not a chat window. It has to survive next month, when you have added four SKUs and nobody remembers the prompt. And when it changes, the change has to reach everything downstream of it.
Getting from a good first pass to that is not more prompting. It is building software. Claude is the engine here; the car is everything around it.
What comes next
A clean product list is the foundation for unit-level reporting that reconciles across channels, and it is what makes SKU-level financial forecasting practical rather than aspirational.
It also points at the harder problem underneath. Brands like Nanit map components as well as finished goods, which is how a plan tells your factory how many lenses, caps, and bottles to order and by when. Dose Daily ran an entire schedule just for glass bottles and caps. That is materials and resource planning, and it is where this is heading.
Your forecast is only ever as good as the product list underneath it.
See it for yourself
Product mapping sits inside the wider Drivepoint platform, alongside the financial model, the demand plan, and the reporting that all read from the same product list.
The fastest way to understand how that fits together is to try it. Our Claude walkthrough takes about five minutes and runs on sample data from a fictional brand, so there is nothing to connect and nothing to set up. No sales call, no credit card.
Product mapping, answered
What is product mapping?
Product mapping is the process of reconciling the different names, SKUs, and item numbers a single product carries across your sales channels into one canonical product list. A coffee brand might have the same roast listed under a Shopify SKU, an Amazon ASIN with a channel prefix, and a retailer item number that shares no characters with either. Product mapping identifies those as one product so demand plans, forecasts, and unit reporting all count them once.
Why does the same product have a different SKU in every channel?
Because each channel was set up at a different time, often by a different person, under different constraints. Marketplaces impose their own identifier formats. Retailers assign their own item numbers and send data back using those, not yours. Internal SKUs accumulate conventions over years, encoding flavor, size, or pack count in positions that made sense to whoever created them. None of this is bad practice, it is just what happens when a brand grows across channels.
Can I do product mapping in a spreadsheet?
Yes, and most brands do. The problem is not the first pass, it is everything after it. A spreadsheet mapping goes stale the moment someone launches a flavor, it lives in a file that one person understands, and nothing downstream knows when it changes. The forecast built on top of it inherits all three problems.
How does product mapping handle bundles?
Bundles are the most common failure point in hand-built mappings, because a bundle looks like a single SKU in every export and behaves like several SKUs in your inventory. Drivepoint's product mapping is built to recognize bundles and break them into their component products rather than counting them as one item.
How often should product mapping be re-run?
Any time your product catalog changes: a new SKU, a new flavor or size, a new channel, or a new retailer. Many brands settle into a regular cadence, reviewing the mapping on a set schedule so it never drifts far from the catalog it describes.
.png)