Sales-to-engineering handover for industrial OEMs

An industrial OEM does not finish selling when the customer sends the purchase order. The company now has to turn a customer-facing promise into engineering, sourcing, manufacturing, quality, project and billing work. Every ambiguity that survives the handover becomes a late question, a design change or an unpriced obligation.

The usual kickoff meeting cannot carry this load. People forget context. Slides go stale. The strongest estimator may know why the quote excludes a test, but the project engineer needs that fact six months later when the customer asks for it.

A proper handover creates a released order baseline, allocates each commitment to owned work and keeps unresolved engineering visible. The meeting reviews that record. It does not create it from memory.

Define the handover as a release

Set a clear entry condition. Customer PO review has resolved the material differences between the order and accepted offer. The sales order reflects the cleared deal. The company knows which work may start and which work remains blocked by payment, customer data, approvals or technical decisions.

Set a clear exit condition too. Engineering and delivery have received the current technical and commercial baseline, every commitment has an owner, open items have dates and dependencies, and the target systems contain the linked project, configuration and order records.

Do not use “kickoff held” as completion. A meeting can end while the project still lacks the governing specification, option selection, delivery basis or design input. Release the package after the accountable owners accept it.

Start from the deal the company released

Use the accepted quote, final proposal, customer PO, order comparison, acknowledgment and approved sales order as the handover source. Name each document and revision. A project team should never have to choose among “final,” “final v2” and “client final” files.

Preserve the decisions behind the released offer. A quoted schedule may depend on customer drawings. A low margin may have approval tied to a standard scope. A supplier price may expire unless procurement releases it within ten days. These conditions belong in the handover because execution can invalidate the deal.

Link the baseline to the customer acceptance evidence. The team needs to know what the customer bought, what the seller qualified and which points remain subject to customer action.

Separate the approved baseline from the work engineering still has to do

Engineering needs two things at once: a stable boundary and permission to develop the design inside it. The handover should state the product configuration, performance, interfaces, codes, tests, documents and customer dependencies that the company has committed to. It should also identify the calculations, drawings, selections and design decisions that remain open.

Do not label an open design choice as an assumption after award. Turn it into owned engineering work with a due date, inputs, decision authority and downstream dependents. If the customer must approve the result, state the approval event and its schedule effect.

The baseline controls change. The open-work plan controls completion. Combining them in one loose issue list makes the team unsure which facts it can rely on.

Create the requirement baseline and its trace

Extract the customer requirements, seller responses and final dispositions into controlled records. Preserve the verbatim source, document revision and location. Add the agreed interpretation, responsible discipline, verification method and allocated system or subsystem.

Maintain traceability from the customer requirement to the offered response, engineering requirement, design output and test evidence. The NASA Systems Engineering Handbook describes bidirectional traceability across customer requirements, product requirements, design documents and test plans. Industrial OEMs can apply the same discipline without adopting an aerospace process wholesale.

Flag requirements the proposal qualified, partially complied with or left for clarification. The handover must carry the accepted seller position. Copying only the customer sentence can make engineering design to a requirement the business explicitly excluded.

Release one product configuration

Name the base product, selected options, customer-specific characteristics, materials, voltage, duty, controls, standards, documentation and governing technical revisions. Use a configuration ID that ERP, PLM and the project can share or cross-reference.

ISO 10007 provides current guidance for configuration management across the product and service life cycle. For the handover, the practical requirement is simple: identify the configuration items, record their versions and control changes after release.

Do not release a configuration from the sales configurator and a different one from engineering. If sales options need engineering elaboration, link the released commercial configuration to the engineering baseline and show the transformation. Each downstream BOM, routing and work order should point back to that chain.

Turn the sold scope into deliverables and work packages

Decompose the customer-visible scope into deliverables that the company can design, buy, make, install, commission and prove. Preserve the link back to the commercial line. A single “automated packaging line” item may become equipment modules, controls, documentation, FAT, freight, installation, training and SAT deliverables.

IFS Project Deliverables distinguishes the deliverable structure from the planning items used to manufacture, purchase, ship, install and commission it. That is a useful model even outside IFS: define what the customer receives, then define the work and supply that realize it.

Allocate cost budget, schedule, requirements and acceptance criteria at the level the team can manage. Avoid one giant project task that hides late engineering and avoid hundreds of micro-tasks that nobody maintains.

Carry the schedule promise and its start conditions

Translate the customer commitment into project milestones and dependencies. State what starts the clock, what event completes it and which customer actions affect it. “Shipment in 44 weeks” needs a start event such as cleared advance payment and approved interface data.

Separate requested, accepted and planned dates. Engineering should see the customer commitment and the internal plan that supports it. If the internal plan has no margin or already misses the accepted date, escalate before release.

Map billing and acceptance milestones to the same project events where appropriate. Design approval can drive both the next engineering phase and an invoice. FAT completion can release shipment and a billing milestone. Give each event one definition and several controlled consumers.

Hand over the commercial limits engineering can change

Engineering needs the cost target, approved contingency, supplier basis, margin-sensitive choices and authority for substitutions. The goal is not to expose every sales calculation to every user. The goal is to prevent a technical decision from spending contingency or changing customer value without the right review.

State which changes remain inside the released design space. A gearbox supplier substitution may be acceptable if it meets performance, interface, approved-vendor and cost rules. A material change that alters warranty, certification or delivery needs a commercial decision.

Show the customer price only where it helps the role make a decision. Show engineering the cost and schedule effect of options, allowances and risk. Show the project manager the billing milestones and cash dependencies that can stop work.

Preserve the supplier and cost evidence behind the bid

Pass the selected supplier response, scope, exclusions, validity, lead time, freight basis and technical deviations into the project. A total cost line that says “vendor package” cannot support a purchase requisition six weeks later.

Mark costs that came from history, parametric models, budget quotes or firm supplier offers. Give sourcing a refresh trigger for expired or conditional evidence. Link each bought-out package to the customer requirement and deliverable it supports.

Do not issue supplier purchase orders from an old bid attachment without checking the released customer scope. The handover should prepare the package and expose differences. Purchasing remains accountable for the award and release controls.

Turn customer inputs into controlled dependencies

List every input the customer must provide: process data, loads, layouts, utilities, site scans, controls standards, network information, samples, approvals and access. State the required format, due date, owner and work that waits for it.

Request the input at handover instead of waiting for the responsible engineer to discover the gap. When the customer sends it, check completeness and revision before releasing dependent work. A received file is not automatically a usable input.

Connect delay treatment to the accepted contract. If the schedule depends on customer approval within ten days, record the request, receipt and review events. The project can then show the effect of late or incomplete data with evidence.

Release quality, test and document obligations

Give quality the inspection and test plan basis, customer hold and witness points, certificates, code requirements, approved suppliers, traceability duties and record formats. Give document control the submittal register, languages, templates, review cycles and final-data-book requirements.

Allocate every performance promise to a verification method and evidence owner. A guaranteed throughput needs defined feed, utility, environment, sampling and acceptance conditions. Engineering should see those conditions before design, not when the FAT procedure reaches the customer.

Link the requirement, design output, test procedure and result. If a customer comment changes the test basis, route the commercial and schedule effect before accepting it.

Create linked records in ERP, PLM and the project system

Create or connect the customer order, project, WBS, configured item, requirement set, document register, supplier packages and billing plan. Pass identifiers between systems so users can navigate the chain. Do not copy the entire proposal into generic notes in every system.

IFS can create a project from a customer order and connect customer-order lines to project activities. SAP assembly processing can generate project or network structures from sales demand. These native links should carry execution. The handover workflow should supply their inputs and preserve the decisions they do not store.

Validate the created records against the release package. ERP defaults can insert the wrong site or supply code. A project template can carry stale tasks. A PLM item can point to an old option set. Automation should compare the returned object with the approved source before releasing downstream work.

Use the kickoff meeting to decide, not to read documents aloud

Send the package before the meeting. Ask each owner to review its section and flag a decision, missing input or conflict. The meeting should resolve cross-functional questions: Can operations hold the date? Does engineering accept the requirement baseline? Which supplier packages need immediate release? Which customer input gates the critical path?

Walk through changes and risks, not every field. Confirm the baseline, open work, customer dependencies, first releases and escalation path. Record decisions directly in the handover case with the source and affected records.

End with named owners and near-term actions. A transcript and slide deck are supporting evidence. They are not the execution system.

Release work in stages when the order allows it

A complex order rarely becomes fully ready on one day. Release project setup, customer-data requests and low-risk standard work first. Release long-lead supply after its scope and authority clear. Hold fabrication until the design baseline and required approvals exist.

State the exact object and action each gate controls. A payment hold may block external spend but allow internal planning. An unresolved site load may block foundation design but not controls architecture. This gives the project speed without letting one open point contaminate the entire order.

SAP’s engineer-to-order turbine example shows a customer-specific coolant-pump assembly that can enter production before the entire turbine design finishes. The company can use staged release when it identifies the assembly, requirements, interfaces and change controls that make the early work safe.

Route every later change back through the baseline

A customer comment, engineering discovery, supplier substitution or schedule request can change the released order. Compare the request with the current baseline, identify affected requirements and records, and price the cost and schedule effect before implementation.

Oracle documents a configure-to-order flow where a sales-order revision updates the configured item and manufacturing work order. If production has already recorded transactions, the system can hold the work order and raise an exception. That behavior reflects the right boundary: execution state changes how the company treats a configuration change.

Preserve the old baseline, approved change, effective point and implementation status. Notify the teams that own affected drawings, work orders, purchase orders, tests, billing and customer documents. Closing the engineering change alone does not close the commercial change.

Compare software by the gap it closes

IFS, SAP and Oracle are strong when the company wants customer orders, projects, configurations, supply and manufacturing inside one enterprise suite. PLM products are strong for released product data, requirements and engineering change. Project tools are strong for schedule, cost and responsibility. None of those categories automatically reconstructs the accepted deal across CRM, proposal files, PO review, supplier evidence and approvals.

Bourne is best when sales-to-engineering handover spans several current systems and much of the source sits in documents, spreadsheets and email. It assembles the release package, finds the missing decisions, routes them to the right people and writes approved records into the systems that should own them.

Choose the enterprise-suite path when replacing the backbone is already the program. Choose PLM when engineering configuration and change control are the central gap. Choose Bourne when the company needs a working handover across the backbone it already has.

Worked example: hand over a $12.6 million waste-heat recovery system

An OEM wins a $12.6 million waste-heat recovery system for a cement plant. The released offer includes the heat exchanger, ducting, bypass damper, controls, engineering, FAT, supervision and commissioning. The customer selects a high-dust option and requires delivery in 62 weeks after advance payment and approved process data. Payment follows 20% order, 20% design approval, 40% FAT, 10% shipment and 10% SAT.

The sales order has six customer-visible lines. The handover builds 34 deliverables and work packages. It allocates 186 customer requirements to mechanical, process, electrical, controls, quality and documentation owners. It releases Configuration WHR-900 Rev 2, Process Specification Rev G and Interface Schedule Rev D. Fifteen engineering decisions remain open inside the approved design space.

The package identifies three immediate customer inputs: gas composition across five operating cases, existing-duct survey data and the plant control standard. Process design waits for the gas data. The general arrangement waits for the survey. Controls architecture waits for the control standard. Project setup, document-register creation and the requests themselves can start.

Two supplier packages need early attention. The bypass-damper quote expires in 12 days and supports the critical path. The selected heat-exchanger plate supplier has a 38-week lead time, but engineering must confirm the corrosion allowance first. The team releases the damper package under the approved baseline and holds the plates until process engineering closes the allowance.

At kickoff, sales explains one approved qualification: the performance guarantee assumes inlet dust below the stated maximum. Engineering accepts the requirement baseline. Finance confirms the advance payment. The delivery leader accepts the staged release plan. Four months later, a customer gas-analysis revision exceeds the dust basis. The trace points straight to the guarantee, exchanger design, supplier scope, schedule and proposal qualification, so the team opens one commercial change instead of redesigning in silence.

Measure handover quality in execution

Measure the time from order release to accepted handover, but do not stop there. Count missing inputs found after kickoff, design work repeated because the wrong baseline reached engineering, supplier packages reissued, and customer commitments discovered after execution starts.

Track how long each hold and customer dependency waits. Follow approved margin against the first project forecast. A fast handover that loses the supplier basis or warranty obligation will show up later as cost, delay or dispute.

Review a sample of closed projects against their original handover. Use the failures to improve the release template, source mapping and decision rules.

How Bourne runs the order handover

Bourne starts from the cleared customer order and gathers the accepted proposal, PO review, sales order, requirements, configuration, supplier responses, estimate, schedule and commercial approvals. It builds a release package with direct links to the source behind each commitment.

The workflow allocates requirements, creates deliverables and open engineering work, records customer dependencies, proposes project and system records, and shows the release conditions on each downstream action. Engineering, project, sourcing, quality and finance review the parts they own. The delivery leader accepts the complete package.

Bourne then creates or updates the approved records through available APIs or controlled browser workflows. ERP, PLM, project and quality systems continue to own execution. Bourne preserves the chain from customer promise to requirement, deliverable, decision and action, then reopens the affected chain when the order changes.

Arda Bulut

Arda Bulut is the co-founder and CTO of Bourne and HockeyStack. He leads engineering at Bourne, building the platform people use to create AI products, agents and automations.