AI Document Assistant for Service Documentation

A document assistant answers questions from a set of documents you upload, such as manuals and instructions for use, instead of from the open internet. The person asking can open the source document behind the answer. At a device, that difference decides whether someone follows the procedure written for that model or a plausible paragraph a general chatbot assembled.

A technician is standing in front of a device. Something is wrong. The manual runs to hundreds of pages, and the relevant procedure is somewhere in the middle.

They can call the service desk. They can guess. Or they can ask a question and get the answer from the manual that belongs to that device.

The third option is what a document assistant does. How it differs from the general assistants everyone now has on their phone is worth spelling out, because nearly everything useful about it comes from that difference.

What a document assistant is

A document assistant answers from a defined, controlled set of documents. Your manuals, your instructions for use, your service procedures.

It is set up to answer from those documents rather than from the internet. How closely it sticks to them, and what it does when they do not cover a question, is something to test before you rely on it.

In sqanit each assistant carries its own prompt, and that is where the behaviour is decided. The prompt it starts with tells the assistant to answer from the uploaded documents and not to make something up when they do not cover a question, and to ask back when a request is ambiguous. You can replace it per assistant, which is how a troubleshooting assistant ends up giving step by step instructions while one answering warranty questions stays short.

That constraint is what makes it useful. In a regulated service context, an answer that sounds right and cannot be traced to a document is worse than no answer at all.

Why a generic AI assistant fails at the device

Ask a general chatbot how to clear an error code on a specific medical device and you will usually get something. The problem is what that something is built from.

It does not know your documents. The procedure you revised last quarter exists in your files, not in a model's training data.

It also does not know which model is asking. Two product lines can share an error code and need different fixes. A general model averages across whatever it has seen.

And you cannot check it afterwards. When the technician has to justify what they did, "the chatbot told me" is not a record. With a document assistant, the source document is there to open and read.

How a document assistant works at the device

In sqanit, the document assistant is configured on the template, which is the digital description of a product model. Every device built from that template gets the same assistant, answering from the documents uploaded for that model.

So the person standing at the machine does not have to know which of the manuals in your portal is the right one. They open the device's page, choose the assistant, and ask. The template already defines which documents are in scope.

A few details matter in practice:

• Users can open the documents the assistant answers from, for example the user manual PDF, and read them directly.
• The assistant can respond in the user's language. That helps people use the documents, but it does not replace the language versions of instructions for use and safety information that the MDR requires.
• An assistant can be linked to an action button in the interactive manual, so a guided troubleshooting flow can hand over to a free question at the point where the flow runs out.
• Staff reach the same assistants in the back office, and customers with a login reach them too.

We wrote up how the device page itself works, and why it needs no app, in the piece on QR code digital twins for after-sales service.

Tutorial: setting up a document assistant, step by step

This is the short version for sqanit. The full reference, with screenshots, is in the sqanit documentation.

1. Check the API key first. The assistant runs on your company's own OpenAI API key. It has to be active and entered in your company settings before anything else works.
2. Open the template. In the back office, go to Templates and choose the product model you want the assistant for.
3. Switch the module on. Under Modules, select AI and enable the Document Assistant submodule.
4. Create the assistant. Click New Assistant, give it a title, and optionally an assistant name, a welcome message and an avatar.
5. Adjust the prompt, or leave it. Each assistant has its own. The default already keeps it inside the uploaded documents and stops it answering past them, so change it only when this assistant has a narrower job, such as troubleshooting rather than general lookup.
6. Add an element and upload documents. Click Add Element, enter a title and an optional description, and upload the documents, such as PDFs of the manual.
7. Save and test it. Ask it three questions your manual answers and one it does not. The last one tells you how it behaves at the edge of your documentation.

Configuration is the quick part. Most of the work goes into deciding which documents belong to which model, and keeping the uploaded version the current one.

What to check before you buy one

Whose model provider account does it run on? Some vendors bundle model usage into the licence. Others, sqanit among them, run on your own OpenAI API key. Both are legitimate, but the cost profile is different and it is easier to ask now than to find out in month three.

Can the user see the source? If nobody can open the document behind an answer, the answer cannot be checked, and it is not usable for regulated service work.

How does a document get updated? When you revise a procedure, how does the new version reach the assistant? If the answer involves a project, your documentation will drift.

What happens when it does not know? Test this deliberately with a question your documents do not cover.

Is it tied to the product model or to nothing? An assistant that sits on a website, detached from any model, leaves the user to pick the right manual first. That is the step you were trying to remove.

Does it work on a bad connection? Hospital basements and plant floors are where devices live. Test at one bar of signal.

Where the time goes, and where it does not

Reading the procedure was never the slow part. The time goes into the steps before it: working out which document applies, finding the current version, and locating the relevant section.

For a distributed service team those steps repeat many times a day and produce nothing. That is the work a document assistant removes. How much it is worth depends on how often your people go looking for a PDF today, which is a number worth measuring before you buy anything.

For context on what device-level service can do to the whole cost line, a US medtech distributor measured a 27% reduction in total service costs on sqanit.

Where it fits next to what you already run

A document assistant does not replace your service management system, your ticketing tool or your product information system. It answers questions. Cases, dispatch and parts still run where they run today.

The connection worth building is the one that turns an unanswered question into a ticket without retyping anything. How sqanit connects to CRM, helpdesk and ERP systems is covered in a separate piece on integrations.

Want to see a document assistant answering from your manuals, on one of your devices? Book a walkthrough.