Automating Spare-Part Quotes in Mechanical Engineering

A spare-part enquiry looks like a minor matter and still regularly ties up half a day. Five stations sit between enquiry and quote: capture the enquiry, identify the machine and its build state, find the part in the ERP, determine price and delivery date, generate the quote. Most of that can be automated, but only if the chain is covered end to end.

We know this pattern from conversations with machine builders rather than from a statistic: the spare-parts business carries good margins and is handled on the side by exactly the people whose time is scarcest. This article describes where the time actually goes, what can be automated, and what makes it fail in practice.

Why does a spare-part quote take so long?

Not because the quote is hard to write. Because four steps come before it, and each one needs a person who knows the machines.

The striking row is the only one answering “partly”. It is the bottleneck, and it sits in second place. Everything after it is comparatively mechanical.

Where is the time really lost?

In identification, and in the waiting time around it. The customer gets in touch with what they can see: a machine number from the nameplate, or in the worse case a description such as “the part at the back left that squeaks”. Someone has to derive from that which assembly is meant and which variant of it sits in this particular machine.

This is the actual after-sales problem, and it is a documentation problem rather than a search problem. Many companies know the as-delivered state of a machine well. They often do not know today's state. Between delivery and enquiry lie retrofits, replaced components and several service technicians who did not consistently report back. Anyone with ten-year-old machines in the field has this problem.

The second time sink is less conspicuous: the callback. Once an enquiry goes back to the customer, it costs not minutes but one or more days. Every avoided callback is worth more than any accelerated internal search.

Why automating half the chain saves nothing

This is the central observation, and it runs against the usual approach.

In our overview of use cases in mechanical engineering, quotation costing and service enquiries appear as two separate use cases. For prioritisation that is correct. In everyday after-sales work they are not two projects but one chain, and chains behave differently from individual measures.

A system that reliably finds the right part but does not produce a quote saves the shortest step and still makes the clerk open the case. Conversely, an automated quoting path without identification produces clean quotes for possibly wrong parts. In both cases the matter lands back on the same desk, only later.

The time saving appears only once a case runs through without an intermediate stop. The right question for this use case is therefore not which step to automate first, but which subset of enquiries can be carried through completely. That is a different scoping decision, and it leads to a different pilot.

What can be automated, and what cannot?

Well suited to automation:

• Recurring wear parts and standard parts where the mapping is unambiguous.
• Enquiries with a known machine number and documented configuration.
• Rule-based pricing, meaning list price plus customer tier plus known special conditions.
• Availability and delivery statements derived from stock and replenishment time.
• The quote document itself.

Not automatable, and worth knowing in advance:

• The undocumented special case. Where the information does not exist, no system can find it.
• Pricing decisions that are negotiations. A long-standing customer with special terms, or a deliberately low price for a machine near its warranty, is a decision rather than a rule.
• The technical judgement of whether the requested part is the right one. When a customer describes a symptom instead of a part, that is service consulting.

A realistic goal is therefore not the fully automated spare-parts path, but a system that carries the clear cases all the way through and hands the unclear ones to a person together with the context already gathered. That handover is part of the solution, not its failure.

What does it require?

Four things, in this order of importance:

1. The link between machine number and installed configuration. This is the core. If it does not exist, the first project is not automation but establishing that link for the relevant machine families.
2. A maintained spare-parts catalogue. Article numbers, descriptions, successor parts. Successor parts especially, because discontinued articles are the norm in after-sales rather than the exception.
3. Read access to the ERP for articles, stock, replenishment time and prices. Read access is enough to begin with, which lowers the hurdle in IT considerably.
4. Pricing logic that can be written down as a rule. If writing it down reveals that there is no rule but experience, that is an important finding in itself.

Note what stands out: three of the four points are master-data topics, not AI topics. That matches what we set out in what an AI project costs. The effort rarely sits in the model.

When it is not worth it

• When the as-delivered and retrofit state cannot be reconstructed and there is no willingness to establish it for at least one machine family.
• With consistently genuine one-offs and no common parts. But as soon as standard parts, wear parts and bought-in components account for a noticeable share of enquiries, the use case applies to custom machinery too.
• When enquiries arrive almost exclusively by phone and are recorded nowhere. The first step is then an intake channel, not automation.

What a pilot looks like

The scope follows from the chain logic above: not one step across all enquiries, but all steps across a defined subset.

1. Select one machine family whose configuration data is most likely to exist. Usually the newest series with the largest installed base.
2. Review the enquiries of recent months and count what share falls to that family and to recurring parts. This number decides the project, and it takes one to two days to establish.
3. Build the chain for exactly that subset, from enquiry through to a quote ready to send.
4. Define in advance what success means. A sensible measure is the share of enquiries that reach a draft quote without a human intermediate stop. Not processing time, which fluctuates too much with enquiry quality.

Boundary: quoting chain or document search?

Both occur in after-sales, but they are two different tasks.

Anyone wanting to search existing machine files, drawings and documents and get a referenced answer is looking for a tool. That is KoAssist, which answers from your own documents and supplies file and page along with the answer.

The quoting chain is something else: it connects ERP, pricing logic and document generation into one continuous process. That is a development project and the work we take on in AI process automation.

The honest first step

The effort in this use case hangs almost entirely on one question that can be answered without a project: how well do you know today's state of your machines in the field?

If you can answer “well” for one series, the use case is realistic for you. If not, the first measure is master-data work, and nobody should sell that as an AI project.

We look at that question in a free initial consultation: one machine family, one look at the data, one dependable answer on whether the chain can be closed. Including when the answer is “not yet”.