How to Choose a Systems Integrator: Questions That Reveal Competence

The way to choose a systems integrator is to ignore the brochure and ask questions that force specifics: who exactly will do the engineering, how acceptance will be tested and measured, what documentation you receive, and what happens when something breaks a year after go-live. Competent integrators answer with detail, numbers, and the occasional "that depends." Weak ones answer with confidence and adjectives. This post gives you the questions, and just as usefully, what good and bad answers sound like.

Why choosing a systems integrator is hard

Proposals converge. Every integrator's website shows the same photos of panels and robots, every proposal promises on-time delivery, and vendor partner certifications mostly certify that someone attended a training class. The variance that actually determines your outcome lives in unglamorous places: how a firm scopes work, who it staffs, how it tests, and what it hands over at the end. None of that is visible in a capabilities deck.

Reference calls help less than people hope, because nobody hands out unhappy references. The better strategy is interrogating process directly, since a firm cannot fake having a written acceptance procedure or a named engineer with relevant history. If you are new to what integrators actually do day to day, start with our systems integration basics primer and come back to the questions.

Do they interrogate your process before quoting?

The strongest single signal is whether their questions make you work. A good integrator asks for your worst parts, not your best. They ask for the real rate the line runs, not the nameplate rate. They ask about upstream variation, compressed air pressure and quality, available panel space, who will maintain the system and on which shifts, and whether they can stand at the line and watch it run before pricing anything. Scoping questions like these are the firm protecting you from their own assumptions.

The inverse signal is just as reliable. A confident fixed price produced from a two-paragraph email means the assumptions were priced instead of the project, and you will pay the difference later through change orders. Honest uncertainty has a recognizable sound: a phased proposal, sometimes with a paid feasibility or discovery step in front of uncertain scope, followed by a firm quote once the unknowns are retired. That structure is especially common, and especially warranted, on vision and AI-adjacent work.

As a hypothetical: two firms bid the same inspection cell. One returns a polished fixed price in three days. The other asks for fifty sample parts, including confirmed defects, and quotes a two-week paid feasibility study before committing to numbers. The second bid feels slower and reads worse in a spreadsheet, and it is almost always the one to take seriously.

Who will actually do the work?

There is a well-known failure pattern politely called the A-team problem: the principal engineer attends the sales meetings, and a junior hire you never met executes the project. Defend against it directly. Ask for the named lead engineer, their tenure, and projects of this type they personally executed rather than projects the company completed. Ask which portions will be subcontracted, since panel building, machine code, and site installation frequently are, and that can be fine, provided you know who supervises the subs and who owns the result.

Then ask for thirty minutes with the engineer, not the account manager. A short technical conversation about your actual parts and constraints reveals more than any reference call: whether they have seen your class of problem before, whether they push back on bad ideas, whether they say "I don't know" when they don't. Also ask what happens if the lead leaves mid-project. Firms with real documentation standards answer that calmly, because the project survives in the drawings and the repository. Firms without them change the subject.

What should you ask about testing and acceptance?

Two acronyms carry most of the weight. FAT, the factory acceptance test, proves the system at the integrator's facility before shipment. SAT, the site acceptance test, proves it on your floor with your product, your utilities, and your operators. Ask to see a redacted FAT procedure from a past project. A real one contains numbers: sustained throughput over a defined runoff period rather than a burst demo, fault-recovery tests such as killing power mid-cycle and documenting what happens, and for inspection systems, escape rate and false reject rate measured against an agreed sample set.

If acceptance criteria are not written and numeric before the purchase order, you will negotiate them during commissioning, which is the worst possible moment, since the integrator wants to leave and you want to withhold payment. Vision projects deserve extra rigor here: pin down who supplies the sample sets, how "defect" is defined, and what happens when real product variation exceeds what was quoted. A large share of the failures cataloged in vision system integration mistakes trace back to acceptance criteria that were never actually agreed. An eight-hour runoff at rate is a common and reasonable ask for a cell; negotiate the duration, but never skip the concept.

Documentation, source code, and life after go-live

Ask precisely what you receive at handover, and get the list into the contract. The reasonable baseline: as-built electrical drawings reflecting what was actually wired, commented PLC and HMI source code with no password protection, an I/O list, a network diagram with addresses, a spare parts list with vendors and part numbers, and training for both operators and maintenance. Source code ownership deserves a direct conversation, because some firms lock PLC code as a customer-retention device. Decline that arrangement. You are buying a machine you must be able to maintain, not a subscription to its author.

Then look past the warranty. Ask how remote support works and through what secured connection, who is allowed to connect and how access is logged, what response times cost after the warranty period, and what their change order process and rates look like with a real example. Firms that support their installations for years answer these questions fluently. Firms that build, invoice, and vanish have visibly never been asked.

Red flags and what integration actually costs

The patterns that should end a conversation quickly:

• A firm quote with no site visit and no questions about your worst parts
• Guarantees of 100 percent detection, zero false rejects, or a "no downtime" cutover
• Reluctance to name the engineers or to disclose subcontracting
• No written FAT or SAT procedure they can show, even redacted
• Locked or withheld source code as standard policy
• References that are all less than a year old, since systems look great at month three and truth arrives around year two

On cost, ranges are wide and honest people hedge them. Controls and vision engineering in North America commonly bills between $100 and $200 per hour. Single-cell projects tend to land between $30,000 and $100,000, and line-level integration runs from $100,000 well past $500,000 depending on scope, industry, and how much of the work must happen during production windows. The cheapest bid frequently wins the purchase order and loses the project, because the gap between bids is usually the assumptions nobody priced. Compare proposals on what is included, meaning documentation, runoff, training, and spares, rather than on the bottom line alone.

FAQ

What is the difference between FAT and SAT?

A factory acceptance test proves the system at the integrator's shop before shipment, catching problems while they are cheap to fix. A site acceptance test repeats the proof on your floor with your product, utilities, and operators, where integration realities surface. Skipping the FAT to save schedule usually costs more time at site than it saved.

How much does a systems integrator charge?

Hourly rates for controls and vision engineering commonly fall between $100 and $200 in North America, with project totals from tens of thousands for a single cell to several hundred thousand for line-level work. Treat any precise number offered before scoping as a guess wearing a suit.

Should you choose a local integrator?

Proximity genuinely matters for installation and emergency response, while design competence matters more than geography for everything else. A common and workable split pairs a remote design and controls partner with local electrical and mechanical trades. Either way, ask how remote diagnostics will work before you need them.

Do good integrators guarantee results?

They guarantee measurable acceptance criteria that both sides defined, usually after feasibility work has retired the big unknowns. Nobody honest guarantees outcomes before seeing your parts and data, so treat an unconditional guarantee as a red flag rather than reassurance.

Willowark works as an integrator and alongside other integrators, and we are happy to be examined with every question above; our approach is described under systems integration services. If you are evaluating partners for an automation or inspection project, contact us and bring your hardest questions first.