Custom Machine Development RFQ: What to Include Before Asking for a Quote

You are ready to ask someone to build your machine. You have a process, a rough concept, and a budget you would rather not discover halfway through the project. A useful request for quotation, or RFQ, turns that starting point into a brief an engineering team can evaluate. It does not need to be a finished design. It needs to make the important questions visible.

The difference matters because two suppliers can read the same short email and price entirely different projects. One assumes manual loading and a basic control panel. Another includes automatic feeding, payment integration, a custom PCB, and installation. Their numbers may be far apart without either supplier being wrong. A better RFQ lets you understand the difference before the purchase order makes it entertaining.

1. Explain the process before describing the machine

Begin with the work the machine must perform. Describe the incoming material or product, the operation, the acceptable output, and who handles each step today. Include the awkward details: variable part sizes, damaged packaging, wet surfaces, seasonal demand, or operators adjusting a position by feel. Those are not minor observations. They often determine whether the concept needs a sensor, a fixture, a different mechanism, or a human decision.

A short process video and representative samples can be more useful than a polished rendering. Annotate what happens during loading, normal operation, changeover, and recovery after a stoppage. If you have already selected a mechanism, explain why. Treat it as a constraint only when there is a real reason to preserve it. Otherwise, you may accidentally ask the engineering team to optimize the first idea rather than solve the actual problem.

For the broader design sequence, use our industrial machine design guide. This RFQ guide addresses the earlier purchasing question: what must a supplier know to propose that work responsibly?

2. Separate requirements from assumptions and preferences

Give each important requirement an identifier, an owner, and a way to verify it. "Compact" is a preference until you define the available installation envelope. "Easy to maintain" becomes useful when you identify the service task, access constraints, and tools available. You can keep an item unresolved, but label it as unresolved. A blank cell is an invitation for somebody else to make a decision on your behalf.

The distinction between a requirement and an implementation choice is worth protecting. "Provide an operator-readable fault message" describes a need. "Use this exact touchscreen" specifies a solution. Both can be legitimate, but they leave different room for engineering. Requirements engineering explains how to turn these statements into a traceable specification. Keep the RFQ readable, and attach detail where it earns its place.

3. Define throughput and quality together

Do not ask only for cycles per minute. Say what counts as a good output, which material is used, how loading works, and whether the number includes rejects, refilling, changeovers, or stoppages. A machine can perform a fast empty cycle and still miss the required production rate. The RFQ should describe the operating conditions under which the output must be demonstrated.

Consider an illustrative target of 240 acceptable units per hour. That is a 15-second average interval per acceptable unit. It does not automatically mean every motion can take 15 seconds. Loading and unloading may overlap with processing, or they may be sequential. Material variation may change the cycle. Ask the supplier to explain the timing model and its assumptions, then agree on a representative acceptance run rather than arguing about a number after delivery.

• State the acceptable output and the inspection method.
• Define normal material, allowable variation, and supplied samples.
• Specify the test duration and how stoppages or rejects are counted.
• Describe changeover, refill, and cleaning requirements separately.
• Record whether the output target is a design goal or a contractual acceptance requirement.

4. Describe the site, utilities, people, and interfaces

A machine does not operate inside its quotation. It operates at a site with available power, compressed air, network coverage, floor space, access rules, and people with particular skills. Record what is available and what the project must provide. Include upstream and downstream equipment, material handoff points, communication expectations, and the person responsible for coordinating integration.

For a connected kiosk, describe how payment, authorization, inventory, and connectivity interact. For a factory installation, describe operator access, maintenance practices, and how the machine enters a defined state when an adjacent process stops. Explain the intended use and foreseeable operating conditions so safety and compliance responsibilities can be scoped by the appropriate specialists. Avoid declaring the machine compliant because the brief contains the name of a standard.

Attach interface drawings and protocols when they exist. If they do not, list their creation as a deliverable. This is especially important when mechanical, electronics, and firmware development are shared between your team and the supplier. A boundary that belongs to everybody often turns out to be owned by nobody.

5. Ask for deliverables, exclusions, and customer responsibilities

Separate the engineering deliverables from the physical supply. A quotation might include design and a prototype but exclude tooling, certification work, production fixtures, installation, operator training, or cloud hosting. None of those exclusions is automatically unreasonable. The problem is discovering them after you have planned a launch around the assumption that they were included.

Name the customer inputs too: representative material, site measurements, access to existing equipment, gateway accounts, branding assets, and timely decisions. An RFQ should not make the supplier responsible for information only you can provide. Ask for a dependency list and identify the consequence if an input arrives late. That creates a manageable project rather than a surprisingly elaborate blame exchange.

6. Define acceptance before the prototype arrives

Acceptance should connect back to the requirement identifiers. Record the test setup, supplied material, operating conditions, measurement method, pass limit, witness, and evidence retained. Some requirements are checked by inspection or analysis; others need a demonstration or physical test. The NASA requirements-verification guidance provides a useful example of linking requirements to verification methods. Your machine brief can apply that traceability without adopting a space-program-sized document set.

Distinguish a factory test from checks that depend on the installed site. A supplier may demonstrate mechanical function in the workshop while final integration depends on your conveyor or network. Record what each stage proves, which issues may remain open, and who signs them off. Also agree on how deviations and retests are handled. "We will test everything later" sounds comprehensive but is not an acceptance plan.

7. Compare proposals using assumptions and deviations

Request a response against your requirement list, including any deviation or alternative. Then compare the proposed architecture, development stages, deliverables, schedule dependencies, and commercial exclusions. If one supplier suggests a standard controller and another proposes custom electronics, ask each to explain the lifecycle implications. The off-the-shelf versus custom controller guide gives you a framework for that discussion.

Use a clarification round before selecting. Resolve the differences that affect price or acceptance and keep the answers with the RFQ revision. Comparing a single total is quick, but it can reward the proposal that noticed the fewest problems. The useful question is whether each supplier has priced the same responsibilities and produced a credible route to the required outcome.

8. A copyable RFQ outline you can start with

Project and business objective:
Current process and known pain points:
Incoming material and representative samples:
Required output and quality criteria:
Throughput and operating assumptions:
Installation envelope and service access:
Utilities, connectivity, and external interfaces:
Known constraints and unresolved decisions:
Required engineering and physical deliverables:
Prototype quantities and included iterations:
Acceptance methods and retained evidence:
Customer inputs and approval responsibilities:
Target delivery window and budget context:
Support, handover, and exclusions to clarify:

Use the outline as a conversation starter rather than a form you must somehow complete perfectly before speaking to an engineer. If a critical unknown needs experiments, ask for a bounded discovery stage with its own deliverables. For example, the first stage could evaluate product handling and return a concept recommendation, risk register, and revised development scope. Paying to resolve uncertainty can be more useful than receiving a confident fixed price built on hidden guesses.

9. Send a brief that makes the next decision easier

Before issuing the RFQ, ask a colleague who was not involved in the concept to read it. Can they explain what the machine must do, how success will be checked, and what remains undecided? If not, improve those parts first. You do not need to solve every engineering problem. You need a shared basis for identifying the problems and deciding who will solve them.

At SolveMpire, an initial discussion can start with your process description, available samples, existing equipment, target quantity, and intended installation. Our engineering services span mechanical design, custom electronics, firmware, and connected systems. The machine development cost guide explains the budget categories to separate before comparing proposals.

If the process is not yet defined, the special purpose machine requirements guide explains how to observe manual work, capture material variation and operator decisions, and turn that evidence into a testable engineering brief before issuing an RFQ.

When preparing the final supplier demonstration, the practical FAT checklist turns acceptance requirements into procedures, representative conditions, configuration records, issue dispositions, and a release decision.