Engineering Helpdesk AI: Trained on Your CAD/PLM Tickets

Engineering Helpdesk AI: The Short Version

Engineering helpdesk AI is an assistant that retrieves resolved NX, Teamcenter and NXOpen tickets, proposes a sourced first-line answer per new ticket and drafts the reply for the CAD administrator. It is retrieval over pseudonymised ticket history, not a fine-tuned model. inteliScience, Siemens NX and Teamcenter specialists delivering nearshore from Romania, builds it on-premise or in an EU cloud.

The Problem: The Same NX and Teamcenter Errors Get Solved Every Quarter

Can an AI be trained on our ticket system to handle NX and Teamcenter errors? That question, in substance, came from an NX customer’s users, collected by a DACH machine builder’s CAD administration. It is the most practical question on their list, because the knowledge they want already exists. It sits in closed tickets nobody reads.

A CAD/PLM helpdesk queue has a shape. A workstation is reimaged and NX cannot find its licence server. A Teamcenter login fails after a password change. An NXOpen tool that ran for years stops after the upgrade to Designcenter NX 2606, released June 2026 [6]. Each was solved before, by the same two administrators, and the resolution went into a ticket that was closed, archived and never opened again. Next quarter the ticket returns with a different requester.

Ticket deflection is the least glamorous and most measurable use of an engineering knowledge assistant, and it is where we would start. If the queue is 40 percent repeats, an assistant that answers repeats from history returns those hours to the administrators who also carry your Teamcenter support and managed services rotation. What follows is how to build it without the two mistakes we see most often: fine-tuning a model on raw tickets, and indexing tickets with the names still in them.

What a Ticket Contains, and What Is Usually Missing

A closed ticket is a symptom, an environment and a resolution, written under time pressure by two different people. Retrieval works on the symptom; the answer comes from the resolution; the environment decides whether the answer still applies. Before anyone builds anything, export 200 closed tickets and audit them against this table.

Field	Usually present	Usually missing	Why it matters for retrieval
Symptom (subject, description, pasted error text)	Yes, in the requester’s words	The exact dialog text; often a screenshot instead of text	A new ticket is another requester’s words for the same symptom; this is what gets matched
Environment (NX or Teamcenter version, OS, role, site, licence type)	Partly, buried in free text	Version as a structured field	An answer valid for NX 2312 may not hold for Designcenter NX 2606
Root cause	Rarely written down	The one line that turns a fix into knowledge	Without it, two tickets with the same fix look unrelated
Resolution	In closed tickets, if the admin wrote it	“Solved by phone”, “fixed”, “see mail”	The assistant can only propose what was recorded
Link to KB article or known-error record	Rarely	The pointer that makes the answer maintainable	Lets the assistant cite the article rather than a ticket
Personal data	Always: requester name, email, hostname, username, sometimes a screenshot with a name on it	Nothing missing here, which is the problem	Must be removed or pseudonymised before indexing

Two findings from this audit decide the project. If fewer than half of the closed tickets carry a usable resolution, the first deliverable is a closing template with a mandatory resolution field, not an assistant. If screenshots carry most of the error text, the pipeline needs OCR on attachments first. Both are cheaper to learn now than in week five of a pilot.

“Trained on Tickets” Means Retrieval, Not Fine-Tuning

Users say “train the AI on our tickets”. What they need is an assistant that, given a new ticket, finds the resolved tickets that describe the same symptom and builds its answer from them, with the source ticket cited. That is retrieval-augmented generation (RAG), and we would advise against fine-tuning a model on ticket text for this job.

Fine-tuning changes how a model writes; it does not give it a reliable memory of which ticket said what, and it cannot cite a ticket ID. Retrieval keeps the knowledge outside the model, in an index you can inspect, correct and delete from. AWS’s own explainer puts it the same way: RAG “extends the already powerful capabilities of LLMs to specific domains or an organization’s internal knowledge base, all without the need to retrain the model”, and “the output can include citations or references to sources” [1]. The widely cited survey by Gao et al. lists exactly the failure modes ticket data triggers, hallucination, outdated knowledge and untraceable reasoning, and describes RAG as the approach that allows “continuous knowledge updates and integration of domain-specific information” [2]. Tickets are updated daily. A fine-tuned model is a snapshot.

There is a second reason, and it is about data protection. A model fine-tuned on raw tickets has absorbed names, and there is no delete operation for a name inside model weights. An index has one.

The model itself is the least interesting decision. Current Claude models such as claude-opus-5-5, released on 22 September 2026 [3], or an open-weight model on your own GPUs will both write a good first-line reply from three well-chosen tickets. What separates a useful assistant from a demo is the retrieval layer and the evaluation around it, which is why our framework for evaluating engineering AI assistants spends more pages on grounding layers than on models.

The Pipeline: From Ticket Export to a Connected Assistant

Building the corpus is seven steps, and steps two to four take most of the time. Every step runs where the ticket data lives.

Export. Pull closed tickets with resolution, status history and attachments from the ticket tool (Jira Service Management, ServiceNow, OTRS or a vendor portal export), including the product and version fields even where they are empty.
Clean. Drop tickets without a resolution, strip signatures, quoted email threads and auto-replies, and pull error text out of screenshots with OCR.
Pseudonymise. Replace names, email addresses, usernames and hostnames with placeholders before the text leaves the ticket database; keep the mapping in the ticket system, not in the index.
Chunk by ticket. One ticket is one retrieval unit, symptom and resolution kept together. Fixed-size chunks separate the question from its answer, the one thing that must not happen.
Link resolutions. Group tickets that ended in the same fix, attach the KB article or known-error record where one exists, and mark a canonical ticket per group.
Index. Embed the symptom text, store product, version, date and resolution group as metadata, and filter on them at query time so an NX 2312 answer is not offered for a 2606 environment.
Connect to the ticket tool. A webhook on ticket creation sends the new ticket to the assistant, which writes its proposal back as an internal comment. No auto-reply to the requester.

Steps two and three can start as a script. This one reads a ticket CSV, removes email addresses and login IDs with regular expressions, keeps only closed tickets with a written resolution and groups them by resolution. Standard library only; adapt the login pattern to your naming convention.

import csv
import re
from collections import defaultdict

EMAIL = re.compile(r"[\w.+-]+@[\w-]+\.[\w.-]+")
LOGIN = re.compile(r"\b[a-z]{2}\d{4,6}\b")  # adapt to your login pattern, e.g. ab12345

def clean(text):
    text = EMAIL.sub("<email>", text or "")
    text = LOGIN.sub("<user>", text)
    return re.sub(r"\s+", " ", text).strip()

resolved = []
with open("tickets_export.csv", newline="", encoding="utf-8") as f:
    for row in csv.DictReader(f):
        if row["status"] != "closed" or not row["resolution"].strip():
            continue  # open tickets and closed-without-resolution teach nothing
        resolved.append({
            "id": row["id"],
            "product": row["product"],   # NX, Teamcenter, NXOpen tool, licence, install
            "version": row["version"],
            "symptom": clean(row["subject"] + " " + row["description"]),
            "resolution": clean(row["resolution"]),
        })

# Group tickets that ended in the same resolution: one knowledge unit, many symptoms
by_resolution = defaultdict(list)
for t in resolved:
    by_resolution[t["resolution"].lower()].append(t)

with open("knowledge_units.csv", "w", newline="", encoding="utf-8") as f:
    w = csv.writer(f)
    w.writerow(["resolution", "tickets", "ticket_ids", "products", "versions", "sample_symptoms"])
    for res, group in sorted(by_resolution.items(), key=lambda kv: -len(kv[1])):
        w.writerow([
            res,
            len(group),
            ";".join(t["id"] for t in group),
            ";".join(sorted({t["product"] for t in group})),
            ";".join(sorted({t["version"] for t in group})),
            " | ".join(t["symptom"][:160] for t in group[:3]),
        ])

The exact-match grouping is deliberately crude; in the real pipeline near-duplicate resolutions are merged with embeddings and a human confirms the merge. Even so, the output sorted by ticket count is the most useful document a CAD administration produces all year: the fixes that recur, with evidence attached. In the private AI knowledge assistant project in our case study, this corpus audit shaped the architecture more than the model choice did.

What the Assistant Does on a New Ticket

On every new ticket the assistant does four things and stops before the fifth: it retrieves similar resolved tickets, proposes a first-line answer with sources, drafts the reply in the administrator’s voice, and flags the ticket as unknown when nothing in the history matches. It never sends. AI proposes, a human validates.

Here is the shape of it, written generically. Ticket IDs are illustrative; the error text is the message NX shows when the licensing client cannot reach its server, as documented in Siemens Community threads [4] (older releases name the variable UGS_LICENSE_SERVER).

NEW TICKET  T-2318  (requester: <user>, site: Plant 2)
"NX won't start on my new workstation. Dialog says: License Error:
Cannot connect to license server system. The server (lmgrd) has not
been started yet, or SPLM_LICENSE_SERVER is set to the wrong port@host."

SIMILAR RESOLVED TICKETS (3 of 3 above threshold)
  T-1907  reimaged workstation, SPLM_LICENSE_SERVER still pointed at the
          old server name                       -> resolved, KB-041 linked
  T-2044  licence service stopped after server patching, restarted
          Siemens PLM License Server service     -> resolved
  T-1622  VPN profile blocked the licence port   -> resolved, KB-058 linked

PROPOSED FIRST-LINE ANSWER  (sources: T-1907, KB-041)
  New workstation + this exact message = most often the environment
  variable. Check SPLM_LICENSE_SERVER on the client, expected format
  port@host, against the current licence server name in KB-041.
  If the value is right, check the licence service (T-2044) and the
  VPN profile (T-1622).

DRAFT REPLY FOR ADMIN  (edit, then send)
  Hi, this message usually means the workstation is looking for the
  licence server under an old name. Could you open System Properties >
  Environment Variables and send me the value of SPLM_LICENSE_SERVER?
  It should read port@host with our current server (see KB-041) ...

UNKNOWN-ERROR FLAG: no

Three details matter. The causes are ranked by how often they resolved this symptom in this company’s history, not by what a public forum says. Every line points at a ticket or KB article the administrator can open in one click. And the draft asks for the one piece of information that decides between the three causes instead of listing all three.

When retrieval finds nothing above threshold, the assistant says so and sets the flag. That flag is the second product of the system: the list of errors your history has never solved, which is the input for the known-error list. Let the assistant answer anyway and it produces a confident guess from a public forum. In practice this rarely ends well.

This runs as a POC. What’s missing for production: pseudonymisation that survives an audit, SSO and permission mirroring, the ticket-tool integration, a feedback loop that reindexes daily, monitoring and operations. We close the gap from “runs on my machine” to “runs in the enterprise”, with a read-only, citation-first chatbot on your infrastructure. Start with the NX Knowledge Chatbot pilot.

Metrics and Pilot Design

An engineering helpdesk AI is measured with the numbers the helpdesk already has, plus two the assistant adds. Every metric needs a baseline from the quarter before the pilot, or the pilot proves nothing. We quote no benchmark numbers because none exist for your queue; the table is what to measure and how.

Metric	Definition	Baseline source	What the pilot compares
Time to first answer	Time from ticket creation to the first substantive reply	Ticket tool timestamps, last quarter	Median for tickets with a proposal vs without
First-contact resolution	Share of tickets closed after the first reply, no follow-up needed	Status history	Same, for tickets where the admin used the draft
Deflection	Share of would-be tickets answered by the self-service chatbot before a ticket is opened	Not measurable before the pilot; count chatbot sessions that end without a ticket	Sessions without a ticket vs total sessions
Escalation rate	Share of tickets passed from first line to the NX or Teamcenter specialist	Assignment history	Before vs during the pilot
Draft acceptance	Share of drafted replies sent unchanged or lightly edited	New; logged by the assistant	Trend over the pilot weeks
Grounded-answer rate	Share of proposals whose cited tickets actually contain the resolution given	New; sampled and scored by an administrator weekly	Target agreed before the pilot
Unknown-error rate	Share of tickets flagged as not in history	New; logged by the assistant	Should fall as the known-error list grows

Pilot design in one paragraph: one queue (NX and Teamcenter first line), the closed tickets of the last two to three years, one administrator who scores twenty proposals a week against the ticket’s real outcome, four to six weeks, and a go or no-go decision on draft acceptance and grounded-answer rate rather than on how the demo felt. Our clear recommendation: score the grounded-answer rate on tickets the assistant has never seen, including a few with deliberately garbled error text, because “knows when it does not know” decides whether administrators still use it in week three.

Tickets are personal data. Every ticket names a requester and an administrator, most contain an email address, many a hostname that identifies a desk, some a screenshot with a colleague’s name in the title bar. The corpus is a GDPR processing activity before the first embedding is computed, and three articles shape the design.

Article 4(5) defines pseudonymisation as processing personal data so that it “can no longer be attributed to a specific data subject without the use of additional information” kept separately [5]. That is the split in step three: placeholders in the index, the mapping in the ticket system under existing access control. Article 5(1)(c), data minimisation, is why the index holds symptom, environment and resolution and nothing else. Article 28 applies the moment a provider hosts any part of the system: a processing agreement naming what is stored, where, for how long and who may read the logs.

On hosting, our position is the same as for every engineering assistant we build: on-premise or in an EU cloud under your control, with permissions mirrored from the ticket tool. A hosted frontier model reached through a hyperscaler’s EU region is acceptable for many DACH manufacturers; an open-weight model on your own GPUs is the answer where tickets touch export-controlled programs. The reference architecture is in our piece on sovereign agentic AI for European manufacturing, and the operating model that keeps such a platform alive after the pilot is the subject of our enterprise GenAI platform case study.

The audit trail turns a chatbot into a helpdesk tool. Every proposal stores which tickets and KB articles it was built from, which model version wrote the draft and whether the administrator accepted, edited or discarded it. The self-service layer discloses that it is an AI system, as the EU AI Act’s Article 50 transparency duties have required since 2 August 2026. And when a ticket is deleted under a retention rule or an erasure request, the index entry goes in the same job. Retrieval makes that one line. Fine-tuning would have made it impossible.

Frequently Asked Questions

Can an AI really be trained on our ticket system to handle NX and Teamcenter errors?

Yes, if “trained” means indexed for retrieval. The assistant retrieves closed tickets whose symptom matches a new ticket, proposes an answer built from their resolutions and cites them. Recurring errors get handled; new errors are flagged, not guessed. The ceiling is set by how many closed tickets carry a written resolution.

RAG vs fine-tuning: which is right for ticket data?

RAG, for three reasons: tickets change daily and an index updates in minutes while a fine-tuned model is a snapshot; RAG can cite the ticket it used and fine-tuning cannot; and personal data in an index can be deleted, while a name absorbed into model weights cannot. Fine-tuning has a role only for tone, never for knowledge.

What data does an engineering helpdesk AI need from our tickets?

Symptom, environment and resolution per ticket, with personal data replaced by placeholders; product and version as metadata; a link to a KB article or known-error record where one exists. Attachments matter when error text lives in screenshots, which in CAD helpdesks is often. Open tickets and tickets closed without a resolution are left out.

How much does an engineering helpdesk AI cost to set up?

The fixed-price pilot on our NX Knowledge Chatbot page is the reference point: core corpus indexed, citation-first chatbot live for a pilot group on your infrastructure, an answer-quality report on real questions, four to six weeks, creditable against rollout. The larger, less visible cost is on your side: cleaning the ticket export, agreeing pseudonymisation rules with the data protection officer and connecting the ticket tool. Budget those days before the licence.

Will the assistant answer requesters directly and close tickets?

Not in our design. It answers in the self-service chatbot before a ticket exists; on an open ticket it writes an internal proposal and a draft reply that the administrator sends or discards. Auto-closing tickets on an AI answer removes the human check that keeps the grounded-answer rate honest.

Next Step

Talk to our engineers about an assistant on your ticket history

References

Amazon Web Services, “What is RAG (Retrieval-Augmented Generation)?”, https://aws.amazon.com/what-is/retrieval-augmented-generation/, retrieved 24 September 2026.
Yunfan Gao et al., “Retrieval-Augmented Generation for Large Language Models: A Survey,” arXiv:2312.10997, v5, 27 March 2024, https://arxiv.org/abs/2312.10997, retrieved 24 September 2026.
Anthropic, “Introducing Claude Opus 5.5,” 22 September 2026, https://www.anthropic.com/news/claude-opus-5-5, retrieved 24 September 2026.
Siemens Digital Industries Software Community, “NX License Error: Cannot connect to license server system. The server (lmgrd) has not been started yet, or UGS_LICENSE_SERVER is set to the wrong port@host,” https://community.sw.siemens.com/s/question/0D54O000061wpw6SAA/nx-license-error-cannot-connect-to-license-server-system-the-serverimgrd-has-not-been-started-yet-or-ugslicenseserver-is-set-to-the-wrong-port-host-15, retrieved 24 September 2026.
European Union, “Regulation (EU) 2016/679 (General Data Protection Regulation),” Articles 4(5), 5(1)(c) and 28, https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng, retrieved 24 September 2026.
Siemens, “Designcenter is for everyone: June 2026 release,” Designcenter blog, 23 June 2026, https://blogs.sw.siemens.com/designcenter/designcenter-is-for-everyone-june-2026-release/, retrieved 24 September 2026.