quindart
← All articles

Factory Automation Requirements: A Template to Use Before Requesting Quotes

Define the operating problem, product variation, interfaces and acceptance evidence before asking automation suppliers to price a solution.

Use the interactive tool ↓
Two colleagues review an automation requirements checklist and sample part beside a machine.

A quotation cannot resolve an unfinished decision

A supplier receives a request for a faster packing station. One quotation includes automatic feeding; another assumes an operator presents each part. Both suppliers have answered the request reasonably. Their prices describe different jobs. Comparing the totals will not reveal which proposal fits the factory.

Before requesting quotations, write down the decision the equipment is meant to improve. Is dispatch waiting for packing capacity, inspection release, available packaging or a confirmed customer order? Follow several actual jobs through the relevant records, then watch the work with the people doing it. A recurring queue beside a machine is useful evidence, but its location does not establish its cause.

The requirements template accompanying this article is a working document for operations, engineering, purchasing, quality and maintenance. Complete it together before sending it to suppliers. Leave unknowns visible. An unanswered field with an owner is more useful than a confident assumption quietly copied into every quotation.

Excellence industrielle's 2025 report describes an industrial AI cohort that defined use cases, prepared requirements specifications and selected suppliers. That is useful context for the sequence of buying decisions, not evidence that any particular equipment will deliver a return. The template here is an original practical aid for making those decisions explicit. [1]

Describe the work before prescribing the machine

Start with the input and the acceptable output. Record product families, drawings and revisions, material condition, presentation, packaging and the point at which responsibility transfers to the next operation. Include the awkward products that actually occur, rather than only the part used in a demonstration. Distinguish today's range from possible future products so suppliers can price optional capability separately.

Consider a hypothetical manufacturer packing machined components. Some arrive dry in trays; others need a quality release and carry protective oil. A proposal tested only on clean, regularly spaced parts may work beautifully and still leave staff sorting the production mix by hand. The requirement should say which conditions the station must handle, which it may reject and where rejected work goes.

Do not prescribe a robot because a demonstration looked convincing. Specify the required outcome and genuine constraints, then invite suppliers to explain their approach. Where a particular technology or component is mandatory, record why. Maintenance familiarity, an existing interface or a validated process may justify a restriction; preference alone deserves discussion.

Give every important number a definition

Required output needs a time boundary and operating conditions. State whether a rate means a short uninterrupted cycle, an hour with routine replenishment, or a shift including changeovers. Separate good units from total cycles. Describe the product mix, staffing, upstream supply and downstream availability assumed in the target. Otherwise a supplier's technically correct speed claim can be commercially misleading.

Record the baseline in the same terms. If the current constraint is waiting for a release, do not turn all waiting time into an assumed equipment saving. Name who measured the baseline, when, and what was excluded. Mark forecasts as forecasts. A target is something the proposed system must demonstrate under agreed conditions, not a result the factory already possesses.

Set priorities before negotiating. Label each requirement mandatory, desirable or optional, and distinguish a safety or quality condition from a commercial preference. A supplier proposing a different approach should identify the affected requirement and the evidence supporting the alternative. Keep that discussion in the revision log rather than scattered across email attachments.

Specify the handoffs that make the station usable

The station will need to know what to run. Identify the authoritative source of the order, product revision, quantity and release status. Agree what happens when the schedule changes after work starts. If information is entered manually at first, specify who enters it and how the selection is checked. Calling a future connection an ERP interface leaves too much unresolved.

Define the return information as well: completed quantity, rejected quantity, stop state and exceptions relevant to planning. Ask how records are identified, timestamped and retained, and what happens during a communication interruption. A completed cycle and a completed order are different events. The template should make their relationship explicit without demanding that the supplier redesign the entire business system.

Walk the proposed arrangement with operators and maintenance. Establish access for replenishment, cleaning, inspection and service, along with utility and space assumptions. Have qualified people define the applicable safety and destination requirements. This document can assign that work and retain its evidence; it cannot replace a risk assessment or professional engineering review.

Write acceptance while there is still something to negotiate

For each critical requirement, specify a test, the representative material, the expected evidence and the person who accepts it. If changeover matters, test changeover. If unusual parts must be detected, include agreed examples. Record how interruptions, rejected work and recovery will be evaluated under an approved test plan. A video of the best cycle is insufficient evidence for a broader requirement.

Separate factory acceptance at the supplier from site acceptance after installation. The first can establish defined functions before shipment. The second addresses the installed equipment, actual utilities, surrounding processes and agreed integration. List anything that cannot be demonstrated until the site stage. Put unresolved items in a punch list with an owner and closure evidence, not in a verbal understanding that the commissioning team must later reconstruct.

Ask for a compliance matrix with each quotation. Suppliers should mark requirements as included, excluded, conditional or requiring clarification, and reference supporting documents. Request separate prices for tooling, integration, installation, training, documentation, spares and recurring support. A lower equipment price may remain attractive, but the comparison should show the total proposed scope.

Use the document to control the next decision

The finished document should let the buying team explain why the project is needed, which assumptions remain open and what evidence would justify proceeding. Assign one person to maintain the issue list and document revision. When a supplier or production team changes an assumption, assess the effect on cost, acceptance and surrounding work before approving it.

Quindart's starting point is the information behind production, checked against floor reality. A requirements exercise may lead to equipment, a software connection or a smaller process change. The useful deliverable is a specification the factory can defend and operate, including a clear reason to postpone a purchase when the case is not yet established.

Put the guide to work

Build your automation brief

Turn an operating problem into a brief your team and suppliers can work from.

Use the interactive tool

You can also export from the tool to discuss it with your team.

Sources

  1. Excellence industrielle Saint-Laurent: 2025 annual report, page 22