Key takeaways
- Identify the product unambiguously: name, grade, code, revision and issue date.
- State specifications with the test method and the tolerance, not a bare number.
- Separate typical values from guaranteed specification limits.
- Cover applications, handling, storage conditions, shelf life and packaging sizes.
- Reference standards and approvals by number, and version the sheet on every change.
Structure of a technical data sheet
- Identification — Product name, grade, code, revision number, issue date, supplier details
- Description — What the product is and its principal use in two or three sentences
- Specifications — Property, unit, specification limit, typical value, test method
- Performance data — Curves, cure times, strengths, efficiency, coverage rates with conditions
- Applications — Approved uses and, where relevant, uses to avoid
- Directions for use — Preparation, mixing ratio, application method, equipment
- Handling and storage — Temperature range, shelf life, container guidance
- Packaging — Available pack sizes, weights, pallet configuration
- Compliance and approvals — Standards, certifications and approval numbers
- Disclaimer — Conditions under which the data holds and the limits of liability
Writing specifications that can be verified
- Every property line needs: property, unit, method (for example the standard number), limit and typical value.
- Label typical values as typical — they are not a guarantee and should not appear as a spec limit.
- State the test conditions: temperature, humidity, substrate, cure time.
- Avoid marketing adjectives in the specification table; keep claims in the description.
- Where a customer specification differs, issue a customer-specific sheet rather than editing the standard one.
A TDS is often incorporated by reference into a supply agreement. Anything overstated on it becomes a contractual promise, so keep guaranteed limits conservative and put marketing language elsewhere.
TDS, SDS and COA — three different documents
| Document | Answers | Audience |
|---|---|---|
| Product data sheet (TDS) | What the product is and how it performs | Specifiers, engineers, buyers |
| Safety data sheet (SDS/MSDS) | What the hazards are and how to work with it safely | EHS, transport, emergency responders |
| Certificate of analysis (COA) | What this specific batch actually tested at | QA, customs, receiving inspection |
The TDS states the specification, the COA proves a batch met it, and the SDS covers hazard and handling. Regulated and chemical shipments usually need all three alongside the commercial documents.
Version control
Number every revision and show the issue date on the sheet. Customers file datasheets and quote them years later, so an undated sheet with changed values is a dispute in waiting. Keep a change log internally and notify customers whose specifications reference the sheet.
How to write a product data sheet
Step 1: Identify the product
State name, grade, product code, revision number and issue date.
Step 2: Describe the product
Summarise what it is and its principal application in a short paragraph.
Step 3: Build the specification table
List each property with unit, test method, specification limit and typical value.
Step 4: Add usage guidance
Cover applications, preparation, mixing, application method and equipment.
Step 5: Add storage and packaging
State temperature range, shelf life, pack sizes and pallet data.
Step 6: Reference compliance and version
Cite standards and approvals, add the disclaimer and record the revision.
Frequently asked questions
What is the difference between a TDS and an SDS?
A TDS describes performance and use; an SDS describes hazards, handling, first aid, firefighting and transport classification. An SDS is a regulated document with a fixed 16-section structure; a TDS is not.
Should a product data sheet include prices?
No. Prices change independently and belong on the quotation or price list. Keeping them off allows the sheet to circulate freely.
How often should a datasheet be revised?
Whenever the specification, packaging, approvals or usage guidance changes. Increment the revision number and issue date every time, even for small edits.
Do typical values need to be met?
No — typical values indicate expected performance. Only the stated specification limits are commitments, which is why the two must be separated clearly.