What happened at Nakkila Works

A request for a quote on an industrial product rarely arrives as one tidy email. It may contain specifications, drawings, bills of materials and clarifications in several versions. Before an engineer can estimate the work, someone has to locate the relevant files, extract the requirements and connect them to a sales opportunity. Missing a single dimension or delivery condition can turn a quick response into an expensive mistake.

A file called “final_version_2” may sound like a joke, but a system must not guess the correct drawing revision from its filename.

This document-heavy step was the focus of a pilot by Finland's Nakkila Works, a manufacturer of tanks and process equipment, with the Robocoast digital innovation hub. According to the case published by the European Digital Innovation Hubs Network, the company handled about 200 complex request-for-quotation (RFQ) packages a year. The team first mapped the actual document flow, then worked with solution providers to test automated intake, extraction, classification and structuring within the existing sales process.

The case authors report that analysis time for some packages fell by up to 90% compared with the manual process and that manual handling errors declined. This is a reported pilot outcome, not a promise of comparable savings for every workshop. The publication does not provide an open measurement protocol, a breakdown by RFQ complexity or implementation cost. A buyer should therefore not base a budget on that percentage without a local baseline and controlled test.

Where AI helps, and where rules are enough

The valuable task is not to let a model write the engineer's quotation. Software can quickly prepare a draft inventory of the incoming package: which files arrived, which version applies, and where dimensions, materials, deadlines and exclusions appear. It can then suggest a structured record for a specialist to check. The engineer remains responsible for technical interpretation, calculations, assumptions and the final price.

The robot intern can sort the paperwork; signing the estimate is still above its pay grade.

For a small manufacturer, a sensible workflow has four layers:

  • The intake layer preserves the original email and attachments, assigns an RFQ identifier, and records sender, time and version. This is ordinary automation; it does not require a model.
  • A parser extracts text from PDFs and spreadsheets, adding OCR for scans. Tables and drawings need separate checks: a dimension visible in an image does not automatically become a reliable data field.
  • A classifier labels document types while a model helps locate and suggest values for a predefined schema: product, material, unit, quantity, deadline and special conditions. Every suggested value should retain a pointer to its source page or cell.
  • A review screen places the source fragment next to the proposed field. Only confirmed values move to the CRM, ERP or estimating spreadsheet. Ambiguous and contradictory values go to a human reviewer.

This is our proposed design for a similar pilot, not a disclosed diagram of the Nakkila Works system. The original case does not identify specific models, an OCR engine or where inference ran. The distinction matters: otherwise a reported result could be falsely attributed to a technology stack that the project may never have used.

What data is needed before buying a model

Start with 30–50 completed RFQs of different kinds, provided contracts permit their use in a test environment. Keep the original emails, every attachment version, approved estimates and notes showing what an expert actually verified. Decide on customer-data masking and access boundaries before uploading anything to a service. A local installation still needs storage policies, backups and access logs.

On part of the sample, an expert creates a reference set: the document inventory, required fields, units, inconsistencies and page references. This annotation takes more effort than a polished demo, but it makes missed requirements measurable. Testing only ten clean PDFs is misleading if real requests arrive as scans, archives and multi-sheet spreadsheets.

The most dangerous errors involve number–unit pairs, drawing revisions and negations such as “coating not required.” For critical fields, set a rule: no confident source-backed evidence means no automatic entry into the estimate. Microsoft's document extraction guidance recommends using confidence estimates to route uncertain results to human review and evaluating quality on one's own data; a confidence score by itself is not validation.

A pilot without a long project

Choose one RFQ type and one intake channel. During the first week, measure manual time spent not just reading but finding revisions, copying fields, seeking clarification and checking again. For the next two weeks, let the system draft records alongside normal work, without automatically writing to the production accounting or sales system.

Compare each draft with the human reference:

  • time from package receipt to a verified record;
  • proportion of required fields found correctly, with dangerous omissions counted separately;
  • human correction time;
  • proportion of requests routed to manual review;
  • cost per accepted record, including infrastructure and review.

Set the acceptance threshold in advance. Saving time while finding no missing critical requirements in the test sample may be more useful than an impressive automation percentage. That threshold is a management decision for the individual business, not an outcome reported in the Finnish case.

Economics and limits of transfer

At 200 RFQs a year, even a sizeable saving per package may fail to pay for an expensive integration. Here is an illustrative calculation, not a Nakkila Works result: at 60 minutes of manual preparation per RFQ, the annual workload is 200 hours. A 40% net saving after human review frees 80 hours. At an assumed fully loaded specialist cost of RUB 1,500 per hour, that represents RUB 120,000 of potentially reallocated time a year—not cash revenue. Implementation, maintenance, annotation, storage and error correction must still be deducted. Change any assumption and the decision changes.

A local model is relevant when quotations and drawings cannot leave the company perimeter, or when volume and stability justify owned infrastructure. Yet “local” does not mean “free”: hardware, updates, monitoring, access control and quality ownership all have costs. If volume is low, start with rules, OCR and human confirmation; add a model only where it removes a measured bottleneck. RAG can help compare an RFQ with approved catalogues, standard components and internal estimating rules, with source and version references. It should not be a generic chat layer, and an agent should not be allowed to send a price to a customer autonomously.

An OECD study from 2026, based on a non-representative sample of more than 2,000 SMEs, identifies time constraints, maintenance costs and skills gaps as barriers to effective AI adoption. It is neither a measurement of Nakkila Works nor a statistic for the Russian market, but it is a useful reminder that process maintenance belongs in the business case alongside model costs.

Nakkila Works handled complex packages and had an EDIH-supported pilot. A small Russian manufacturer cannot automatically transfer either the reported effect or the funding arrangement. The transferable principle is to map the process and build a reference set first, then extract source-linked data, and only then integrate it. If a draft record does not reduce expert time without introducing dangerous errors, improve documents and rules before searching for a larger model.