Noam Naveh
CEO @Stylib
A technical data sheet looks like something you create once and file away. In textiles, at least, it doesn’t work like that.
Fabric specifications keep moving for months, sometimes years, after launch. A new flammability certificate arrives. A colourway is discontinued. The composition changes slightly. An abrasion test is updated. None of this is unusual. It’s what a product that’s still on sale does.
So the data sheet isn’t really a document. It’s a recurring job dressed as one.
What one change actually costs
From what we see at Stylib, nearly every manufacturer handles a change the same way. Someone reopens a sheet that’s already live. Find the file. Edit it. Check the layout hasn’t broken. Export a new PDF. Version it. Then replace it in every place it has been published.
Very little of that is work on the product. Almost all of it is work on the document.
Now multiply it out. A few hundred live sheets, each likely to change more than once, each change touching several copies. The effort never ends, and it grows with the catalogue. Every new collection adds sheets, and every sheet adds future edits.
“It’s just admin, though”
That’s the obvious objection, and it’s exactly why the cost stays hidden. Nobody would sign off a P&L line labelled “reformatting PDFs”. Spread across hundreds of products and repeated indefinitely, that’s roughly what’s being paid for. It just never appears in one place where anyone sees the total.
And it isn’t admin, because of who reads the output. In a 4specs survey of 235 US specifiers, 90% said they usually want to find product data sheets on a manufacturer’s website, ahead of formatted specifications (70%) and product selection guides (66%). The data sheet is the document specifiers go looking for, and they make decisions off it.
In the UK there’s a second reason. After Grenfell, the Construction Products Association drew up the Code for Construction Product Information (CCPI). Its five tests are that product information is clear, accurate, up to date, accessible and unambiguous. Its clauses call for a documented sign-off process and formal version control for all product information. For anything sold into a building, a stale sheet is no longer untidy. It’s a compliance gap.
The cost isn't in the editing. It's in which way the information flows
In most manufacturers the PDF is the master record. The rub count, the fire certificates and the cleaning code live inside the layout, so changing a fact means changing a design file. Every downstream copy then depends on someone remembering where it went.
Flip it and the sheet becomes an output. If composition, test results and certifications sit in one structured record, the sheet is generated from that record. A change made once appears in every sheet, everywhere it’s shown. Version control stops being a filing discipline and becomes a property of the system.
The CCPI doesn’t say how to stay up to date. You can get there with diligence and a lot of manual effort. Or you can arrange things so an out-of-date sheet is hard to produce in the first place.
The sheet will keep changing
It will change for as long as the product is on sale. The only real decision is whether each change is a design job or a data entry.That second option is what our product datasheet automation is built for: branded technical sheets generated from structured product data, so one change updates every sheet.
- 4specs, December 2020 newsletter: survey results, “What do you want to find on the manufacturer’s website” (fall 2020 survey, 235 responses)
- The Construction Index, 26 Jan 2021: CPA consultation on the Code for Construction Product Information (five tests and 11 clauses)
- CIBSE Journal: Construction code launched (CCPI launch, response to the Hackitt Review)