Tomorrow’s machine quotations start with yesterday’s projects.

A memory built from every completed project.

Every delivered machine leaves behind useful information: the components actually purchased, negotiated prices, design and programming hours, assembly difficulties, modifications and commissioning time.

Tomorrow’s quotation system could connect those actual results to the original estimates.

It could help explain why a work package exceeded its budget, which parts of a solution were reused and which requirements created additional work.

The aim would be to retrieve a previous project with its context. A similar cell can provide a useful reference, but its cost only makes sense when its scope, performance and delivery conditions are understood.

That experience would remain accessible when the next enquiry arrives, even if the person who delivered the earlier project is unavailable.

Price knowledge grounded in actual purchases.

A manually maintained price database falls out of date as purchasing conditions change.

A system connected to supplier quotations, purchase orders and invoices could update its references from recent transactions. For a component, it could retrieve the latest price paid, the supplier, date, quantity and associated terms.

It would distinguish a list price from a negotiated price, an estimate from a confirmed order, and an exceptional purchase from a reference suitable for reuse.

An unusual price increase, a superseded part number or an outdated price would trigger a targeted check.

The engineer would have a documented estimate, with the items needing a fresh supplier quotation clearly identified. Less time would go into searching for prices, and more into assessing their relevance to the project.

An RFQ becomes a working project brief.

When the customer’s request for quotation (RFQ) arrives, the system could prepare a structured first reading:

• Required functions and performance.
• Product variants and operating conditions.
• Mandatory standards and preferred components.
• Supply boundaries and interfaces.
• Acceptance criteria.
• Missing or contradictory information.

Each item would remain linked to its source in the customer’s documents.

The system could then search the company’s history for relevant completed projects, suggesting connections, previously used architectures and points of comparison.

The engineer might receive a specific question:

The engineer’s input would address a decision that directly affects the concept and its cost.

The engineer steps in where judgment matters.

This is where an engineer-in-the-loop approach becomes meaningful.

The system prepares, searches, connects information and calculates. The engineer brings judgment when several solutions are possible, when information is missing or when a commitment needs approval.

That includes:

• Confirming the interpretation of the customer’s requirements.
• Selecting or adapting the concept.
• Resolving technical assumptions and assessing risks.
• Approving the proposed scope and performance.

For each decision, the engineer would have the relevant requirements, historical references, assumptions and possible effects on cost or schedule.

Routine tasks could progress within approved rules. New or uncertain issues would be brought to the right person.

Those decisions would enrich the project record: the system would retain what was chosen, why and under which conditions.

From the approved concept to the customer proposal.

Once the technical choices are approved, the system could build the estimate by connecting equipment, services, hours and assumptions.

Calculations would follow explicit, verifiable rules. AI would help interpret documents and project history, suggest cost items and flag possible omissions.

The technical and commercial proposal could then be prepared from the same project record: solution description, supply boundaries, options, exclusions, prices and approved terms.

Formatting would follow the company’s template. Internal costs would remain separate from the information shared with the customer.

When a requirement changes, the system could identify the affected elements and prepare a consistent revision of both the estimate and the proposal.

A concrete opportunity for software developers.

Such a tool could begin by connecting to the files and software already in use: Excel, purchasing systems, time tracking, project folders and Word templates.

Its value would come from the connections between that information.

For an automation company, the intended benefit would be to reuse its experience more easily, work from more reliable information and focus its expertise on the decisions that determine a project’s success.

This is a concrete prospect for industrial AI: a company preparing each new quotation with more knowledge drawn from the machines it has already delivered.