The Six Things a Technical Confirmation Email Must State
Share
A technical confirmation email is a strange document. It is written quickly, read once, filed, and then quoted two years later in a conversation about whether a batch conforms. By then it is a commitment, and by then nobody can remember what was meant by "standard grade".
The fix is not longer emails. It is six statements, each of which closes a specific gap. Most confirmations contain two of them.
The six statements
| # | Statement | The failure it prevents |
|---|---|---|
| 1 | Product identity and grade basis | "Ph. Eur. grade" read as a document rather than a framework |
| 2 | The specification document and its version | Two parties holding different revisions |
| 3 | The method behind each critical number | A number with no procedure, untestable by the customer |
| 4 | The batch and date the statement refers to | A general claim read as a batch-specific one |
| 5 | What is not tested or not claimed | Absence of a result read as a passed result |
| 6 | What happens if a result differs | A dispute with no agreed route |
1. Identity and grade basis
Name the substance, the salt or hydrate form if one exists, and the basis on which the grade is described. "Ursodeoxycholic acid, EP grade" is not enough on its own, because it does not say whether the product is described by the monograph, by a company specification aligned with it, or by a customer specification that departs from it.
The distinction is not pedantic. A product described by a monograph carries the tests in that text. A product described by a company specification may carry additional tests, tighter limits, or in some cases fewer tests with a justification. The customer's regulatory file depends on which of the three applies.
2. The specification document and its version
Specifications have revisions. Two parties can spend a week discussing a limit when one is reading revision four and the other revision six, and neither email mentions a version because both assume the document is stable.
A version reference, or an attachment, or a statement that the specification is unchanged since a named date, converts the conversation into something checkable. Where a specification is about to change, saying so in the confirmation prevents the change from arriving as a surprise in the next certificate.
3. The method behind each critical number
This is the statement most often missing. A certificate reports assay 99.4% and does not say whether that came from a titration or a chromatographic comparison. Those two methods can differ by more than half a percent on the same material, which means the number is not portable between laboratories without the method.
Where the method is pharmacopoeial, name the chapter. Where it is in-house, name it and say whether it has been validated and against what. Where the customer will test the same parameter with a different method, the two results will differ, and the only way to have that conversation productively is to have named both methods in advance.
4. The batch and the date
A statement about a product is not a statement about a drum. Saying "our material meets 0.10% on this impurity" describes a capability. Saying "batch X, manufactured on date Y, tested at 0.04%" describes a fact.
The distinction matters when the customer's incoming test disagrees. A capability claim invites the reply that the batch in question was different. A batch-specific claim invites a comparison of two results on the same material, which is a solvable problem.
5. What is not tested
The most valuable line in the email and the one most often omitted, because it feels like a weakness. It is the opposite: a statement of the testing scope prevents the customer from building a file on an assumption.
Parameters commonly outside routine testing in this product family include elemental impurities at the full ICH Q3D panel, nitrosamine risk assessment, specific microbiological counts beyond the compendial set, and residual solvents outside the class used in the process. Each of them can be tested on request, and each of them takes time, which is exactly what a customer needs to know at the quotation stage rather than at the audit.
6. What happens if a result differs
A single sentence settles this: which party's result governs, what happens if the two differ by more than a stated amount, and whether a third laboratory is available as a referee. Without it, a disagreement becomes commercial rather than technical, and the party with the weaker position concedes rather than resolves.
The gap between specifications is where this clause earns its place, and the quality agreement is where it should be recorded so that it survives staff changes on both sides.
How to write it
One page, numbered to match the six statements, no adjectives. Attach the specification. Name the methods. State the exclusions. Offer the route if results differ. Close with the document pack that will accompany the first shipment, because that is the next question the customer will ask.
The first-order pack belongs in the same email rather than in a later one, since a customer who has to ask twice for a COA has already formed a view about the administrative side of the relationship.
We send confirmations in this shape, and we treat the exclusions list as part of the offer rather than as a caveat. The relevant frameworks are ICH Q6A for specification concepts, the Ph. Eur. texts and certificates for the compendial route, and the European GMP text for the documentation expectations behind them.
The question to ask is not whether the supplier will confirm in writing. It is: which of the six statements is missing from the confirmation you already have?
The reply that costs the least
There is a moment in most technical correspondence when the honest answer is "we do not know yet". The temptation is to write something reassuring, and the reassurance becomes a commitment once it is forwarded internally by the customer.
A three-part reply handles it without losing the thread. What is known, stated plainly. What is not known, stated plainly, with the reason. When the answer will arrive, with a date. That reply is shorter than the reassuring one and it survives being quoted back six months later, which the reassuring one does not.
The phrases that create work later
"Should be fine." A judgement offered without a basis. It will be read as a confirmation and it cannot be defended when it is wrong.
"Standard grade." A term with no document behind it. It means whatever the reader needs it to mean, which is the definition of an ambiguity.
"Meets pharmacopoeia." A conformity claim that a supplier is rarely in a position to make, and one that a customer's regulatory file will treat as a statement about the batch. The safer construction describes the specification and its relationship to the text rather than asserting conformity.
"No problem." Used for requests that have not been checked with the people who would perform them. It is the most expensive phrase in the list because it commits a third party who has not been consulted.
Keeping the record usable
Three habits make correspondence usable later. Number the statements, so that a reply can reference one of them. Put the specification in an attachment rather than in the body, so that the body remains readable and the attachment remains the version-controlled document. And close with the next action and its owner, so that the thread has a state rather than a mood.
These habits are the same ones that make a confirmation email work at the start of a relationship, applied to the correspondence that follows. A file built from numbered statements is auditable; a file built from paragraphs is a recollection with timestamps.
What the customer does with the email
The email is not read once. It is pasted into a qualification file, quoted in a deviation report, and used by someone who joined after it was written. That future reader has no context and no ability to ask a follow-up question, which is the standard the email should be written to.
Two consequences follow. Anything that depends on a conversation should be restated in the email, because the conversation will not survive. And anything that is true only for a period should carry the period, because a statement without a date becomes a permanent claim.
The subject line and the attachment
A subject line that names the product, the grade and the purpose is worth more than it appears. Correspondence is retrieved by search years later, and a thread called "RE: RE: question" is unretrievable. The same applies to attachments: a specification named with its version and date can be matched to a certificate; one called "spec.pdf" cannot.
None of this is administrative decoration. It is the difference between a file that can answer a question in two minutes and one that requires an email to the person who wrote it, who may no longer be there, and who may not remember why the sentence was written.
Frequently asked questions
Why does an email matter if there is a contract?
Because the technical content usually is not in the contract. The contract names a product and a specification by reference, and the reference is filled in by correspondence. When the two documents disagree, the email is read as the clarification, which is a difficult position to argue from later.
What is the most commonly missing statement?
The method. Certificates routinely report a number without naming the procedure that produced it, and two procedures for the same parameter can differ by more than the specification width. Without the method, the number is a claim rather than a measurement.
Should an email list what is not tested?
Yes, and it is the most valuable part. A statement that a parameter is not routinely tested prevents the customer from assuming it was, and prevents a later conversation in which the absence of a result is read as a passed result.
How specific should a grade reference be?
Specific enough to identify a version. "Ph. Eur. grade" identifies a framework, not a document, and the framework has editions and supplements. Name the edition or say that a company standard is applied and describe how it relates to the framework.
What if the customer asks for something not tested?
Say so, and say what it would take: a method, a validation, a batch to test on, and a time. An email that promises a result the site cannot produce is worse than an email that describes the gap, because the gap is recoverable and the promise is not.
Does this replace a quality agreement?
No. It reduces the number of things the agreement has to settle later, and it gives the agreement something specific to reference. The agreement is the durable instrument; the email is the working record that keeps it accurate between revisions.