How Manufacturers Should Prioritize AI Use Cases

RFQ triage, service knowledge search and project research can all sound like sensible first AI projects. The difficult part is choosing which one deserves scarce engineering time. A list of ideas will not settle that. A comparison of actual work might.

Start with the decision that is slow or unreliable today. For an equipment manufacturer, that could be deciding whether an enquiry contains enough information for technical review. The useful first project may be extracting missing requirements, even if the original request from leadership was to automate quotations.

Name the work before scoring it

Write one sentence for each candidate: when a particular event happens, a particular role needs to make a decision using identifiable evidence. “AI for sales” is too broad. “Help application engineering identify missing requirements in incoming RFQs” is specific enough to investigate.

Collect a bounded sample of recent work: the request, its attachments, clarification messages, timestamps and eventual disposition. Use only records the team is authorised to review. Establish where effort is spent before deciding which portion should use AI.

If sales already collects the technical details quickly but requests wait for an owner, a routing rule may be the better investment. Discovering that is a useful result, even though it produces no AI pilot.

A score needs an explanation

For an initial discussion, use the eight-column shortlist. It asks for the decision, evidence, reviewer and smallest test without requiring a full scoring exercise. Move viable candidates into the detailed worksheet only after those basics are clear.

The downloadable worksheet uses five dimensions. Higher scores mean a stronger case on value, evidence, feasibility and adoption. The risk column is deliberately different: higher means greater residual risk. Never add these columns into an unexplained total.

These are decision aids, not validated predictors of ROI. Missing permission, unacceptable safety exposure or no competent reviewer should stop a candidate regardless of its value score. A weighted average must not make those conditions disappear.

Read the example rows as a decision, not a leaderboard

The CSV contains illustrative candidates, not customer results. Its RFQ extraction example has scores of 4 for value, evidence, feasibility and adoption, with residual risk at 2. The project-signal example has value at 4, the other positive dimensions at 3 and residual risk at 3.

Under those assumptions, RFQ extraction is the better first test: the evidence and operating fit are stronger. That conclusion would change if the RFQ records were unavailable or the engineering lead could not review outputs. Project research could then be the more practical starting point, provided a regional business-development owner could assess the sources.

The numbers make the disagreement visible. They do not resolve it. Replace every example baseline before using the sheet to request budget.

What the first RFQ test should actually do

Before choosing that test, estimate the operating burden. In this deliberately simplified planning example, there are 80 requests a month. Manual preparation takes 35 minutes; assisted preparation, including review, is assumed to take 20. That releases 20 hours a month: 80 × 15 / 60. It is capacity, not a payroll saving.

At an assumed internal capacity value of EUR 50 an hour, the RFQ example represents EUR 1,000 a month before running cost and setup. If review takes 30 minutes instead of 20, released capacity falls to roughly 6.7 hours, worth about EUR 333 on the same assumption. That change matters more than moving a score from 3 to 4. Replace these figures with observed work and supplier estimates; do not treat them as a ShiftNode price list.

Use past requests to extract stated requirements, flag missing fields and propose an owner. Preserve a reference to the email or attachment behind each extracted fact. Ask experienced reviewers to compare the draft with the original request.

Track invented requirements, missed omissions, incorrect routes and review time. Keep pricing, final product selection and automatic sending outside this test. Stop if the assistant fills a missing requirement with an unsupported guess. The RFQ intake guide explains how to separate initial qualification from quote readiness.

At the review meeting, choose whether to expand, revise or stop. Expansion needs evidence that the output helps the people doing the work and that the next integration is worth its maintenance cost. A convincing demonstration alone is not enough.