What should you leave out of a technical report for a customer?

This guide covers technical reports a supplier or distributor writes for a customer, such as service visit, trial, test and failure reports. It does not cover documents whose content is fixed by regulation or contract, such as a safety data sheet or a certificate of analysis. Data protection and trade secret questions depend on jurisdiction, so the legal points here are orientation, not legal advice.

Which content decides what a customer technical report includes?

The reader and the purpose decide what a customer technical report includes, so fix both before the first line is written. Milne Open Textbooks states that the sections of a technical report are decided by the author based on the audience and the expected use of the report (Milne Open Textbooks, accessed 2026). Engineers interviewed by the University of Sheffield say the same in practice: a report needs a topic, an audience and a stated aim, and a report for managers focuses on conclusions, the business case and risks rather than on how the findings were reached (University of Sheffield, accessed 2026). For a customer technical report, write three things at the top of the working file: who will read it (for example the customer's maintenance engineer, a plant manager or a purchasing lead), what decision or action the report supports, and which records it draws on. The person who asked for the report and the account owner should agree on these before drafting starts. Each later choice follows from them. A customer engineer acting on a failure report needs the test method, the result and the recommended action. The same engineer has no use for how your team argued about the cause, which colleague reviewed the draft, or the score your internal tool gave the diagnosis.

Customer technical report content table: what stays in and what comes out

The content table below decides, item by item, whether content stays in a technical report when the reader is internal and when the reader is the customer. It is a starting rule set; a specific contract, a non-disclosure agreement or a regulation can override a row.

The row that most often needs a decision is cost: keep it out of a customer technical report unless the agreed purpose of the report is a cost comparison, and then show only the figures that comparison uses. Use the table in the order of the rows when you edit a draft: the first three rows remove traces of internal work, the fourth protects other customers, and the last four handle commercial figures and technical content. A third reader needs its own column in practice. When a report goes to the product maker's technical team, for example to escalate a complaint, the customer's own name, site and staff details usually come out instead, unless the customer has agreed to share them.

Why does internal review history end up in customer reports?

Internal review history ends up in customer reports because the customer version is usually edited down from an internal draft instead of written for the customer from the start. A technical report often passes through several hands: the field engineer writes the observations, a laboratory adds results, a senior engineer reviews the cause, and someone in sales checks the wording. Each pass leaves traces: tracked changes, margin comments, a superseded conclusion in an appendix, a paragraph explaining why an earlier hypothesis was dropped. When the same file becomes the customer version, removing those traces depends on one person reading every page with the customer's eyes, late in the process and under time pressure. Tracked changes and comments are the easiest traces to miss, because a word processor can hide them on screen and still keep them in the file sent to the customer. The practical fix is to start a clean customer document once the conclusion is settled, carry over only the results, conclusions and actions, and keep the review trail in the internal file. Milne Open Textbooks notes that a detailed procedure may be withheld from readers when it is proprietary, and a brief description used in its place (Milne Open Textbooks, accessed 2026); internal methods and review notes can be handled the same way.

Should confidence scores go into a report sent to a customer?

Confidence scores from internal tools, scoring sheets or reviews should not go into a report sent to a customer, because the customer cannot tell what the scale means or what it was measured against. A diagnosis marked "confidence 0.8" (illustrative) carries meaning only for the team that built the score. To the customer, it reads either as a hedge or as a precise probability, and it is neither. What the customer needs instead is information it can assess. For a measured value, that is the method, the result and its uncertainty: JCGM 100:2008, the Guide to the expression of uncertainty in measurement, states that when reporting the result of a measurement it is obligatory to give some quantitative indication of its quality so that those who use it can assess its reliability (JCGM, 2008). For a conclusion that is not a single measurement, such as a root cause, state which parts are confirmed by tests and which are not yet confirmed, and what would confirm them. "The deposit was identified as calcium carbonate by the attached analysis; the source of the hardness has not been confirmed" (illustrative) tells the customer more than any score. Keep the internal score in the internal file, where it helps your team decide how much further testing is worth doing.

How do other customers' details leak into a technical report?

Other customers' details leak into a technical report through reused templates, comparison data and case references that were written for a different account. A report template copied from the last site visit can keep the previous customer's name in a header, a file path or a photo caption. A comparison chart that shows how "similar plants" performed can identify a plant by its size and location even without a name. A sentence such as "we solved the same problem at a nearby bearing plant" can reveal another customer's process issue. Two references set the frame. Where a report names people, such as operators or contacts at another customer, EU data protection law limits personal data to what is "adequate, relevant and limited to what is necessary" for the purpose (Regulation (EU) 2016/679, Article 5(1)(c)); the UK regulator ICO explains the same principle for the UK GDPR (ICO, accessed 2026). Separately, ISO 9001:2026 keeps clause 8.5.3, Property belonging to customers or external providers (ISO, 2026); a supplier certified to ISO 9001 should check how its own procedure under that clause treats information customers entrust to it. In practice: start each report from a blank template, remove other customers' names, sites and results, and use aggregated data only when no single customer can be identified from it.

When should cost, margin or stock figures appear in a customer document?

Cost, margin or stock figures should appear in a customer document only when the document's purpose needs them, and margin almost never does. A cost figure belongs in a cost-in-use review the customer asked for, in a quotation, or in a comparison of treatment options where the customer agreed on the cost basis; in each case show the figure, its source and the date it applies to. A technical service report about a failure or a trial does not need cost, and a cost line in it can turn a technical discussion into a price discussion. Margin is internal commercial information. Under the EU Trade Secrets Directive, information qualifies as a trade secret only if it has commercial value because it is secret and has been subject to reasonable steps to keep it secret (Directive (EU) 2016/943, Article 2). US federal law uses a similar test of reasonable measures and independent economic value (18 U.S.C. 1839). Putting margin in customer documents works against those steps. Stock levels are operational data; when the customer's question is supply, answer with availability and a lead time, not an inventory count. The same rule fixes all three: write the purpose of the document first, then include only the commercial figures that purpose uses.

What to check in a customer technical report before it is sent

Check a customer technical report before it is sent against a short list that follows the content table, and do it on the file that will actually be sent. The checks below take a few minutes and catch most internal content:

1. The reader and purpose written at the start still match the report's content.

2. Tracked changes are accepted or rejected and all comments are deleted in the sent file.

3. No internal review notes, rejected hypotheses or reviewer names appear in the body or appendices.

4. No confidence scores or internal ratings appear; measured values show method, result and, where available, uncertainty.

5. Every cited source is a document the customer holds or can request, not an internal record.

6. No other customer's name, site, result or staff name appears in text, tables, headers, file names or photo captions.

7. Cost appears only if the purpose needs it; margin and stock counts do not appear.

8. File properties, such as author and template name, contain nothing internal.

A second person who did not write the report should run the check, because the author tends to read what was meant rather than what is on the page.

When should legal or privacy staff review a customer technical report?

Ask legal or privacy staff to review a customer technical report when it contains personal data about people outside the customer's own team, information covered by a non-disclosure agreement, another customer's results, or a statement that could be read as a warranty or a regulatory claim. These are the cases where the general rules in this guide stop being enough: data protection duties depend on the jurisdiction, and confidentiality duties depend on the wording of each agreement. A report that will be shared beyond the customer, for example with an insurer, an equipment maker or a regulator, also needs that review, because the reader is no longer the one the report was written for. Lubinpla handles the reader question at the start: when a document is proposed, the reader is set and then confirmed on the approval card, and a document for an external reader leaves out work history, internal review, confidence and scores, and internal record sources, with cost, margin and stock included only as far as the document's purpose needs. Whatever tool or template you use, keep the person who confirms the reader the same person who approves the final file.