Walkthrough: extracting your help desk's deflection data for a report

clara_k · 2026-08-23T06:06:07Z

The proliferation of AI-powered deflection features—auto-suggested articles, chatbot interactions, and proactive answer prompts—is often marketed with impressive but nebulous efficiency gains. To move beyond vendor claims and internal anecdotes, one must conduct a granular analysis of one's own data. This post outlines a methodological approach to extracting and structuring deflection data from a typical enterprise help desk platform, enabling a fact-based assessment of ROI and feature efficacy. The primary challenge is that "deflection" is not a single, universally logged metric. It is a derived value, contingent on your specific platform's event logging and your organization's definition of a successful deflection. For the purpose of this walkthrough, we will define a deflection as a *user-initiated session that concludes with a viewed knowledge base article without subsequent ticket creation within a defined time window (e.g., 24 hours).* This excludes sessions where articles are served by an agent within a ticket thread. **Step 1: Identify Relevant Data Sources** You will need administrative access to your help desk's backend reporting, data export functions, or ideally, direct database/API access. Key tables or logs to examine include: * **Search Query Logs:** Records of user searches within the help portal, including session IDs, query strings, and timestamps. * **Article View Logs:** Tracks each knowledge base article view, linked to a user session ID and a timestamp. * **Ticket Creation Logs:** The canonical source for new ticket events, including creation timestamp and often the source (e.g., "web portal," "email," "chat"). * **Chatbot Interaction Logs:** If using an AI chatbot, logs detailing conversation flows, suggested articles, and session outcomes. * **User Session Tables:** Ties together a sequence of user actions within a single help portal visit. **Step 2: Construct the Data Relationship** The core analytical task is to join these datasets on a common session identifier. The logic flow for a basic deflection query should be: 1. Start with a **Search Query Log** entry (the initiation of a self-service intent). 2. Left join to **Article View Logs** from the same session ID within a short time delta (e.g., 300 seconds). This identifies sessions where a search led to a viewed article. 3. Perform an anti-join against the **Ticket Creation Log**, filtering out any session IDs where a ticket was created from the same user (or same session, if tracked) within your defined post-interaction window (e.g., 24 hours). The resulting dataset represents probable deflected tickets. **Step 3: Enrich with AI Feature Attribution** To assess specific AI features, you must filter this deflection data further. For example: * **AI-Suggested Articles:** Join deflection sessions to logs that flag when an article was presented via an "AI Suggest" widget or chatbot response. This often requires a custom event tag. * **Chatbot Deflections:** Isolate sessions that began with chatbot interaction and ended in an article view without ticket creation. The chatbot logs should provide the initial trigger. * **Proactive Deflection:** Analyze pageview or in-app event logs to identify instances where a contextual help article was pushed to the user based on their UI navigation, and then check for subsequent ticket creation. **Step 4: Calculate Meaningful Metrics** Raw deflection counts are less valuable than rates. Key performance indicators should include: * **Deflection Rate:** (Number of Deflected Sessions) / (Total Number of Self-Service Initiated Sessions). A "session" can be defined as a unique search query or a help portal visit. * **AI-Assisted Deflection Rate:** (Deflections with AI Feature Attribution) / (Total Deflections). This quantifies the AI's contribution. * **Cost Avoidance:** Apply your average cost-per-ticket (fully loaded agent cost) to the number of deflected tickets. This translates technical metrics into financial language for procurement and leadership. * **Trend Analysis:** Track these rates weekly/monthly, especially after deploying new AI features or updating knowledge base content, to measure impact. Without this disciplined extraction and analysis, you are left relying on the vendor's dashboard, which may use definitions of deflection that inflate its perceived value. The effort to build this internal report is non-trivial but pays dividends in contract negotiations, feature justification, and understanding the true performance of your AI support investment. I am interested to hear from others who have attempted similar analyses—what were the primary data obstacles you encountered, and how did you validate the accuracy of your deflection attribution?

Page 2 / 2 Prev

AI Features in Support Tools

Last Post by code_reviewer_anna 1 month ago

16 Posts

16 Users

0 Reactions

48 Views

RSS

code_reviewer_anna

(@code_reviewer_anna_v2)

Honorable Member

Joined: 6 months ago

Posts: 422

23/08/2026 6:29 pm

Right, that multi-device gap is huge. We try to patch it by looking for matching email addresses or internal user IDs across the session and ticket, but that only works if your auth system logs that ID for both actions. If the knowledge base visit is anonymous, you're out of luck.

Some teams just accept the blind spot and treat their deflection rate as a conservative baseline - the real number is probably higher, but at least you can trust the lower bound.

Clean code, happy life

ReplyQuote

Page 2 / 2 Prev