A new machine should arrive with a clear plan, not a cloud of uncertainty. Yet many operations managers first meet their equipment when the crate is open, the install crew is waiting, production is asking for dates, and everyone hopes the controls, guarding, changeovers, and product handling all behave the way the quote suggested they would.
That’s the expensive way to learn what you bought.
Factory acceptance tests work best when you treat them as a working session between the manufacturer, engineering, quality, and operations. Done right, they don’t just confirm that a machine turns on. They prove that it solves the production problem you need solved, under conditions your team can trust, before the equipment ever reaches your floor.
Table of Contents
- Why Factory Acceptance Tests Are Your Best Insurance Policy
- Defining Success Before the Test Begins
- Building Your Comprehensive FAT Protocol
- Running a Smooth and Effective FAT
- From Punch Lists to Project Handover
- The FAT as a Foundation for Production Excellence
Why Factory Acceptance Tests Are Your Best Insurance Policy
When a machine arrives without a rigorous factory acceptance test behind it, the site install often turns into discovery work. Controls issues appear under power. Sensors are mounted correctly but tuned poorly. Safety logic passes a drawing review but frustrates operators in real use. By the time those issues show up on your floor, every fix costs more because electricians, mechanics, production leaders, and schedules are all involved at once.
A well-run FAT shifts that risk upstream, where corrections are cheaper and faster. In global manufacturing, a properly executed FAT can cut installation and startup times by 30 to 50 percent and reduce repair costs for post-installation defects by a factor of 5 to 10x, according to Packaging Corp’s review of successful equipment installation practices. That matters even more in regulated production and high-value manufacturing, where downtime in some sectors can cost upwards of $260,000 per hour in the same source.
FAT and SAT are not the same job
A lot of teams blur the line between FAT and SAT. That usually leads to weak expectations for both.
A factory acceptance test is where you verify the machine at the builder’s facility before shipment. You’re checking build quality, controls logic, safety devices, sequence behavior, and whether the system can perform the agreed tasks under defined conditions. A site acceptance test happens after installation, when the system is connected to your utilities, upstream and downstream processes, and plant-specific operating conditions.
The FAT should not be used to postpone hard questions until the machine lands. The SAT should not be used to discover whether core functions were ever proven at all.
Why this matters for semi-automated systems
Semi-automated equipment has a specific trade-off. It gives you flexibility, lower capital exposure, and better fit for many medical device and small-to-mid-sized manufacturing environments. But because operators, fixtures, sensors, and manual touchpoints all interact closely, the success of the system depends on practical detail.
That’s why factory acceptance tests are especially valuable for teams working in GMP-aware manufacturing environments. You need to know not just that the machine cycles, but that it supports controlled, repeatable production with realistic operator interaction.
Practical rule: If a problem can be found at the vendor’s facility, that’s where you want to find it.
The best FATs not only reduce surprise but also create confidence. Your team sees the machine behave, asks questions before shipment, and walks into installation with evidence instead of assumptions.
Defining Success Before the Test Begins
Most FAT problems start before anyone enters the test bay. They start when the customer thinks “test what we ordered” is specific enough, and the vendor thinks “run the standard FAT” will cover it.
It won’t.
Factory acceptance tests became more formal as quality standards matured. FATs accelerated with standards like ISO 9001 and became mandatory in regulated sectors such as pharmaceuticals under FDA cGMP guidelines after 1978, as outlined in DXP’s overview of FAT protocol purpose and history. That history matters because it frames the FAT correctly. It isn’t a courtesy demo. It’s a formal verification step.
Put the right people in the room
A useful FAT team is small enough to move quickly and broad enough to catch blind spots.
From the customer side, the strongest group usually includes:
- Operations leadership: They know what will make the equipment usable on a real shift.
- Manufacturing or process engineering: They can compare the machine behavior to the intended process.
- Quality or validation: They look at documentation, traceability, alarms, access levels, and compliance expectations.
- Maintenance or controls support: They catch serviceability issues early, especially around sensors, panel layout, spare parts, and troubleshooting access.
From the supplier side, you want direct access to the people who can answer and act:
- Project manager: Keeps scope, schedule, and documentation aligned.
- Controls engineer: Explains sequence logic, alarm handling, and any software limitations.
- Mechanical lead or builder: Addresses hardware fit, motion, guarding, and adjustments.
- Quality representative when needed: Helps close documentation questions cleanly.
If the people attending can only observe and can’t resolve anything, the FAT slows down fast.
Write the FAT scope like a mini contract
The FAT needs its own working scope. Not a vague reference to the quotation. Not a collection of emails. A real, reviewable test scope.
That scope should answer four basic questions:
- What functions must be demonstrated
- What materials or simulated parts will be used
- What counts as acceptance
- What is explicitly out of scope
The last point prevents a lot of friction. If line integration, plant MES connection, or final packaging material isn’t available at the FAT stage, say so clearly. If the machine will be tested with representative parts rather than live production inventory, document that too.
A good FAT scope protects both sides. The customer knows what will be proven. The vendor knows what won’t suddenly be added in the room.
Define success in production terms
The most effective FAT planning starts with production needs, not machine features alone.
Instead of “verify barcode scanner,” define its actual purpose: confirm the scanner reads the required label format, rejects bad reads appropriately, and supports the operator workflow. Instead of “check recipe handling,” confirm that approved users can select the correct format without exposing unauthorized parameters.
Useful pre-FAT questions include:
- What production problem is this system supposed to remove
- Where is operator judgment still required
- Which failures would stop startup if discovered late
- Which issues can wait until commissioning without adding serious risk
Those answers shape a FAT that reflects reality, not just equipment completion.
Building Your Comprehensive FAT Protocol
A FAT protocol turns purchase requirements into evidence. If the protocol is loose, the FAT becomes a live discussion about what the machine was supposed to do. If it is detailed, the team can prove what works, log what does not, and leave with decisions instead of opinions.
For semi-automated equipment, that distinction matters more than many buyers expect. The machine may cycle correctly and still create operator delays, awkward manual handling, or inconsistent quality at the exact points where people interact with automation. A good protocol catches those gaps before the equipment ships.
If you’re buying custom-designed machinery for a specific production requirement, every meaningful requirement should show up in the protocol as a testable step. Custom equipment has fewer safe assumptions. The FAT should confirm not only that the builder finished the machine, but that the machine addresses the production problem you approved capital for.
Start with static verification
Static verification happens before the machine runs. It confirms the build matches the released design and that the basics are in place before anyone starts chasing software issues that are really hardware or documentation problems.
That usually includes document review, visual inspection, utility checks, and safe-access review. For regulated or washdown-sensitive applications, it should also include finish quality, material selection, cleanability, and maintenance access.
Static checks worth listing one by one in the protocol include:
- Drawing verification: Confirm the latest electrical drawings and relevant mechanical documents match the as-built system.
- Component confirmation: Verify installed sensors, actuators, drives, valves, and HMIs against the approved bill of materials.
- Safety hardware review: Confirm guard switches, e-stops, light curtains, interlocks, and safety relays are installed and identified correctly.
- Operator access: Check that loading, unloading, adjustment, cleaning, and maintenance access are practical and safe.
Static checks are rarely the exciting part of a FAT.
They are often the cheapest issues to fix.
Move into functional testing
Functional testing proves machine behavior. The protocol should force the team to run the system the way production will use it, including normal operation, fault conditions, and recovery steps.
For semi-automated systems, I usually want more detail around handoff points between the operator and the machine. A fully automatic cell may live or die on cycle time and fault recovery. A semi-automatic station can miss its ROI because the operator prompt is unclear, the fixture is awkward, or a reset sequence takes too many steps. None of those problems look serious on a mechanical completion checklist. They show up fast in a well-written FAT.
Useful functional test areas include:
- Controls sequence: Start, stop, reset, fault recovery, and orderly shutdown
- Alarm handling: Sensor failure, actuator timeout, low-pressure condition, jam detection, and operator prompts
- User access: Role-based access where applicable, parameter protection, and traceable changes
- Safety response: Safe stop behavior, restart logic, interlock recovery, and access door behavior
- Manual interactions: Fixture loading, part presentation, operator confirmation steps, and ergonomic timing
If a human action affects quality, throughput, or safety, put it in the protocol and test it under realistic conditions.
Finish with performance proof
Performance testing should show whether the machine can produce the agreed result under representative conditions. That means using the right parts or approved surrogates, following the intended operating method, and recording outcomes against defined acceptance criteria.
This part of the FAT is often where trade-offs become visible. A machine may hit target speed only with an experienced technician loading parts. It may hold quality only when recipes are set by the controls engineer instead of a production operator. It may reject parts correctly but create enough interruption that line staffing assumptions no longer make sense. Those are not minor observations. They affect startup risk, labor planning, and the payback case for the equipment.
Below is an example of a FAT protocol format with completed results so the team can see how findings are captured.
| Test Category | Test Case Description | Acceptance Criteria | Result (Pass/Fail/Comment) |
|---|---|---|---|
| Static | Verify electrical drawings and installed panel components match approved release | As-built matches released documentation | Pass |
| Static | Inspect guarding, e-stops, interlocks, and labels | Safety devices installed and functioning as specified | Pass, label missing on guard door 2 noted for correction |
| Functional | Power-up and home all axes and actuators | System initializes without faults and reaches ready state | Pass |
| Functional | Simulate part-present sensor failure | Alarm generated, sequence stops safely, recovery is controlled | Fail, see punch list item #5 for recovery prompt revision |
| Functional | Run recipe changeover between two part formats | Changeover completes per documented procedure with no unintended adjustments | Pass, operator needed engineering support on first attempt |
| Performance | Run repeated cycles with production-representative parts | Cycle time meets documented target and quality output remains acceptable | Pass |
| Performance | Verify reject handling and operator response | Nonconforming parts are segregated and operator receives clear instruction | Pass, reject bin full warning to be added post-FAT |
| Performance | Simulate sustained production run | System maintains agreed reliability and stable operation over the run | Pass, minor HMI lag observed but did not affect run |
A useful protocol also states prerequisites clearly. List the parts required, tooling needed, approved simulations, software version under test, and who signs each result. Those details keep the FAT disciplined and make the output usable later, especially when punch list items need to be closed without arguing over what was witnessed.
Running a Smooth and Effective FAT
On the day of the FAT, the room tells you a lot before the first test starts. If parts are laid out, tools are ready, the latest protocol is printed or loaded, and the controls engineer can move through the sequence without hunting for files, you’re in decent shape. If everyone is still debating what version is current, you’re already spending time badly.
For operations managers who haven’t attended many FATs, it helps to think of the day as structured observation. You are not there to admire the machine. You are there to watch how it behaves under instruction, how the vendor team responds to questions, and whether the system can be supported in practice. That’s especially important when the equipment includes integrated automation control systems tied to operator workflow and plant reliability.
What a good FAT day looks like
A smooth FAT usually starts with a short kickoff. The team confirms scope, reviews safety, checks materials, and agrees on how findings will be logged. Then the group follows the protocol in order rather than bouncing between favorite features.
The strongest sessions keep one person focused on execution and another on documentation. While the machine runs, someone should record pass or fail status, note observations, and capture evidence. Photos and short videos are useful when they support a specific finding, such as sensor placement, HMI wording, guarding clearance, or product orientation through a nest or fixture.
A practical rhythm looks like this:
- Morning review: Confirm scope, witness list, protocol revision, and available test materials.
- Guided execution: Run tests in the defined order and resist the urge to improvise unless everyone agrees to it.
- Real-time logging: Record failures and observations at the moment they occur, not hours later from memory.
- Daily debrief: End the session with open items, owner assignments, and agreement on what happens next.
How to handle issues without losing momentum
Not every issue deserves the same reaction. Some findings are observations. Some are deviations. A few are hard stops.
An observation might be an HMI screen that could be clearer or a cable route that should be tidied before shipment. A deviation is a miss against the agreed protocol, such as an alarm that doesn’t display correctly or a changeover sequence that requires undocumented extra steps. A critical failure is anything that blocks safe operation, invalidates a key requirement, or makes the performance run meaningless.
Keep the room calm and specific. “This failed because the reject confirmation didn’t latch after reset” is actionable. “The software seems off” is not.
Good FAT leadership also avoids turning every issue into a design debate. If the protocol says a function must occur, verify whether it occurred. If someone wants a new feature, log it separately through change control. Mixing defects with enhancement requests confuses the record and usually slows decisions.
One more point matters. Don’t let the vendor “fix it later” without a clear retest path. If a controls change is made during the FAT, rerun the affected test and any nearby functions that could have been impacted. Otherwise you leave with confidence in a patch, not confidence in the machine.
From Punch Lists to Project Handover
A FAT usually ends with open items. That is normal. The value comes from finding them while the machine is still at the builder’s floor, where corrections are faster, cheaper, and easier to verify.
The handover risk is rarely the existence of problems. It is poor definition. A vague note like "operator station needs work" turns into arguments later. A clear note like "barcode scanner misses 2 of 20 reads when the fixture is loaded with part family B, retest required after bracket adjustment" gives the vendor something to fix and gives your team a clean basis to accept or reject the result.
That matters even more on semi-automated systems. The machine may be technically functional while still creating avoidable labor drag, awkward operator motion, or extra quality checks that were never part of the business case. If the FAT is meant to reduce project risk, the closeout process has to capture those practical gaps, not just electrical or software defects.
Sort findings by business impact
Use a punch list that reflects production consequences.
A simple three-level structure works well:
- Critical: Correct before shipment and retest as needed. This includes safety issues, failed core process steps, unstable controls behavior, missing required interlocks, or anything that would block startup, validation, or safe operation.
- Major: Correct under an agreed plan with a named owner and due date. Typical examples are incorrect alarm text, manual cycle steps that do not match the work instruction, incomplete documentation, or operator tasks that are workable but too slow or too awkward.
- Minor: Track to closure, but do not let them distort the shipment decision. These are items like label cleanup, cosmetic panel issues, noncritical HMI wording, or finish work that does not affect function.
This classification helps answer the core project question. Can the equipment ship without creating more cost at site than it saves at the factory?
I usually push teams to be strict on anything that shifts work back onto operators. A semi-automated machine can pass every sequence test and still miss the point if it adds excessive handling, unclear recovery steps, or constant small stops. Those issues may not look dramatic in a FAT report, but they show up quickly in labor hours, training burden, and first-week output.
Build the handover package before shipment
Do not treat the FAT report as paperwork to finish on the flight home. It is the operating record for the handoff between vendor, engineering, operations, maintenance, and quality.
A useful handover package includes:
- Approved FAT protocol: The exact test document used, with recorded results, comments, and signatures.
- Punch list log: Each item with severity, owner, target date, and the evidence needed for closure.
- Supporting evidence: Photos, videos, screenshots, data logs, and marked-up drawings tied to specific test steps or findings.
- Open-item disposition: A written statement showing what must be closed before shipment, what can be verified during site acceptance, and what has become a separate change request.
- As-built release status: What drawings, manuals, software backups, spare parts lists, and parameter files are complete and released with the machine.
One rule helps keep handover honest. Read every open item out loud before final signoff. Confirm who owns it, how it will be closed, and whether closure requires proof, retest, or customer approval. That ten-minute review prevents a lot of expensive confusion later.
Good handover protects both sides. The customer gets a machine with fewer unknowns. The vendor gets a clear record of what was accepted, what remains open, and what is outside the original scope. That is how a FAT supports collaboration instead of turning into a final exam nobody trusts.
The FAT as a Foundation for Production Excellence
The best factory acceptance tests don’t feel like exams. They feel like alignment.
Operations learns how the machine really behaves. Engineering sees whether the design intent survived the build. Quality checks whether the documented requirements are visible in the system. The vendor gets one last chance to correct issues before the cost and pressure of site work take over.
That’s why I’d encourage any new operations manager to view factory acceptance tests as part of production strategy, not just project administration. A strong FAT gives you early operator familiarity, clearer startup expectations, cleaner documentation, and a far better handoff into commissioning. It also tells you something important about the company that built the equipment. Good partners don’t resist disciplined FATs. They prepare for them.
Semi-automated systems benefit especially from this approach because success depends on the interaction between machine logic, fixture design, operator motion, product variation, and maintainability. Those are practical realities. They need to be seen, challenged, and agreed before shipment.
A machine that passes a thoughtful FAT arrives with a shorter list of unknowns. That changes the tone of the entire startup.
If you’re planning new equipment, upgrading a manual station, or evaluating the right level of automation for your process, System Engineering & Automation can help you build a practical path from concept through FAT, installation, and commissioning. Their team focuses on cost-effective manufacturing solutions that improve quality, efficiency, and safety without losing sight of real production constraints.
