Product Data Sheet Template

A product data sheet template is the multi-product version of a spec sheet: one row per product, one column per field, a whole range in a single file. It is the format most suppliers send and most systems accept, which is exactly why it goes wrong so often. Everyone assumes it is the easy one.

The file that lands is usually readable by a person and unusable by a system. Sizes concatenated into one cell, a heading row halfway down where a new brand starts, units typed into value cells, and a colour key nobody documented. Each of those is a small decision made by someone trying to be helpful, and each one costs a day.

What is in the product data sheet template

Two tabs. A How to use this tab written for the supplier, and a Products tab with twenty two columns.

Six columns are marked required: supplier part number, product name, brand, GTIN, pack quantity and unit of measure. Those six are the minimum for a product that can be received, priced and identified. Everything else improves the record; those six decide whether there is a record at all.

The remaining columns cover parent SKU, category, short and long description, colour, size, material, the three dimensions, weight, country of origin, commodity code, and three URL columns for images and the datasheet.

One row per sellable item

This is the rule the whole file depends on.

If a bracket comes in three lengths, that is three rows. Each has its own supplier part number, its own barcode, its own weight and its own price. They share a parent SKU, which is how the three rows get grouped back into one product with a size selector on the website.

The failure is a single row with 300mm / 400mm / 500mm in the size column. It looks efficient. It cannot be sold. Nothing downstream can generate three listings from one row, so somebody rebuilds it by hand, and halfway through that job it turns out the barcode for the 400mm version was never collected because there was only ever one barcode cell.

The same applies to colour, voltage, pack size and anything else a customer chooses between. If the customer picks it, it is a row.

Getting the parent SKU right

The parent SKU column groups variants. The variant axis is whatever genuinely differs between them.

Two rows sharing a parent SKU that differ on nothing are a duplicate, and they will both go live. Two rows differing on three axes at once usually mean the family has been modelled wrongly and should be two families.

Decide the axis before the file is filled in. Changing it afterwards means rebuilding every relationship, and on a range of any size that is a week nobody planned for.

Five formatting rules that decide whether the file imports

No merged cells. A merged cell has one value and several addresses. Every parser resolves that differently, and the ones that resolve it silently are worse than the ones that fail.

No second header row. Subheadings that split the sheet into sections, a row reading "ACME PRODUCTS" before the Acme lines, are read as products. You get a product called ACME PRODUCTS with no price and no barcode, and it goes live.

No blank rows between groups. Many importers stop at the first blank row and report success. Nine hundred rows in the file, four hundred in the system, no error anywhere.

No colour coding as meaning. Yellow for "check this one" is invisible to every system that reads the file. If the status matters, it needs a column.

No units inside value cells. The unit belongs in the column heading, which is why the template ships with Length (mm) and Weight (kg) rather than bare Length and Weight. A column holding 300mm is text. A column holding 300 is a number.

The columns people skip, and what it costs

Pack quantity and unit of measure. Without both, a price is meaningless. Twelve pounds per what. This is the most common cause of a margin calculation being wrong by a factor of six.

Country of origin and commodity code. Nobody fills these in until a customs declaration needs them, at which point the supplier has moved on and the person who knew the answer has left.

GTIN. Without it a product cannot be listed on most marketplaces at all. Chasing it when the file arrives costs one email. Chasing it four months later, when a marketplace launch is two weeks out, costs a marketplace launch.

Additional image URLs. One per line in the cell, not comma separated and not all in the primary column. Most import routines split on line breaks.

Sending the data sheet template to a supplier

Delete the example row first. It is there so the format is obvious, and suppliers copy it if you leave it in.

Cut the columns you do not need. A supplier looking at twenty two columns where fourteen apply will fill in the fourteen, but they will spend the first ten minutes deciding which fourteen, and that hesitation is where completion rates go.

Tell them what happens next and by when. "Please complete and return" produces a file in three weeks. "We are listing this range on the 14th, anything missing a barcode does not go live" produces a file on Friday.

Accept the data in whatever form they already hold it. If the specs live in a PDF, take the PDF. Asking a supplier to retype their own data into your columns is the step that creates both the delay and the errors.

Validate on arrival, not at import

Import is the expensive place to find problems. By then the file is three weeks old, the person who filled it in has moved on, and the fix involves a conversation that starts with explaining what a GTIN is.

Checking the file the moment it arrives, against the fields you actually need, and replying with the specific rows and columns that are missing, turns a three week loop into a same day one. It also changes the tone of the exchange, because you are pointing at row 47 rather than at the supplier.

That is the argument for a supplier portal over an email attachment, and it is most of what a supplier onboarding process is actually for. Portals that validate at submission see first pass completeness well above what a master spreadsheet returns, mostly because the supplier finds out immediately rather than eventually.

When one spreadsheet becomes forty

A product data sheet template works while there is one file, one supplier and one person looking after it. It stops working at the point where every supplier sends their own version of it, on their own schedule, with their own column names.

At that point the job is no longer filling in a template. It is mapping forty different shapes onto one structure, every time they change, and doing it fast enough that the range review does not slip. SKULaunch does that mapping: it reads whatever the supplier sent, matches their columns to yours, flags what is missing against your required set, and hands back records rather than files.