AI for Technical Support: Finding Procedures Without Inventing Instructions

An assistant that always answers, in a workshop or on a job site, is a problem, not a convenience. What a technician needs isn't a well-written procedure: it's reaching the right page of the right manual, for that machine in that version, and being able to check it in ten seconds. This guide sets the boundaries for an assistant handling technical procedures: what it can retrieve, what it must refuse to do, and when it must call in a person.

Identification comes before the answer

The same question has different answers on different models, and sometimes on two units of the same model. Before searching, the assistant needs to know what it's actually dealing with.

• Product and model.
• Version, serial number, or year of installation.
• Configuration and the options actually installed.
• The context: installation, scheduled maintenance, or an ongoing fault.

If one of these elements is missing, the right move isn't to answer anyway by guessing the most likely model: it's to ask. One more question costs seconds; the procedure for the wrong model costs a service call, and sometimes much more.

Every answer must be traceable

The simplest test for telling a useful tool from a dangerous one is this: does the answer say where it comes from? If it doesn't, it isn't an answer — it's a well-phrased opinion.

• The document, with its revision or edition.
• The exact location: chapter, paragraph, page.
• The ability to open the original document at that exact point, with a tap.
• The date the source was last updated.

The summary is there to save time, not to replace the manual. If checking it means searching the document by hand, no one will do it: a direct link to the exact spot matters more than the quality of the summary.

A demonstration case

The example below is made up to show the expected behavior and does not describe a real installation.

1. The technician asks: "error E12, what do I do?"
2. The assistant doesn't answer and asks for the model and year, because in the available manuals the same code appears on two series with different meanings.
3. The technician provides the model and serial number.
4. The assistant returns the relevant passage from that series' manual, cites the document, revision, and paragraph, and shows a link to the original page.
5. The technician asks whether they can replace a component. The assistant reports what the manual prescribes and flags that, in that part of the installation, the operation is one that requires certification: the answer stops there and names who to contact.
6. The assistant logs the question, the source used, and the outcome, so that whoever maintains the documentation can see what's actually being asked and where the manuals fall short.

Informing is not authorizing

This is the distinction that needs to be put in writing before you switch anything on, because no one reconstructs it after the fact.

• Explaining what a code means, where a component is located, what a procedure calls for: that's information, and it's fine.
• Instructing someone to work on parts that require certification, qualification, or lockout procedures is not the assistant's job, whatever the manual says.
• Some information should only be given to those with the role to use it: the assistant's permissions follow those of the person asking, never the other way around.
• The same separation applies to actions: reading a piece of data from the business management system is one thing; opening a ticket or ordering a spare part is another, and needs explicit, role-based authorization.

When the assistant must stop

What's needed before switching anything on

• The list of documents that count as authoritative, with version and date.
• Superseded documents removed from the searchable archive, not left sitting alongside the current ones.
• Readable formats: a scan without text is just an image, and it can't be searched.
• A person who is accountable for that archive and has the time to manage it.
• A way to add a new document and withdraw an old one without having to call a vendor every time.

This is the least visible part of the project, and it's the one that decides the outcome: the quality of the answers never exceeds the quality of the archive.

How to tell whether it's working

• How many questions get an answer with a source, and how many end in a stop. A stop isn't a failure: it's the system behaving as intended.
• How often the technician opens the manual anyway after reading the answer.
• Which questions come up most often: they point to a gap in the documentation or missing training, and they're the most useful information the system produces.
• Reports of wrong answers, which should take just a tap: if flagging one is inconvenient, no one will do it.

The check should be carried out by an experienced technician on a sample of answers, at fixed intervals, even when no complaints come in. The absence of complaints only means that no one has run into the error yet.

What this guide doesn't cover

This guide covers documentary support: retrieving and citing what has already been approved. No critical instruction should be generated by an automated system without a qualified technician's review. Preparing documents before making them searchable has a guide of its own, and applications for field technicians — job reports, signatures, spare parts, timesheets — are another matter entirely.