How to Prepare an Electronics Quote Request

Who this article is for

This material is for customers who want to ask about electronics design, prototyping, NPI, PCB assembly or electronic device manufacturing.

Typical situations include:

• you have an idea for a device and want to understand the cost of further work,
• you have a prototype and want to prepare it for production,
• you have PCB documentation and are looking for electronics assembly,
• you have a product after a previous supplier and want to organize production,
• you import a finished product and are considering your own production,
• you want to compare EMS offers but do not know what information is needed,
• you need a quote not only for a board, but for a complete device with final testing.

If the project is simple and the documentation is complete, an RFQ can quickly lead to a quotation. If the project is incomplete, the RFQ should first help identify what is missing.

What an RFQ means in electronics design and manufacturing

An RFQ is a request for quotation whose purpose is to obtain a price, lead time and scope of delivery. In electronics manufacturing, an RFQ may cover different things: electronics design, prototype build, PCB assembly, production preparation, testing, firmware programming, enclosure integration or serial production.

The problem is that these scopes are often mixed in one request. A customer asks for production but actually still needs design work. They ask for PCB assembly but expect a finished device. They ask for a unit price but do not have a final test, an up-to-date BOM or volume information.

A good RFQ should therefore answer three questions:

• what exactly needs to be quoted,
• what stage the project is at,
• which data is certain and which data is still an assumption.
• Without this, a partner may prepare an offer, but it will depend on interpretation. Two offers based on different interpretations are not comparable.

Why comparable offers matter more than the number of offers

Many customers send the same request to several suppliers and expect a simple price comparison. This only makes sense if every supplier quotes the same scope, the same volumes, the same tests and the same level of responsibility.

In practice, this is often not the case. One partner assumes they will buy components and take responsibility for BOM completion. Another assumes that the customer will supply the parts. A third includes functional testing, while a fourth includes only visual inspection. One includes tooling preparation, while another shows it later as an additional cost.

That is why a well-prepared RFQ should force comparability. The customer should specify whether they expect a quote with component sourcing, without component sourcing, with testing, without testing, with firmware programming, with packaging, with final assembly or only for PCB assembly. If an element should be optional, it is worth asking for it as a separate line item.

The best offer is not always the lowest price. The best offer clearly shows the scope, assumptions, risks and conditions for moving to the next stage. This helps the customer make a decision based on facts, not on a price that looks attractive only because part of the work is missing.

RFQ, RFI and RFP: what is the difference?

In practice, the customer does not always need an RFQ immediately. Sometimes an RFI or an RFP is a better first step.

RFI, or request for information, is used to check whether a potential partner has the right capabilities. It is useful when the customer is still looking for a supplier and wants to ask about services, experience, technologies, testing, NPI approach, quality, traceability or firmware support.

RFP, or request for proposal, is broader. It checks not only the price but also the proposed approach. It makes sense when the project requires technical cooperation, is not fully defined or the customer is looking for a partner for a larger process: from concept through prototype to production.

An RFQ works best when the scope is specific enough to prepare a quote. If the customer has only an idea and expects a serial production price, they are formally asking for an RFQ, but in reality they first need analysis or an RFP.

In practice, an EMS RFQ should combine purchasing language with technical language. A quote request for electronics manufacturing cannot be limited to price, because the partner must also assess component, testing, documentation, timing and supply chain risks.

The most common mistake: asking only for a unit price

The unit price is important, but in electronics, asking for it too early often leads to poor decisions. If it is not clear whether the product has a final test, what the BOM looks like, whether firmware must be programmed, what the enclosure looks like and what the production scale is, the price will only be an estimate.

The biggest problem appears when the customer compares offers without checking what they include. One offer may include component sourcing, assembly, programming and testing. Another may cover only SMT assembly. A third may not include tooling preparation, while a fourth may assume that the customer supplies all components.

As a result, the cheapest offer may not be the best one. It may simply be the least complete.

A good RFQ should make the scope clear: what is included in the price, what is excluded, what assumptions were made, what requires clarification and which costs are one-off.

First define what you are really looking for

Before sending an RFQ, it is worth naming the starting point. This shortens the discussion and reduces the risk of misunderstandings.

Typical scenarios:

If you do not know which scenario fits your situation, it is worth saying so directly. A good partner should help determine whether you need a production quote or an analysis stage first.

RFQ for electronics design

A request for electronics design should describe the problem, not only the expected solution. At the beginning, you do not need to have a schematic or PCB. You do need to describe what the device should do, where it will operate, who will use it and which constraints matter most.

For a design RFQ, it is worth providing:

• a description of the device functions,
• the operating environment,
• power supply requirements,
• communication requirements,
• size constraints,
• expectations for the enclosure,
• firmware requirements,
• expected volume,
• regulatory or industry requirements,
• target product cost, if known.

At this stage, the quote usually covers design work, prototyping and first validation. The serial production price can only be indicative, because there is no final BOM, test strategy or production documentation yet.

The transition from idea to product is described in the Inventronics product development process.

RFQ for a prototype

A prototype request should clearly separate two goals: checking functionality and preparing for production. A demonstration prototype may work, but it does not have to be ready for serial production.

For a prototype RFQ, it is worth providing:

• the current project stage,
• available files and documentation,
• number of prototypes,
• expected test scope,
• firmware programming method,
• enclosure or mechanical requirements,
• critical components,
• known technical issues,
• decisions that the prototype should confirm.

If the prototype is meant to be a step toward production, DFM, DFT, testing and documentation should be discussed from the start. Otherwise, it is possible to build a demonstration unit that later requires major changes before serial production.

RFQ for NPI and production preparation

NPI, or new product introduction, is often missing from quote requests. A customer asks about assembly, but the product does not yet have a stable BOM, a test procedure, quality criteria or a plan for the first production run.

An NPI RFQ should include:

• documentation review,
• BOM analysis,
• component availability assessment,
• DFM and DFT,
• test preparation,
• firmware programming procedure,
• pilot run plan,
• acceptance criteria,
• ECO/ECN change handling,
• a plan for moving to repeatable production.

This is especially important when a project is stuck between prototype and production or when the customer wants to transfer production from another supplier. In such situations, a sensible first step may be a diagnostic phase such as NPI Rescue.

RFQ for PCB assembly

A PCB assembly request is most concrete when the customer has a complete set of production data.

The minimum data set includes:

• Gerber files or full PCB production data,
• BOM with manufacturer part numbers,
• centroid or pick-and-place data,
• assembly drawing,
• information about variants,
• SMT and THT requirements,
• quality requirements,
• volumes and schedule,
• information on who buys the components,
• test scope after assembly.

If some data is missing, a quote may still be possible, but it should include assumptions. It is worth marking immediately what is current, what is preliminary and what is not available yet.

RFQ for a complete device

A complete device is more than an assembled board. An RFQ for a device should also include the enclosure, mechanical parts, harnesses, connectors, labels, firmware, configuration, final testing, packaging and logistics requirements.

In the industry, this scope is often called box build or final assembly. The customer does not have to use these terms, but should clearly state whether they expect only electronics or a device ready for shipment.

For this type of RFQ, it is worth providing:

• product structure,
• final assembly scope,
• list of mechanical parts,
• packaging requirements,
• labeling method,
• final test procedure,
• traceability requirements,
• acceptance criteria for the finished device,
• responsibility for sourcing non-PCB parts.
• This matters because integrating electronics with the enclosure often reveals issues that are not visible in PCB files alone.

How to describe volumes and timing

Volumes are one of the most important parts of an RFQ. Five prototypes, a pilot run, the first hundred units and repeatable production over several years are quoted differently.

In the request, it is worth separating:

• number of prototypes,
• planned first production run,
• expected monthly or quarterly production,
• annual production,
• possible volume increases,
• expected launch date,
• preferred delivery rhythm.

If you do not know exact volumes, provide scenarios. For example: 5-10 prototypes, first run of 50 units, annual production of 500-1000 units. This is better than no information, because the partner can assess whether the process should be prepared for manual small-batch startup or for larger repeatability from the beginning.

Timing should also be described realistically. If the project requires component sourcing, PCB fabrication, assembly, programming, testing and an enclosure, the delivery time depends on the slowest element. An overly aggressive deadline in an RFQ may lead to an offer with many assumptions or to important preparation steps being skipped.

A good partner should separate the time needed to prepare the process from the time needed for production itself. The first batch usually requires more engineering work than later batches.

One-off costs: NRE, tooling and test preparation

In an RFQ, it is worth asking not only about the unit price but also about one-off costs. In electronics, these can be significant, especially for new projects, prototypes, NPI and complete devices.

One-off costs may include:

• documentation analysis,
• process preparation,
• SMT stencil,
• test adapters,
• assembly fixtures,
• test program preparation,
• firmware programming procedure preparation,
• first batch validation,
• production documentation,
• design changes for DFM or DFT.

In the industry, such costs are often called NRE, or non-recurring engineering. For the customer, the key point is not the term itself, but understanding which costs appear once and which costs repeat in every batch.

When comparing offers, the customer should check whether one-off costs are shown separately. An offer with a low unit price but hidden preparation costs may turn out to be less attractive than a more expensive but transparent offer.

IP, confidentiality and ownership of documentation in an RFQ

An RFQ often requires sharing technical documentation. This may include schematics, PCB files, BOM, firmware, mechanical drawings, test data, a description of product behavior and information about problems in current production. This is sensitive data.

Before sending full documentation, it is worth agreeing confidentiality rules. In many cases, an NDA is needed, especially if the project contains proprietary technical solutions, firmware, end-customer data or information about costs and suppliers.

It is also worth checking who owns the documentation. This often becomes a problem in projects developed by several subcontractors or during production transfer from a previous supplier. The customer may have the product but not full rights to source files, tooling, test programs or firmware code.

That is why the RFQ should indicate which data the customer has, which data can be shared and which items need clarification. If the goal is long-term production, documentation rights and change handling are as important as the assembly price.

How to ask for quote variants

If a project has several possible paths, it is better to ask for variants instead of one combined price. This is especially useful when the customer does not yet know whether to start with a prototype, a pilot run, full NPI or immediate production.

Example variants:

• quote for documentation review only,
• quote for prototypes without serial production preparation,
• quote for prototypes with DFM/DFT analysis,
• quote for a pilot run with final testing,
• quote for production with component sourcing,
• quote for production with customer-supplied components,
• quote for a complete device with enclosure assembly and packaging.

This structure helps show where the cost is created, which decisions affect lead time and where the risk of wrong assumptions can be reduced. It also makes internal discussion easier, because management, purchasing and engineering teams can see what they are actually paying for.

What data to prepare for every RFQ

Regardless of the scenario, a good RFQ should include several groups of information.

• Product description and use case
  What the device does, where it operates, who uses it and what the consequences of failure are.
• Project stage
  Whether there is only an idea, a prototype, a PCB design, a first batch or production at another supplier.
• Expected service scope
  Design, prototype, PCB assembly, component sourcing, NPI, testing, firmware, enclosure, final assembly or serial production.
• Technical documentation
  Schematic, PCB, BOM, production files, drawings, mechanical models, assembly instructions, test description and firmware.
• Volumes and timing
  Number of prototypes, first batch, annual production, preferred schedule and expected flexibility.
• Quality and regulatory requirements
  Standards, certificates, operating environment, traceability, acceptance criteria and end-customer requirements.
• Main risks and concerns
  Component availability, cost, timing, quality, IP, testing, firmware, production transfer or problems with a previous supplier.

If the request concerns repeatable production, it is also worth adding information about the expected supply model: production on demand, safety stock, scheduled deliveries, component sourcing by the partner or customer-supplied components. This helps assess not only price, but also operational risk.

You do not need to have everything perfect. You do need to show what is known and what still needs clarification.

What to do if the documentation is incomplete

Incomplete documentation does not stop the discussion. It only stops the expectation that a reliable serial production offer can be prepared immediately.

If data is missing, the best approach is to say it directly in the RFQ. For example: “we have a working prototype but no formal test procedure”, “the BOM needs verification”, “firmware is developed by an external team”, “the enclosure is still being designed”, “we do not know whether documentation from the previous supplier is complete”.

This honesty shortens the process. The partner can then propose an analysis stage, documentation review or NPI instead of pretending that everything is ready for production.

Table: minimum data for different quote requests

This table does not replace a technical discussion, but it helps prepare the request so that the partner can identify risks faster.

Common mistakes in RFQ requests

The most common mistake is sending only the BOM and expecting the full price of a finished device. The BOM is important, but it does not describe testing, quality, final assembly, firmware or production risks.

Other common mistakes include:

• no volume information,
• no distinction between prototype and serial production,
• unclear component sourcing responsibility,
• no test information,
• no acceptance criteria,
• no product variant information,
• omitting firmware and programming,
• no enclosure and packaging data,
• expecting comparable offers for different scopes,
• hiding problems from current production.
• A good RFQ does not have to be long. It has to be specific. The less the partner has to guess, the better the chance of receiving a useful quote.

How Inventronics can help

Inventronics can help customers prepare a project for quotation even when the input data is not yet complete. The discussion may cover electronics design, prototype, NPI, BOM review, PCB assembly, firmware, testing, enclosure integration and serial production preparation.

If the customer has an idea or prototype, the first step may be organizing requirements and risks. If the customer has finished documentation, the next step may be manufacturability, testing and quotation review. If the customer wants to transfer production, it is worth starting with a data audit and a re-NPI plan.

The most important point is not to pretend that every project is ready for immediate production. Sometimes the best answer to an RFQ is not a unit price, but a proposal for the first stage: analysis, documentation review or a pilot run.

Frequently Asked Questions

If you are looking for shorter answers before sending a request, see also the Inventronics frequently asked questions.

Summary

A good RFQ for electronics design and manufacturing is not a purchasing formality. It is a tool that helps organize the scope, project stage, technical data, risks and quality expectations.

The better the request is prepared, the lower the risk that the customer receives offers that are not comparable or look attractive only because they are incomplete. In electronics, the most expensive items are often not those visible in the unit price, but those missing from the scope: testing, firmware, documentation, NPI, enclosure, quality and change handling.

If you are not sure whether your project is ready for quotation, it is worth starting with a technical discussion. Sometimes the shortest path to a good offer is to organize the input data first.

Talk to Inventronics about a quote request for electronics design and manufacturing. We can help define the scope, missing data, risks and the shortest path to a meaningful quotation.