Five SKU strings. One product. One pile.

The problem, in one line

Five SKU codes for one product — the shape every seller ends up with after a year of listings, renames and pack variants:

Acme_2 Ply_100 Pcs ( Black )
Acme_Black_100 ( WN )
Acme_Black_100 Pcs ( With Clip )
Acme_Black_STD_100
Acme_PK_Black_100

One box. One shelf. One bag to pack from. Sort by the exact SKU and they land in five separate runs, and the packer walks to the same shelf five times.

Group them once as Black-100 and every batch from then on prints them as a single run of fifty labels.

How the suggestions are worked out

Two passes, in order of how much they can be trusted.

1. Colour and pack size

A colour word and a pack quantity are pulled out of each SKU, and SKUs with the same pair are bucketed together. This produces names you recognise —Black-100, Blue-50 — and it is the pass that catches most of a real catalogue.

It knows that "3 Ply" is not a pack of three. Below ten, a number in a SKU is far more likely to be a ply, a size or a layer count than a pack size, so a labelled number wins and a small unlabelled one is passed over.

2. Shared distinctive words

Whatever is left is clustered on the words two SKUs have in common — after throwing away the words that appear in most of them, because those are the brand name and boilerplate, not a signal. A brand name appearing in every single SKU tells you nothing about which ones belong together.

What sorting by product gives you

• One walk to the shelf per product, not one per listing
• The longest run first, while you are fresh
• A printed divider page between groups, if you want one
• A pick list whose totals are per product, not per SKU string
• Orders wanting more than one piece held back into their own block at the end, so they are never packed on autopilot as singles

Why suggesting them matters

Grouping is not unique — at least one other free tool does it, and does it well. What differs is who does the work. Everywhere else you are handed an empty mapping file and asked to assign a parent to every SKU you own. On a catalogue of a hundred codes that is an evening before a single label is sorted, and it has to be repeated whenever you add a listing.

Here the suggestions arrive already made, ordered by how many labels each is worth, and new SKUs get proposed against your existing groups the next time they appear in a batch. You are confirming a guess rather than doing data entry. The full comparison →

Built once, reused every morning

The groups are the valuable part. Labels are a day's work and gone by evening; the groups are months of knowing your own catalogue. They are kept in your browser, one set per marketplace, and you can save them to a file and carry them between machines. That file is the same format the desktop version reads, in both directions — this is deliberately not a lock-in.

Common questions

How is this different from sorting by SKU?

Sorting by SKU puts identical SKU strings together. One product often carries several SKU strings — different listings, different packs, a rename, a typo — and sorting by the string splits one shelf into several runs. Grouping says which strings mean the same thing, once.

Do I have to build the groups by hand?

No. It reads your own SKU names and suggests groups from them — first by colour and pack size, then by the distinctive words two SKUs share once the brand name is discounted. Nothing is applied until you accept it.

Where are my groups stored?

In your own browser, one set per marketplace. They are never sent anywhere. You can save them to a file and load them on another machine, and the file is the same format the desktop version uses.

What order do the groups print in?

The order you arrange them, top first. Inside each group the longest run prints first, so you pack the big pile while you are fresh, and ties fall back to alphabetical so the order never wobbles between runs.