The factory acceptance test: the exam you get to write yourself
The FAT is the last gate before your machine ships. Startups treat it as a formality. Industrial buyers treat it as the moment of truth. Write the exam yourself, early, or someone else will write it for you.
The worst phone call in hardware comes at the end. The machine is built, the truck is booked, the invoice is ready. Then the customer's engineers arrive for the factory acceptance test, pull out a checklist you have never seen, and fail you on day one. Three months of rework. The startup that wrote the test procedure in the final week learns, expensively, that the FAT is not a formality. It is the deal, one last time.
A factory acceptance test is the customer's chance to verify, at your facility before anything ships, that the equipment does what the contract says. It sounds like quality assurance. It is actually a negotiation about what done means, and like every negotiation, it is won by whoever prepares.
Write the exam while everyone is still friends
The single most valuable FAT move happens at contract stage, not at machine stage. Attach the test procedure to the purchase order as an annex: what will be tested, how, with what pass marks, measured in whose units. Get it signed when everyone is optimistic and the lawyers are already at the table.
Startups resist this because it feels like extra paperwork when the deal is close. It is the opposite. An agreed FAT protocol protects you from the checklist that appears at the door, and it protects the customer's champion from their own colleagues. When the test is written down and signed, nobody can move the goalposts in week forty.
Pass marks in numbers, not adjectives
A bad FAT says the machine will demonstrate reliable operation at production speed. A good FAT says the machine will run four consecutive hours at 120 units per minute with fewer than two unplanned stops, measured by the customer's engineer, using the customer's material. Adjectives are where acceptance tests go to die.
Every line of the protocol should answer: what exactly do we measure, with what instrument, over how long, and what number is a pass. If a line cannot be written that way, the requirement underneath it is not understood yet, and it will come back at the worst moment. This is the same discipline as defining pilot success before anyone plugs anything in, one level up in formality.
Rehearse on your own floor
Obvious, and routinely skipped. Run the full FAT yourself, exactly as written, before the customer arrives. Not a quick spin. The whole protocol, timed, witnessed by someone on your team who did not build the machine.
What you will find is humbling and cheap: the sensor that drifts in hour three, the documentation page that does not match the wiring, the test step nobody can actually perform as written. Finding these with your own people costs an afternoon. Finding them with the customer's engineers watching costs you credibility you spent a year earning.
A failed FAT is information with a price tag
If you do fail, and some first machines do, the failure itself is rarely the disaster. The disaster is an ambiguous failure with no agreed next step. This is why the protocol also needs the boring clauses: what happens on a failed item, who pays for rework and retest, how long the retest window is, what partial acceptance looks like.
A startup that fails a test point and responds with a clear plan inside a signed framework keeps the deal and often the relationship. The customer's engineers fail things all the time. What they cannot work with is a supplier who goes quiet or argues about what the test meant.
The FAT is your reference case being born
Zoom out. A passed FAT is not just a shipped machine. It is a witnessed, documented, customer-signed proof that your equipment does a measurable thing in the real world. That document is the beginning of your next three deals, because the next buyer's first question is always: who else has this, and did it pass.
So treat the protocol as marketing with a torque wrench. Agree the numbers you would proudly publish. Negotiate the right to reference the result. The startups that understand this stop dreading the acceptance test and start using it as the sharpest proof in the pipeline. It is the same logic as pricing to value: the test is not about your machine, it is about the customer's outcome, measured.
What to do this week
If you have a deal heading toward a build, ask one question: is the FAT protocol written, and is it signed. If the answer is no, that is your next piece of paper, before the purchase order closes. And if you are selling complex equipment into industry and want the commercial process around it built properly, from first meeting to signed test protocol, that is the work we do at SLSCRW.