Working with an automation integrator: specification, acceptance and what you hold at handover

What you are actually buying

Integrators buy robots, controls, sensing and handling equipment from manufacturers and assemble them into something that runs your process. The margin buys one organisation accountable when the gripper, the controller and the camera disagree with each other. That accountability evaporates the moment you split the scope, purchasing the robot yourself to save money and asking the integrator to program it, because every fault then has two candidate owners. Buy complete responsibility or accept that you are the integrator. Plants with strong internal engineering sometimes choose the second deliberately, and it is defensible when chosen knowingly.

The requirement document is the project

A cell does what the requirement document says and treats everything absent from it as optional. Write down the parts to be handled with their real variation rather than nominal drawings, the rate expected and over what period, how faults are recovered and by whom, what happens to an out-of-tolerance part, the changeover expectation, the utilities available and the environment it will live in. Supply real sample parts spanning the tolerance range, bad ones included. Ambiguity costs twice: once as a variation order and again as the argument over whether it was implied. Effort here is repaid during commissioning.

Acceptance at their site and acceptance at yours are different tests

Factory acceptance runs at the integrator's premises before shipment, using your parts, and its purpose is to find problems while the cell is accessible and the build team is still assembled. Site acceptance runs after installation under production conditions and should cover what factory testing cannot: genuine material supply, a changeover, a deliberately induced fault and its recovery, and sustained running across a shift rather than a demonstration. Write both protocols before contract, with pass criteria and stated consequences for failure, and tie payment stages to them instead of to shipping dates.

Code, drawings, passwords and the right to hire somebody else

At handover you should hold controller programs in editable, commented form, the robot programs, any sensing configuration, as-built electrical and pneumatic drawings, a parts list carrying manufacturers' references rather than the integrator's internal codes, and every password. Without those you cannot make a small change without raising an order, and you cannot engage anybody else if the relationship sours or the firm stops trading. Some integrators resist on intellectual property grounds, so negotiate it explicitly at quotation, because after handover your leverage is gone. Inspect the deliverables before final payment rather than accepting a promise.

Support once the invoice is paid

Support terms matter far more than they seem during a project everyone feels optimistic about. Agree what happens when the cell has stopped, whether attendance is included and within what period, and what it costs. Remote access should be designed against your security requirements rather than requested afterwards by an engineer who cannot get in. Training belongs on your cell with your operators rather than in a generic classroom, and it needs repeating once people have run the equipment long enough to know what to ask. Settle the boundary between warranty defect and operating damage before the first dispute.

Frequently asked questions

Should we buy a complete cell or supply some of the equipment ourselves?

Buying complete costs more and gives you one party to hold responsible when something fails to work. Splitting the scope saves margin and moves integration risk onto you, which is fine where you have engineers able to arbitrate between suppliers and unpleasant where you do not. A middle path, specifying the robot make for standardisation while the integrator still supplies and warrants it, usually works. Trouble comes from free-issuing equipment and then expecting undivided responsibility for the outcome.

What should factory acceptance testing actually cover?

Your parts, deliberately marginal ones included, run long enough to expose intermittent faults rather than long enough for a demonstration. Test recovery: halt the cell mid-cycle, remove a part, jam something, and watch how it restarts and whether an operator could manage that alone. Check the safety functions and the documentation set. Confirm the rate is achieved with fault handling active rather than in a clean run. Attach a payment stage to the result, because that is what gets faults fixed before shipping.

Why insist on unlocked, documented control code?

Because every future change depends on it. Products change, cycles get tuned, sensors get added, and a locked controller turns each of those into an order and a wait. It also protects you if the integrator becomes unavailable through workload, a soured relationship or business failure. Ask for editable commented code, robot programs, configuration files and passwords as contract deliverables, then check them yourself before final payment, since an unreadable dump technically satisfies a vaguely worded clause.