Turnkey PCB Assembly Procurement Ownership: Who Approves What?
Direct answer: The practical answer to "Which decisions stay with the customer in a turnkey PCB assembly project?" is to use a documented decision gate, not a generic supplier promise. The target outcome is a RACI-style decision model for BOM ambiguity, alternates, schedule, inspection, and delivery. Start with the engineering baseline gate: Customer approves design intent, revision, variant, and acceptance criteria. Then review the package and people who can approve exceptions. Hold the project when procurement begins before the baseline is coherent. 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?
Turnkey is often mistaken for transferring engineering authority as well as purchasing work. This guide helps engineering managers and buyers handing sourcing to a turnkey provider make decisions about responsibility and approval design. Its information gain is a procurement approval matrix that prevents silent substitutions. The framework below is a project-control tool, not a claim that one process, supplier, quantity, or lead time fits every board.
Turnkey Approval Matrix
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.
| Decision factor | How to evaluate it | Stop condition |
|---|---|---|
| Engineering baseline | Customer approves design intent, revision, variant, and acceptance criteria. | Procurement begins before the baseline is coherent. |
| Purchasing execution | Provider sources to the approved BOM and documented alternate rules. | A line requires engineering interpretation. |
| Substitution | Provider gathers evidence; customer engineering approves functional change. | Purchase would precede explicit approval. |
| Schedule tradeoff | Provider presents dependency and options; customer accepts impact and priority. | An expedite decision silently removes validation. |
| Inspection/test | Both parties agree coverage, limits, evidence, and failure disposition. | Testing is a label rather than a deliverable. |
| Delivery | Provider coordinates the agreed packaging and shipping scope; customer confirms destination needs. | Responsibility or Incoterm assumptions conflict. |
What turnkey transfers and what it does not
For the what turnkey transfers and what it does not step, use Engineering baseline as the control point. Customer approves design intent, revision, variant, and acceptance criteria. Treat this as a release decision rather than an administrative detail. Place the build on hold when procurement begins before the baseline is coherent. 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.
Decisions the provider can execute
For the decisions the provider can execute step, use Purchasing execution as the control point. Provider sources to the approved BOM and documented alternate rules. The useful evidence is a record another person can review without reconstructing the conversation. Place the build on hold when a line requires engineering interpretation. 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.
Decisions engineering must approve
For the decisions engineering must approve step, use Substitution as the control point. Provider gathers evidence; customer engineering approves functional change. This check should connect engineering intent to a purchasing or manufacturing action. Place the build on hold when purchase would precede explicit approval. 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.
Escalation rules for shortages
For the escalation rules for shortages step, use Schedule tradeoff as the control point. Provider presents dependency and options; customer accepts impact and priority. A short written rule is more valuable than a broad assurance because it exposes the next owner. Place the build on hold when an expedite decision silently removes validation. 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.
Approval records before purchasing
For the approval records before purchasing step, use Inspection/test as the control point. Both parties agree coverage, limits, evidence, and failure disposition. The aim is not maximum paperwork; it is to prevent an unapproved assumption from entering the build. Place the build on hold when testing is a label rather than a deliverable. 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.
Ownership matrix
For the ownership matrix step, use Delivery as the control point. Provider coordinates the agreed packaging and shipping scope; customer confirms destination needs. Close the step with an explicit pass, hold, or approved-deviation result. Place the build on hold when responsibility or Incoterm assumptions conflict. 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 turnkey pcb assembly topic owner. Supporting resources:
