OEM Temperature Controller RFQ Checklist: What to Send for an Accurate Quote

An OEM temperature controller RFQ should do more than ask for a unit price. It should give engineering and procurement enough shared information to decide whether an existing platform fits, whether an option must be added, or whether the project needs new hardware or firmware.

The goal is not to write a perfect specification before speaking with a supplier. The goal is to make assumptions visible. A useful RFQ identifies what is fixed, what is preferred, and what is still open for engineering review.

Start with a one-page application brief

Describe the equipment before listing controller features. Include:

• What the controller operates: cold room, display cabinet, chiller, greenhouse, process skid, or another machine.
• The controlled medium and normal operating sequence.
• Where the equipment will be installed and who will operate or service it.
• Whether the controller is a replacement, a private-label version, or part of a new machine design.
• Target markets and the party responsible for the finished equipment.
• Expected prototype quantity, pilot quantity, and annual planning quantity as estimates rather than commitments.

This context helps the supplier interpret every later requirement. A relay requirement without the connected load, or a sensor range without the application, is not enough to choose a safe architecture.

Separate requirements from preferences

Assign each item one of three labels:

1. Required — the product cannot be accepted without it.
2. Preferred — it creates value but may be traded against cost, schedule, or platform reuse.
3. Open for proposal — the supplier may recommend an implementation.

ISO/IEC/IEEE 29148 treats requirements engineering as a life-cycle activity covering the discovery, analysis, documentation, verification, validation, communication, and management of requirements. NASA's requirements checklist adds a practical test: requirements should be clear, unambiguous, measurable, and verifiable, with one thought per requirement where possible (NASA Systems Engineering Handbook appendix).

Instead of writing “the controller should be robust and easy to use,” write separate statements for allowable supply conditions, display information, permitted user actions, fault responses, and the test that will demonstrate each one.

Electrical and I/O package

Attach an electrical diagram even if it is preliminary. The RFQ should identify:

• Nominal power supply and expected variation.
• Loads controlled by each output, including the external contactor or relay arrangement.
• Required analog, temperature, humidity, current, digital, and communication inputs.
• Sensor type, cable length, connector, measurement range, and required control performance.
• Output type and the required normal state during power-up, sensor failure, communication loss, and controller reset.
• Earthing, isolation, overcurrent protection, and enclosure assumptions that belong to the finished equipment.

Do not specify only a relay current number. Provide the load type, switching device, duty, and protection arrangement so the output stage can be evaluated in context.

Control sequence and firmware behavior

A state or sequence table is usually clearer than a feature list. For each operating mode, show:

Include setpoint limits, differentials, timers, priorities, alarm delays, password levels, power-loss recovery, and which parameters must persist. For an existing refrigeration sequence, the articles on compressor anti-short-cycle delay and fan delay after defrost show why individual timers need to be specified as part of a complete state sequence.

HMI, language, and service workflow

Provide a screen or menu map rather than “custom display.” State:

• Display technology and approximate viewing distance.
• Values, units, icons, languages, and alarm messages required on each screen.
• Which settings operators, installers, and service staff may change.
• Required parameter export, reset, diagnostic, and firmware-update workflow.
• Brand assets supplied by the buyer and rules for their use.

If a touchscreen is being considered, document the tasks it must simplify. A larger screen is not automatically a better interface; see the decision framework in when a thermostat becomes an HMI.

Communication and data ownership

For Modbus or another protocol, attach a draft data-point list. Define which values are read-only or writable, scaling and units, update expectations, alarm representation, address configuration, byte and word order where relevant, and behavior when communication is lost.

The Modbus Organization describes Modbus as an application-layer client/server protocol whose services are organized through function codes (official specifications). The protocol alone does not define your product's register map. The RFQ still needs the required data model, permissions, exceptions, and compatibility expectations.

Also state who owns the register map, HMI source assets, configuration tools, cloud integration, and project-specific firmware deliverables.

Mechanical, environmental, and production inputs

Include a dimensioned panel drawing, available depth, mounting method, terminal access, cable direction, enclosure or ingress requirement, operating and storage environment, expected condensation or contamination, and any vibration or cleaning constraints from the host equipment.

For a new enclosure, provide industrial-design files or sketches, material and finish preferences, label artwork, installation method, and the surfaces that cannot move. Do not assume a new housing is part of a normal private-label request; it is a separate engineering and tooling decision.

Target-market and conformity information

Name the countries or regions where the finished product will be sold and identify the compliance owner. Do not write only “CE required” or “UL required.” Applicable legislation and standards depend on the finished product, its use, voltage, interfaces, and route to market.

For the EEA, the European Commission states that the manufacturer is responsible for identifying applicable requirements, carrying out the appropriate conformity assessment, preparing technical documentation, issuing the declaration of conformity, and applying the CE marking (European Commission guidance). IEC 60730-1 covers construction, operation, and testing requirements for automatic electrical controls within its stated scope, including controls associated with equipment used in commercial and industrial applications (IEC 60730-1:2022). Neither reference proves that a particular controller or finished machine complies; the project must determine the applicable route.

Ask the supplier to distinguish existing evidence from new work: current reports for an unchanged platform, evidence that may support an option, and assessment or testing that would be required after a custom change.

Branding, packaging, and commercial planning

Send vector artwork, label languages, rating-label fields, packaging hierarchy, barcode or serialization rules, accessory list, manual responsibility, shipment destination, and quantity scenarios. If forecasts are uncertain, give ranges and explain the launch plan.

MOQ, non-recurring engineering, tooling, sample cost, and schedule should be outputs of the agreed scope—not values guessed before the hardware, software, enclosure, compliance, packaging, and quantity inputs are known. Our separate guide explains how customization depth changes MOQ, tooling, and lead time.

The RFQ handoff checklist

Before sending the package, confirm that it contains:

• Application brief and target markets.
• Electrical diagram, I/O list, load information, and sensor details.
• Operating sequence, alarms, fault responses, and parameter table.
• HMI/menu map, languages, and branding assets.
• Communication data-point list and integration responsibilities.
• Panel cutout, envelope, mounting, terminals, and environmental conditions.
• Compliance goals and the named party responsible for the finished product.
• Prototype, pilot, and forecast quantities.
• Acceptance criteria, deliverables, IP expectations, and change-approval contacts.

Standard, optional, or project-evaluated at Beamform

Beamform's published product pages describe standard controller families and model-specific functions. Features identified there as optional must still be confirmed for the selected model and project. Changes to PCB layout, input/output circuits, relay arrangements, sensor interfaces, firmware logic, HMI, protocol, enclosure, branding, or packaging are project-evaluated custom work—not assumed stock configuration.

Final feasibility, cost, MOQ, tooling, compliance work, and schedule can only be assessed after the specification is reviewed. Browse the controller range, read what can actually be configured in an OEM controller, or contact Beamform with the checklist above.

FAQ

Can I request a quote before the electrical diagram is final?

Yes, but mark assumptions and open items clearly. Ask for a budgetary or platform-selection response first, then update the quote after the load, I/O, and protection design is baselined.

Should I send a competitor's product as the specification?

It can illustrate size or workflow, but it does not replace your own requirements and may create intellectual-property or compatibility ambiguity. State the functions and interfaces you actually need.

What is the minimum information for a useful first review?

Application, supply, load and I/O list, control sequence, panel constraints, target market, required interfaces, estimated quantity, and the boundary between required and negotiable features.

When should pricing become firm?

After both parties agree on the configuration baseline, deliverables, validation scope, packaging, quantity basis, and treatment of later changes.

Sources

• ISO/IEC/IEEE 29148:2018 — Requirements engineering
• NASA Systems Engineering Handbook — requirements and V&V appendices
• European Commission — manufacturer responsibilities for CE marking
• IEC 60730-1:2022 — Automatic electrical controls, general requirements
• Modbus Organization — specifications and implementation guides