Custom automation is one of the larger capital decisions a plant makes, and it is one of the few where the thing you are buying does not exist yet when you agree the price.
That is what makes it different from buying a machine tool. You are buying an outcome and a design process, not a product with a spec sheet. Most of what determines whether it goes well happens before anyone cuts steel.
1. Be sure the process is stable first
The most expensive automation failure is a machine built around a process that was not ready.
If your part is still changing, or the process only works reliably when a particular operator runs it, automating it will produce a machine that makes bad parts consistently.
Signals you are not ready: nobody can tell you the real cycle time, quality varies by shift, or the process depends on an adjustment somebody makes by feel. Fix that first, or run a paid process development study. Both are far cheaper than discovering it during commissioning.
2. Know which number you are buying
"Faster" is not a specification.
Decide whether you are buying throughput, labour reduction, quality consistency, or safety. They lead to different machines, and a design optimised for one is rarely optimal for another.
Then write down the number: parts per hour, at what quality level, across which variants. That number is the contract.
3. Give them every variant, including the ugly ones
The single most common cause of cost growth.
Buyers send the common part and mention the others later. Variants drive tooling complexity, and tooling complexity drives cost and schedule more than almost anything else. A variant introduced after design is locked is a change order and a delay. The same variant disclosed at RFQ is a design input and often costs very little.
Send them all, including the one that runs twice a year.
4. Tolerances are the real specification
A print with nominal dimensions describes a part you will rarely receive.
Automation has to work on parts at the edges of their bands, and when several components in an assembly arrive near their limits simultaneously, the cumulative stack-up can exceed what standard tooling accommodates. In volume production that is not a rare event.
Send the tolerances. Better, send a box of real parts, including the ones you would normally reject.
5. Decide flexibility deliberately
Robots or fixed automation is not a technology preference. It is a bet on how long the part will last.
Fixed automation is faster and cheaper for a known, unchanging process. Robots cost more and can be redeployed when the program ends.
One Tier 1 customer specified robots over hard automation explicitly because they were thinking past the current vehicle program. It made the project more complex and more expensive, and it means that line has a second life available to it. That was the right call for them. It is not the right call for everyone.
Ask the question at design stage: what happens to this machine when the part changes?
6. Send your standards with the RFQ
Your plant has a PLC platform, a safety standard, a network architecture, and tag conventions. Your maintenance team knows them.
If you do not send that specification, you will receive a machine built to somebody else's preferences, and your team will inherit equipment they cannot support. Send it with the RFQ, and treat how an integrator responds to it as part of the evaluation.
7. The cheapest quote is telling you something
When one quote comes in well under the others, it usually means it contains less engineering, not better value.
Compare what is actually in each: design hours, simulation, prove-out with real parts, documentation, training, commissioning support, spares. The gap is almost always in those lines. They are the ones that determine whether the machine runs.
8. Budget for prove-out with real parts
Simulation gets you close. Only physical parts confirm pick positions, orientation sequences, and clearances.
That means pulling production parts off a floor that still has orders to fill, and coordinating so it does not disrupt you. On one aerospace cell, getting parts for every variant in sufficient quantity was effectively a project inside the project.
Plan for it. It is not a contingency, it is a phase.
9. Agree what acceptance means, in writing, early
Define the acceptance test before the design is finished: which parts, how many, what rate, what quality level, measured how, over what duration.
Acceptance criteria written at the end of a project get negotiated under schedule pressure by people who are tired. Written at the start, they are an engineering target everyone designs toward.
10. Buy the support, not just the machine
The machine runs for a decade. The build takes months.
Before you sign, know: who answers when it faults, whether the documentation is good enough for your team to clear a fault unaided at 2am, what spares to hold, and whether training will be repeated in two years when the team has turned over.
11. Expect something to change
On any project where multiple parties build in parallel, something will move. A third-party interface will shift, a part will change, a date will pull in.
The question is not whether it happens but whether the project absorbs it. Ask an integrator how they handled a mid-project change, and listen for whether they had the design work in place to adapt quickly, or whether the schedule simply slipped.
The short version
Most automation projects that disappoint were decided badly before they were built badly. Stabilise the process, define the number, disclose every variant, send your tolerances and your standards, and buy the engineering rather than the lowest price.