How to Prepare a PCB Assembly RFQ That Gets an Accurate Quote
Direct answer: The practical answer to "What information makes PCB assembly quotations complete and comparable?" is to use a documented decision gate, not a generic supplier promise. The target outcome is a scope-first RFQ worksheet and quote-normalization checklist. Start with the build scope gate: State prototype, validation, pilot, or repeat batch and the decision it supports. Then review the package and people who can approve exceptions. Hold the project when suppliers assume different service levels. Exact manufacturing, inspection, sourcing, and test scope depends on the selected design and partner. This guide makes scope explicit before quotation, release, or the next build decision.
What decision does this guide support?
A price cannot be compared when fabrication, sourcing, test, packaging, and delivery assumptions differ. This guide helps engineers and procurement staff requesting comparable quotations make decisions about RFQ completeness and quote comparison. Its information gain is an apples-to-apples RFQ scope matrix. The framework below is a project-control tool, not a claim that one process, supplier, quantity, or lead time fits every board.
RFQ Information Checklist
Use this framework at the point where a project could otherwise move forward on an assumption. Each row names the evidence needed and a condition that should stop release until an owner resolves it.
| Checklist item | Required evidence | Hold condition |
|---|---|---|
| Build scope | State prototype, validation, pilot, or repeat batch and the decision it supports. | Suppliers assume different service levels. |
| Files | Provide fabrication, BOM, CPL, drawings, variants, and revision identity. | The package cannot be reconciled. |
| Sourcing | State consigned/turnkey split, alternates, source controls, excess, and ownership. | Quotes use different purchasing assumptions. |
| Quality scope | Define inspection coverage, acceptance criteria, test, data, and failure handling. | The word tested has no shared meaning. |
| Commercial basis | State quantities, recurring demand, schedule driver, packaging, destination, and terms needed. | Delivered scope differs across quotes. |
| Normalization | Compare inclusions, exclusions, assumptions, one-time costs, and material exposure line by line. Use the transaction-specific PCB and PCBA landed-cost method to keep policy, quote, freight, commercial, inventory, and execution inputs separate. | A lower headline excludes required work. |
Define the build stage
For the define the build stage step, use Build scope as the control point. State prototype, validation, pilot, or repeat batch and the decision it supports. Treat this as a release decision rather than an administrative detail. Place the build on hold when suppliers assume different service levels. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
Required manufacturing files
For the required manufacturing files step, use Files as the control point. Provide fabrication, BOM, CPL, drawings, variants, and revision identity. The useful evidence is a record another person can review without reconstructing the conversation. Place the build on hold when the package cannot be reconciled. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
Sourcing and substitution rules
For the sourcing and substitution rules step, use Sourcing as the control point. State consigned/turnkey split, alternates, source controls, excess, and ownership. This check should connect engineering intent to a purchasing or manufacturing action. Place the build on hold when quotes use different purchasing assumptions. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
Inspection, programming, and testing
For the inspection, programming, and testing step, use Quality scope as the control point. Define inspection coverage, acceptance criteria, test, data, and failure handling. A short written rule is more valuable than a broad assurance because it exposes the next owner. Place the build on hold when the word tested has no shared meaning. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
Packaging and delivery
For the packaging and delivery step, use Commercial basis as the control point. State quantities, recurring demand, schedule driver, packaging, destination, and terms needed. The aim is not maximum paperwork; it is to prevent an unapproved assumption from entering the build. Place the build on hold when delivered scope differs across quotes. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
Normalize quote assumptions
For the normalize quote assumptions step, use Normalization as the control point. Compare inclusions, exclusions, assumptions, one-time costs, and material exposure line by line. Close the step with an explicit pass, hold, or approved-deviation result. Place the build on hold when a lower headline excludes required work. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
How to use the framework on a real project
- Define the baseline. Identify the board revision, assembly variant, quantity, intended learning or delivery outcome, and files being reviewed.
- Assign decisions. Name who can approve engineering changes, sourcing substitutions, process deviations, test failures, and schedule tradeoffs.
- Record the result. Store the pass, hold, or deviation outcome with the build package so a repeat order does not depend on memory.
Questions to close before release
What evidence is sufficient?
Evidence should match the risk. A file reconciliation may be enough for one decision; a datasheet comparison, inspection record, controlled test, or engineering approval may be needed for another. The key is that the evidence is named before work proceeds.
Who owns an exception?
The party executing purchasing or manufacturing can identify an issue and present options, but changes to functional intent require an authorized customer engineering decision. Put that boundary in the RFQ or release record.
When should the project stay on hold?
Hold when the next action would make an unresolved assumption expensive, irreversible, unsafe, or difficult to trace. A documented hold is usually less costly than discovering after assembly that teams used different revisions or acceptance criteria.
Related Cyrionix resources
This guide strengthens the services topic owner. Supporting resources:
