RAG knowledge assistant for customer support teams

Ticket bodies, attachments and email signatures carry personal data that a support assistant does not need. A customer's name, phone number, account reference or address often sits in the first message, in quoted reply chains and in the signature block that the helpdesk appends to every agent reply. If the ingestion pipeline reads these fields as ordinary text, the personal data is split into chunks, converted into embeddings and displayed again in citations shown to other agents. The safer design decides at ingestion what leaves the source system: strip quoted history and signatures, pseudonymize identifiers the answer does not need, and exclude tickets or fields that are not required for the assistant's purpose. Each of these choices should be written down as a rule that the pipeline applies to every document, not a manual clean-up.

Indexing only resolved, public-facing content removes most of the exposure. Help center articles and product documentation are usually written for publication and carry little personal data. Past tickets are more useful for answering recurring questions but are far riskier, so the first release can index the help center and approved macros, and add resolved tickets only after a review of what the pipeline removes. The team should confirm what Zammad's Elasticsearch integration copies out: Zammad uses Elasticsearch for search and for searching the content of email attachments, so the reader must check whether attachment text, which may contain identity documents or statements, is also sent to any external process or to the RAG pipeline.

Erasure is the control most often left undefined, so confirm it before the first load. When a customer asks for deletion, the organization must be able to remove the source ticket, every chunk derived from it, every embedding and every cached answer or citation that quoted it. Confirm with the RAG platform vendor and the vector store how documents are deleted and whether a re-index removes orphaned vectors, and set a test that deletes a known ticket and verifies it no longer appears in retrieval. The legal analysis of lawful basis, minimization and erasure sits in the GDPR guidance for RAG assistants, which should be read alongside this design.

Deflection is not proven by a ticket that never gets created. A customer who reads an answer and goes away may be satisfied, or may have given up, or may open a ticket in a different channel the helpdesk does not count. Before any dashboard is built, agree on a written definition with support leadership that distinguishes a resolved contact from an abandoned one. The baseline for comparison must come from the client's own Zammad or other helpdesk history: ticket volumes by category, first-response times, reopen rates and escalation rates for the same categories over a period before launch. No external benchmark figure should be used to justify the project, because the mix of products, contact channels and ticket types differs from one organization to the next.

Track the signals that show whether an answer held up. Reopened tickets matter most: if a customer returns to the same issue within the agreed window, the assisted answer did not resolve it. Escalations to second-line or engineering show whether agents trusted the suggestion enough to act, or had to go beyond it. Agent edits to suggested answers, recorded at the point an agent changes or rejects a citation, reveal where retrieval found the wrong article or where the source document is out of date. CSAT should be measured on assisted tickets and compared with unassisted tickets in the same categories, since a low score on a cited answer often points to a stale help article rather than a poor model. Confirm which of these fields your helpdesk stores natively and which need a custom report before promising them to stakeholders.

Where volume allows, hold back a control group, for example by routing a fixed share of eligible chats or tickets to agents without the assistant for a defined period, and compare reopen, escalation and CSAT outcomes between the two groups. Agree the sample rules, the review window and the reporting owner before go-live, and record the decisions in the evaluation plan so the results cannot be reframed after the fact. Report deflection as a range with its definition, its window and its limits, and state which categories were excluded. Any claim made to a board or customer should be traceable to the helpdesk export that produced it.

Ask first how the partner removes personal data before anything reaches the index. A support corpus is full of names, email addresses, phone numbers, order details and sometimes card or account numbers pasted into ticket bodies. Ask which fields of the Zammad ticket, article and attachment model are excluded at ingestion, whether redaction runs before chunking or only at display time, and how the partner proves that a sample of indexed chunks contains no personal data. Ask also what happens to attachments and email signatures, which are the most common leak paths. A credible answer names the redaction method, the test set used to check it and who signs off on the result.

Next, ask how citation accuracy is tested against real tickets rather than against the help center alone. A good partner builds a labeled set of past questions with the answer and the source article or ticket that supports it, then checks that each cited passage actually contains the claim. Ask which Zammad version the connector targets, given that Zammad 7.2 was released on 23 September 2026 and has security releases since then, and how the partner handles the 6.5 line in parallel. Ask whether the connector reads through the Zammad API or a database export, and how it stays current with ticket edits, merges and closed-ticket reopenings. Also ask how prompt injection hidden in ticket text, such as a customer instructing the assistant to ignore policy, is filtered before retrieval and before generation.

Finally, ask how deflection is measured and which license limits apply. Deflection should be counted only when a customer's question is answered and not followed by a ticket on the same issue within an agreed window, so ask for the exact definition, the window length and the source of the data. For licensing, ask whether the partner will build on Dify, whose license restricts multi-tenant use from the source code, or on Open WebUI, whose license restricts changes to branding above 50 end users in any rolling 30 day period, and what that means for an internal agent team versus a customer-facing portal. Finally, ask how erasure requests and edits flow into re-indexing across source tickets, chunks and vectors, and what evidence of deletion the partner can produce on request.