Your new line form is a spreadsheet. It has somewhere between forty and two hundred columns. There is a hidden tab nobody has opened since the person who built it left. The filename ends in v4_FINAL, and the version number stopped incrementing three years ago. A buyer emails it to a supplier. The supplier fills in what they can and guesses the rest. Someone in merchandising fixes it by hand. That loop is where speed to market goes, and it is the same loop in almost every distributor we work with.
What a new line form is actually for
Strip away the history and the form has one job. It is the contract between the commercial decision to stock something and the data needed to sell it.
That is a genuinely hard document to write, because it sits across four functions. Buying agrees the terms. Supply chain needs the pack data. Finance needs the codes. Ecommerce and marketing need the content. Each of them has added a column at some point, and none of them has ever removed one.
So the form drifts. It grows by accretion, never by design, and it ends up encoding a data model that was never written down anywhere else. That is the real problem, and the six failures below are all symptoms of it.
Failure one: one form for every category
The single form is the original sin. A distributor selling cable, PPE, hand tools and fixings has one new line form covering all of it, because building four felt like more work.
The result is a document where most columns are irrelevant to most products. A supplier setting up a box of nitrile gloves faces columns for conductor material, IP rating and thread pitch. They leave them blank, which is correct. They also leave EN standard and cuff length blank, which is not, because those columns are lost in the noise.
You cannot tell the difference afterwards. A blank cell means “does not apply”, “do not know” or “did not see it”. The form gives you no way to separate them. Every downstream chase starts from zero.
The fix is category-scoped forms driven by your attribute schema. Not four forms, necessarily. A form per category group, generated from the node the buyer picks, with only the fields that node actually requires. If your product attributes are scoped properly by node, this is a generation problem rather than a design problem.
Failure two: three jobs in one document
Commercial terms, logistics data and product content are three different jobs. Different owners, different lead times, different consequences for being late.
Cost price and rebate terms come from the supplier’s commercial contact and are usually agreed before anything else. Pack dimensions, weights and hazard classes come from their operations team. Descriptions, features, images and technical specifications come from marketing, or from a datasheet, or from nobody.
Putting all three on one sheet forces the slowest to set the pace. The supplier cannot return the form until marketing has written copy. So the buyer chases the whole document while the ERP fields sit finished in a draft.
We split these. Terms and logistics on a short form that gates the buying decision. Content on a separate, later collection with its own deadline, tied to the launch date rather than the contract date. The product can be created, ordered and stocked while content is still being enriched. That single change usually does more for lead time than any technology.
Failure three: free text where a list belongs
Open any returned new line form and look at the colour column. Blue. BLUE. Navy blue. RAL 5010. Dark Blue/Black. All in the same field, all from the same supplier, sometimes on the same tab.
It happens because the cell is free text and nobody told the supplier otherwise. Units are worse. A length column with no unit will come back containing 500, 0.5, 500mm and “50cm approx”. Somebody then has to work out which is which, usually months later, usually wrong.
The fix is not complicated and it is not a portal. It is data validation on the cells and a value list per attribute. Units go in the column header or get a column of their own. Every select attribute needs its list defined before the form goes out, and the list needs to be short enough that a supplier reads it.
The hard part is not the validation. It is agreeing the value lists, which is the same job as defining the attribute schema. That is why this work belongs with taxonomy and attribution rather than with whoever owns the spreadsheet.
Failure four: no variant model, so one row per SKU
Most new line forms are flat. One row, one SKU. That works for a single item and falls apart on a range.
A supplier launching a glove in five sizes and three colours has fifteen rows. The description, the brand, the standards and the features are identical across all fifteen. They copy and paste, and by row nine something has drifted. Now you have three descriptions for one product and no way to know which is right.
The other version of the same failure is the range row. One row for the whole product, with sizes listed as “S, M, L, XL, XXL” in a single cell. That is fast for the supplier and useless to you, because there are no SKUs, no GTINs and no way to sell it.
What works is a two-part structure that matches how you actually hold the data. A product sheet with the shared content, one row per product. A variant sheet with one row per SKU, carrying only the variant axes, the identifiers and the pack data. The supplier fills in far less, and you get a structure your PIM can take without a transformation step.
If your form has no concept of a variant, your suppliers are inventing one for you. They are not doing it consistently.
Failure five: nothing is ever rejected
Ask a distributor what happens when a new line form comes back forty per cent complete. The honest answer is that it gets accepted, because the line has a launch date and the buyer has a target.
So the gap moves downstream. It surfaces at PDP build, when someone finds there is no image, or at the first customer complaint about a wrong dimension. By then the supplier contact has moved on and the buyer has other priorities. Fixing it costs several times what it would have cost at the gate.
A gate only exists if something can fail it. That means a written acceptance test. Which fields are mandatory for this category, what counts as a valid value, and what happens on a fail. Not a scoring rubric. A binary answer and a return with the failing rows highlighted.
The objection is always commercial. We cannot hold up a line over a missing attribute. Sometimes true, and the answer is an exception route with a named owner and a date, not a silent pass. What you cannot have is a process where the standard is whatever arrived. We build this gate into every supplier data onboarding programme, because without it the rest of the process is decoration.
Failure six: it is a file, not a process
This is the one MDs feel most directly. It generates the questions they cannot answer.
Where is that line? Who has it? How many are outstanding this month? How long did the last thirty take? When the form is an email attachment, none of those questions has an answer. Status lives in someone’s inbox, and the audit trail is a thread.
Version drift follows. Two people send the supplier different copies of the form. The supplier fills in the older one. Someone merges them by hand. Meanwhile a column added last quarter is missing from half the returns, and nobody notices until the category review.
This is where a supplier portal genuinely earns its place, and it is also where distributors overreach. More on that below. The minimum viable version is not a portal. It is a register: one row per line in flight, with supplier, category, date sent, date returned, gate result and current owner. A shared sheet will do. What matters is that the status exists somewhere outside an inbox.
The root cause: nobody owns the specification
Six failures, one cause. The new line form is a document, and the data model it encodes lives in people’s heads.
Nobody owns it. It has no version history worth the name, no change process, and no relationship to the attribute schema in the PIM. When the PIM gets a new mandatory field, the form does not learn about it. When a category is restructured, the form does not learn about that either.
That is why fixing the form as a document never sticks. Six months later it has drifted back, because the same accretion pressure is still there and there is still no owner to push back.
The form should be an output, not an artefact. Generated from the attribute schema for a given node, versioned with it, and regenerated when the schema changes. Once that is true, most of the six failures become impossible rather than merely discouraged.
How to fix a new line form, in the order that matters
Sequence matters here, because doing these out of order wastes the effort.
- Write the attribute specification first. Per category node: field name, type, unit, value list, mandatory or optional, and who is expected to supply it. This is the actual work. Everything else is presentation.
- Split by job. Terms and logistics on the gating form. Content on a later collection tied to launch date.
- Scope by category. Generate the fields from the node. A supplier should never see a column that cannot apply to their product.
- Add validation at the point of entry. Value lists, units in headers, mandatory checks in the file itself.
- Add the variant structure. Product sheet and variant sheet, so nobody copies a description fifteen times.
- Write the acceptance test and use it. Binary, per category, with a named exception route.
- Give it a status. A register at minimum, with the dates you need to answer how long this takes.
Steps one to three are where the return is. Most teams start at step seven, buy a portal, and load the same broken specification into it.
When a new line form does not need replacing
We are not going to tell you the spreadsheet has to go. For a large number of distributors it does not.
A well-specified Excel form with validated cells, category scoping and a real acceptance gate outperforms a supplier portal that suppliers refuse to log into. That refusal is real, particularly with small manufacturers and with overseas suppliers who deal with forty distributors and will not learn forty systems. A portal that gets a thirty per cent adoption rate has made your process worse, because now you run two.
The case for replacing the file gets strong at three points. When volume is high enough that the register becomes the bottleneck. When you need supplier self-service for updates rather than just new lines. When your largest suppliers can send structured feeds and you want to stop asking them for spreadsheets they generate by hand from the same system.
Even then, the sequence holds. Specification first, channel second. Your best suppliers should send a feed. Your mid-tier should get a validated template. The long tail gets whatever route actually produces data. Trying to force all three down one route is how you get the form you have now. We see the same pattern across industrial distributor catalogues regardless of size.
Key takeaways
- The new line form encodes a data model nobody wrote down. That is the root cause of all six failures.
- One form for all categories destroys the difference between “not applicable” and “not answered”.
- Split commercial terms and logistics from content, so the slowest input stops setting the pace.
- Suppliers will invent a variant structure if you do not give them one, and it will not be consistent.
- A gate that never rejects anything is not a gate. Write the acceptance test and run it.
- Fix the specification before you buy the portal. Most failed portals were loaded with a broken spec.
If new lines are taking longer than the commercial team can defend, the diagnosis is usually quick. We review the form, the returns from your last twenty lines and the attribute spec behind them. You get back the failure points and a fix sequence. Thirty minutes on a call is enough to see whether it is worth doing. Get in touch, or look at how we run supplier data onboarding and what we do for B2B distributors.