This is hardly surprising. Sales views requirements primarily from the customer’s perspective: what does the client company need? What was discussed? Which solution fits? Engineering must derive reliable technical specifications, configurations, and calculations from this. Later, the service department again needs information about what was agreed upon, planned, and actually implemented.
Things become critical when this knowledge moves from one stage to the next via email, Excel lists, meetings, or free text. Then a handover quickly turns into a translation and detective task. Better communication alone can’t solve this problem. What is essential is a common level of information and a central location. Which requirements apply? What assumptions have been made? What has already been confirmed? What needs to be technically verified? And who is responsible for it?
In this article, I will show you six typical handover errors between sales and engineering – and how machinery companies can structure their offer and order processes without turning them into a bureaucracy project.
Why the handover between sales and engineering is so important
In series production, an offer can be comparatively clear. In machinery and plant engineering, this often looks different: products vary widely, requirements are customer-specific, and technical dependencies are complex. Therefore, a sales opportunity must progressively evolve into a technically feasible and economically viable solution.
The handover from sales to engineering is an important checkpoint in this process. It connects what a client company needs and expects with what is technically feasible, calculable, and deliverable. Quality management also considers this connection. ISO 9001 requires you to verify product and service requirements before making a binding commitment. If requirements are not documented, they must be confirmed before acceptance.
- In practice, this means:
A good handover doesn’t simply transfer as much information as possible. It ensures the right information is clear, understandable, and available when needed.
Would you like to see what this Customer Experience process could look like with Dynamics 365 in mechanical engineering?
In our short video, we show how you can connect marketing, sales, and service on a common platform, simplify handovers, better use existing customer knowledge, and see where agentic AI makes sense.
The six most frequent handover errors in mechanical engineering – and how to avoid them
01
Requirements are described but not clearly defined
“High performance,” “particularly robust,” or “suitable for environment X”: what initially sounds clear in a customer conversation can mean several things for the technical design.
Sales knows the context of the conversation. The technical specialist who later works with the information may not have been present. Without context, they must interpret or ask questions. This costs not only time. Different interpretations can lead to different technical solutions.
Therefore, record requirements as accurately as possible. What performance is needed? What operating conditions apply? Which interfaces are planned? Which specifications are mandatory and which are merely desirable?
The earlier you answer these questions, the more robust the subsequent quotation process will be.
02
Assumptions suddenly look like facts
Not every piece of information is fixed at the beginning of a project. That’s normal. However, it becomes problematic when you can no longer distinguish what the customer has confirmed from what was assumed internally.
For example, the sales department assumes a specific configuration is sufficient. The technical team interprets this information as already agreed upon. In the calculation, it is ultimately treated as a fixed requirement. An assumption has become an unexamined fact.
The solution isn’t to avoid open issues. Quite the contrary: open issues must be visible. Using straightforward labels like “confirmed – accepted – open – pending technical review” can already be helpful. This turns uncertainty into actionable information.
03
The calculation begins with an information gap
For a reliable offer calculation, it is not enough to know the desired machine type. Depending on the product and business model, variants, quantities, special configurations, additional services, operating conditions, or other technical and commercial framework conditions may be relevant.
If this information is missing, a loop begins: the technical team asks questions, sales researches emails or conversation notes, follow-up questions go to the customer company, and then it goes back into the calculation.
“The key question is therefore not: ‘How do we calculate faster?’ But: ‘What information must be available for us to calculate meaningfully at all?’ Whoever defines these minimum requirements can already reduce feedback loops at their origin.”
Dennis Istel, Consultant, Arineo GmbH
04
The configuration is in the heads of individual experts
Which options are compatible? Which combination is technically excluded? What change leads to further changes? With complex products, much of this knowledge often resides in experienced employees’ minds. As valuable as this know-how is, it also becomes a bottleneck when individual specialists must check every request.
Product configuration therefore means more than just selecting options. It connects customer requirements with technical rules and dependencies. Current approaches for the machinery and plant engineering industries accordingly link configuration, technical feasibility, and offer processes. The central task here is: how do we make relevant product knowledge available so that sales and technical teams build on the same rules? The better this knowledge is structured, the earlier teams can identify technically impossible or incomplete configurations.
05
Business decisions do not reach the technology department
A discount is initially a sales decision. Nevertheless, commercial agreements can affect the economic viability of a technical solution. The same applies to custom services, additional services, or services included in the offer but not taken into account in the technical calculation.
This does not mean that the technology department needs to know every single business detail. What matters is a clear rule: all commercial decisions that influence the technical or economic evaluation of a solution must be part of the relevant handover information.
This prevents companies from having sales and technology departments working on the same offer but with different calculation bases.
06
Deadlines are promised before the prerequisites are clear
“Can you deliver by October?” For the client company, this is a simple question. Internally, the answer may depend on construction, configuration, procurement, manufacturing, and available capacities.
If a desired deadline becomes a promised date too soon, a dangerous gap can open between customer expectations and technical reality. Therefore, the status should also be included in deadline information: is this the preferred deadline? Has it been reviewed internally? Is it feasible under certain conditions? Or has it already been confirmed as binding? This distinction may seem trivial, but it can be decisive later in the project.
This transforms error-prone handovers into a seamless process.
The six errors occur at different points, but often share the same structural cause: information is captured but then doesn’t fit the required structure, isn’t in the right place, or lacks a clear processing status.
An example of a seamless process is a project in which we integrated the handover process directly into the existing CRM environment. Sales records requirements for a specific product there. The participating departments then track the subsequent calculation, documentation, and approval within the same process. This makes it clear to those involved which information is already available, what processing status has been achieved, and where a decision is still pending. Technically, the enhancement was implemented using the Microsoft Power Platform.
The example shows what matters: the technical handover must be so anchored in the process that information and processing statuses remain traceable for all parties involved. Companies should define which information must be available at which point in the offer process – and subsequently reuse this data as seamlessly as possible. Four approaches help with this.
01
Define the minimum information for a technical handover
A custom machine requires different details than a configurable serial product. Nevertheless, not everyone should have to re-evaluate what “ready” means for engineering.
Therefore, define a minimum viable handover: the smallest amount of information the next process stage can use to work meaningfully.
Minimum Viable Handover: These seven questions should be answered by a handover
What does the client company want?
What technical and engineering requirements are there?
What has already been agreed upon?
What statements did sales make to the client company?
What has been configured?
Which variants and options have been selected, and what dependencies are known?
What is still undecided?
What information is missing, and which points need technical review?
On what basis is the calculation made?
What quantities, variants, special services, and framework conditions apply?
What has been promised regarding price, performance, and deadline?
Which commercial framework conditions have already been confirmed and which have not?
Who sorts out the rest?
Who takes the next step for open questions?
It is not important to be able to definitively answer every question before the handover. The status must be clear. For example, information can be confirmed, accepted, open, or pending technical review. This lets engineering see at a glance what they can rely on and what still needs clarification.
02
Capture the information where the sales process already takes place
The next leverage point is where the information lives. If requirements initially appear in an email, then move to an Excel list, are supplemented in a meeting, and later recorded again in another system, additional handovers will inevitably arise.
With Dynamics 365 Sales, you can structure the sales process from the sales opportunity through products and offers to the order. Information from a sales opportunity can be reused for subsequent process steps.
For mechanical engineering companies, this is particularly interesting: the sales opportunity dataset can become the common starting point of the handover. In addition to classic sales information, you can also structure details relevant to technical review. Which fields and data are necessary depends on the respective product and process.
Instead of an email with the note “Can you take a look at this?”, the engineers now receive a defined process with traceable information and a clear status.
03
Specifically map engineering-related requirements
A CRM standard does not automatically know all the information relevant to your machines, systems, and variants. That’s precisely why the process should not be built around the system.
Dynamics 365 and the underlying Power Platform let you extend the common data context with company-specific structures. This can make sense, for example, when sales needs to capture additional information for a technical review: operating conditions, required performance values, interfaces, desired options, or other product-specific details.
For clearly defined use cases, a streamlined Power App can also be useful here. Instead of another Excel list, you create a structured input form, and the data flows directly into the common process. You can use such an application internally to capture technical requirements according to a defined schema. You can also design it for field staff so requirements are recorded in a structured way during customer conversations.
The benefit is more about what occurs with the information after input than the input format itself: it is directly available within the process context. It does not need to be transferred from a separate file or conversation note.
04
Integrate product knowledge into the sales process
With highly variant products, structured data capture alone is not enough. Sales also needs to know which combinations are technically possible. This is exactly where a product configurator can bridge the gap to engineering.
In one of our projects, for example, we developed an application with which field staff and client companies can jointly compile a machine configuration – working on similar principles as a vehicle configurator. During the customer conversation, we not only document requirements but also select concrete product options.
For products with many variations, the input requires corresponding product logic in the background: which options are compatible? What dependencies exist? When is a technical review required? Product rules and dependencies that are otherwise primarily known to experienced specialists can be stored in the configurator in a structured way. This enables verification of permissible configurations and identification of areas needing further technical clarification during the sales process.
A possible addition to Dynamics 365 is, for example, Experlogix CPQ. Such a configuration solution can play an important role between CRM and ERP processes: on one side are customer requirements and sales information; on the other, the product, calculation, and order.
The configurator helps develop a technically feasible configuration from the requirements. The goal is not to remove technical specialists from the offer process. Rather, their knowledge should be used where it is actually needed – for exceptional cases and demanding technical decisions instead of repeatedly checking known product rules.
From sales handover to the 360-degree view of the client company
However, the process is not yet finished. What is learned about the client company and its machine during offer creation is also valuable later for other areas.
For example, service should not have to research which machine, and in which version, is at the client company. It needs the machine context to classify inquiries. Sales, in turn, benefits when service information is visible within the customer context. Marketing and sales can also develop existing relationships more effectively if relevant information doesn’t disappear into separate data worlds.
This is where a common Customer Experience platform delivers its advantage: the handover is not a one-time data transfer from A to B. Information remains usable throughout the customer relationship. With Dynamics 365, you can connect different Customer Experience processes on a common platform. Dynamics 365 Sales maps the sales process; further Dynamics 365 applications can supplement marketing and service processes.
“Instead of asking: ‘How do we pass this request to the technical team?’, consider how you can create a data context that advances sales, specialists, and service throughout the entire customer lifecycle.”
Dennis Istel, Consultant, Arineo GmbH
A Concrete Vision for Mechanical Engineering
What might such a process look like? A lead is qualified, and the sales opportunity is created in Dynamics 365. Sales staff record not only contact details and expected revenue, but also customer requirements relevant to the specific product.
Before the technical review begins, the process checks whether the defined minimum information is available. Missing details remain visibly marked as open. For products with many variants, a configurator helps to combine customer requirements with technical product rules. Special cases are specifically directed to the responsible specialists. Based on this, the system creates the quotation. Dynamics 365 links sales opportunities, products, and quotations, reusing information throughout the sales process. A traceable processing status simultaneously improves the data basis for pipeline and forecast.
When a quotation becomes an order, a new information chain does not start again. Relevant data can be passed on to downstream processes and systems. And when the machine is later in use at the client company, the existing customer and machine context is also available for further sales and service processes.
This creates end-to-end integration. Not because everything has to take place in a single system, but because information is passed on in a structured manner – and this does not have to be reassembled, interpreted, or entered again at each process step.
Does the entire IT landscape need to be rebuilt for this?
No. That’s often exactly the wrong starting point. Start with a concrete handover where you currently lose a lot of time.
Examine ten or twenty typical requests. What information did engineering regularly have to request? Which details were entered multiple times? Where did employees have to search through Excel files, emails, or notes from conversations? Which product rules did the same specialists always have to check? From this, we can develop an initial binding handover process.
Perhaps in the first step, a structured recording of additional requirements is sufficient. Perhaps a Power App for a specific process makes sense. Perhaps the greater leverage lies in a product configuration. Or sales and service currently work with such varied datasets that the initial focus should be on the common customer context. What’s important is that the technology follows the process – but the platform ensures that individual improvements can later become a coherent whole.
Conclusion: Good handovers begin with shared data
Sales and engineering pursue the same goal: to offer a solution that meets the client company’s requirements, functions technically, and can be implemented profitably. To achieve this, they must, above all, have access to the same reliable information – this saves manual information gathering, inefficient coordination loops, and errors.
Defining minimum information clarifies when a request can be processed technically. Structured statuses highlight assumptions and open questions. Product configuration brings technical rule-based knowledge earlier into the sales process. A common platform ensures relevant information doesn’t end up in the next data dead-end after handover.
This is where mechanical engineering companies gain more leverage than by optimizing a single interface: marketing, sales, and service can work from shared data and use customer context from the first contact through to after-sales.
Would you like to see what this Customer Experience process could look like with Dynamics 365 in mechanical engineering?
In our short video, we show how you can connect marketing, sales, and service on a common platform, simplify handovers, better use existing customer knowledge, and see where agentic AI makes sense.
Frequently asked questions about the handover between sales and engineering
The specific details depend on the product and process. A reliable handover typically includes customer requirements, existing agreements, the intended configuration, open technical questions, the calculation basis, and relevant commercial and time-related commitments. In addition, for any outstanding information, it should be clear what its status is and who is responsible for resolving it.
Dynamics 365 Sales can map sales opportunities, products, offers, and other sales information in a coherent process. You can supplement mechanical engineering-specific information with additional data structures and Power Platform applications, depending on the use case. This structures relevant information and makes it available for later steps in the process.
Not every Excel list needs to be replaced. It becomes critical when a spreadsheet becomes the central transfer medium for a recurring process, and information is manually transferred into other systems. In such cases, you can structure the required details directly in the sales process or via a suitable Power App.
A CPQ (Configure, Price, Quote) system can make product rules and dependencies usable for the sales process. This lets you configure possible product variants systematically and identify technically inadmissible combinations earlier. In complex special cases, technical review remains important; however, standard knowledge does not need to be manually rechecked with each request.
The CRM holds customer and sales context, including sales opportunities and quotations. A product configurator connects customer requirements with product rules and generates an admissible configuration. The ERP takes over downstream commercial and operational processes. It matters less which system “leads” than that relevant information can be passed in a structured way between these process steps.
