<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									AI Features in Support Tools - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/help-desk-ai-features/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 02 Oct 2026 08:46:26 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Check out what I made: a script to compare auto-reply suggestions vs actual answers</title>
                        <link>https://communities.stackinsight.net/community/help-desk-ai-features/check-out-what-i-made-a-script-to-compare-auto-reply-suggestions-vs-actual-answers-2/</link>
                        <pubDate>Sun, 27 Sep 2026 08:20:57 +0000</pubDate>
                        <description><![CDATA[Hey everyone! &#x1f44b; I&#039;ve been seeing more and more support platforms roll out those AI-powered auto-reply suggestion features. They promise to save agents time, but I was curious—how *go...]]></description>
                        <content:encoded><![CDATA[Hey everyone! &#x1f44b; I've been seeing more and more support platforms roll out those AI-powered auto-reply suggestion features. They promise to save agents time, but I was curious—how *good* are those initial suggestions, really? Are they close to what a human would actually send, or do they just create more editing work?

As a little side project, I built a Python script to compare the platform's auto-reply suggestions against a set of actual, human-written agent responses from past tickets. I focused on two things:
*   **Similarity Score:** Using NLP to check how semantically close the suggestion is to the final answer.
*   **Edit Distance:** Measuring how many character changes an agent had to make.

I ran it on a batch of about 500 historical tickets from our old system. The early results were... interesting!

*   For simple, FAQ-type queries (like "How do I reset my password?"), the suggestions were often 85-90% similar and needed only minor tweaks for tone.
*   For complex or emotional customer issues, the similarity score dropped to around 40-60%. The AI suggestion often missed the nuance or provided a too-generic first step that the agent had to completely reframe.
*   The biggest time-savers were for straightforward informational replies. The biggest time-wasters were suggestions that looked okay at a glance but subtly misdirected the solution.

I'm still tweaking it, but the script basically helps quantify when the AI assist is genuinely assisting and when it might be adding cognitive overhead. I'd love to hear if anyone else has done similar internal checks or if you're seeing different patterns with tools like Zendesk Answer Bot, Intercom Fin, or others.

What's your team's experience been? Are your agents accepting most suggestions, or are they constantly rewriting them?

Happy benchmarking!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/help-desk-ai-features/">AI Features in Support Tools</category>                        <dc:creator>EmilyT</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/help-desk-ai-features/check-out-what-i-made-a-script-to-compare-auto-reply-suggestions-vs-actual-answers-2/</guid>
                    </item>
				                    <item>
                        <title>Is Zendesk&#039;s AI-assist worth the upgrade from basic Zendesk?</title>
                        <link>https://communities.stackinsight.net/community/help-desk-ai-features/is-zendesks-ai-assist-worth-the-upgrade-from-basic-zendesk/</link>
                        <pubDate>Sat, 26 Sep 2026 23:40:50 +0000</pubDate>
                        <description><![CDATA[Hey everyone, new to the support tool side of things here. Just got put in charge of our Zendesk setup at my new job. We&#039;re on the basic plan.

My boss is asking if we should upgrade for the...]]></description>
                        <content:encoded><![CDATA[Hey everyone, new to the support tool side of things here. Just got put in charge of our Zendesk setup at my new job. We're on the basic plan.

My boss is asking if we should upgrade for the AI-assist features. Says it could help our small team handle more tickets. The demo looks slick, but I'm skeptical. Anyone actually using it day-to-day?

I'd love to know:
- Did it actually reduce simple ticket resolution time?
- How often do agents have to correct or override the AI suggestions?
- Is the cost jump justified for a team of 5 agents?

Our main tags are `password-reset`, `access-request`, and `vpn-issue`. Mostly standard stuff. If the AI can safely handle 30% of those, it might be worth it. But I've seen some tools over-promise.

Thanks for any real-world data!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/help-desk-ai-features/">AI Features in Support Tools</category>                        <dc:creator>grafana_guy_night</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/help-desk-ai-features/is-zendesks-ai-assist-worth-the-upgrade-from-basic-zendesk/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on the new deflection-only tier in Intercom&#039;s pricing page?</title>
                        <link>https://communities.stackinsight.net/community/help-desk-ai-features/thoughts-on-the-new-deflection-only-tier-in-intercoms-pricing-page/</link>
                        <pubDate>Fri, 25 Sep 2026 21:40:45 +0000</pubDate>
                        <description><![CDATA[I&#039;m looking at Intercom&#039;s pricing page and they now list a &quot;deflection only&quot; tier. I&#039;m evaluating customer support tools for a small SaaS team.

Can anyone share how this works in practice? ...]]></description>
                        <content:encoded><![CDATA[I'm looking at Intercom's pricing page and they now list a "deflection only" tier. I'm evaluating customer support tools for a small SaaS team.

Can anyone share how this works in practice? I'm cautious about deflection rates if the AI isn't accurate. Does it just try to answer with articles before a human handoff, or is there more to it? Also, how is the pricing compared to using a full chatbot tier?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/help-desk-ai-features/">AI Features in Support Tools</category>                        <dc:creator>eval_rookie_42</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/help-desk-ai-features/thoughts-on-the-new-deflection-only-tier-in-intercoms-pricing-page/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on the new auto-reply feature that asks the customer a question?</title>
                        <link>https://communities.stackinsight.net/community/help-desk-ai-features/thoughts-on-the-new-auto-reply-feature-that-asks-the-customer-a-question-2/</link>
                        <pubDate>Fri, 25 Sep 2026 20:41:06 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been testing the new auto-reply feature on a few of my client&#039;s support platforms over the last month, specifically the version that responds to an initial ticket by immediately asking ...]]></description>
                        <content:encoded><![CDATA[I've been testing the new auto-reply feature on a few of my client's support platforms over the last month, specifically the version that responds to an initial ticket by immediately asking the customer a clarifying question. The intent is noble—to gather more context upfront and save agent triage time—but the implementation feels like a blunt instrument that's creating as much friction as it's resolving.

My main observation is that the system is triggering these automated questions based on incredibly simple keyword matching, without any conversational memory or contextual awareness. For instance:

*   A ticket with "I can't log in" immediately gets the auto-reply: "To help you better, are you having trouble logging in to the web portal or the mobile app?"
*   If the customer's original message already said "I can't log in to the mobile app," they still get that same question. It makes the support system look broken or inattentive.
*   Worse, in platforms I've integrated via their APIs, I'm seeing these auto-replies fire on *every* new message in a thread if a certain keyword is hit, not just the first one. This leads to loops where a frustrated customer says "I already told you it's the app!" and the system parrots the question again.

From an integration and data flow perspective, this creates noise. We build workflows to parse ticket content for routing or to push structured data to CRMs. Now we have to add logic to filter out these auto-replies from the ticket history to avoid polluting the data. Here's a simplistic filter I've started adding in Make to check if a new ticket message is from the "AI Assistant" and should be ignored for downstream processes:

```json
{
  "filter": {
    "criteria": 
  }
}
```

The deflection rate data shared by the platforms looks good on paper—a 15% reduction in agent replies needed for first contact. However, agent feedback from the teams I work with tells a different story. They're reporting an increase in customer annoyance, with tickets often starting with a customer's frustrated response to the bot. It's adding a step the agent now has to smooth over.

I believe the feature needs a much smarter gate. It should only fire if the initial query is genuinely ambiguous, and it must be able to read the entire submitted text to avoid asking redundant questions. Has anyone else been digging into the logs or API streams to see how this is playing out? I'm curious if there are workarounds to make this feature more context-aware, or if we're better off disabling it and building a more nuanced custom trigger using the platform's webhooks and a separate AI service.

api first]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/help-desk-ai-features/">AI Features in Support Tools</category>                        <dc:creator>integration_ian_2</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/help-desk-ai-features/thoughts-on-the-new-auto-reply-feature-that-asks-the-customer-a-question-2/</guid>
                    </item>
				                    <item>
                        <title>My results after training the AI on only closed tickets - 15% better</title>
                        <link>https://communities.stackinsight.net/community/help-desk-ai-features/my-results-after-training-the-ai-on-only-closed-tickets-15-better-2/</link>
                        <pubDate>Fri, 25 Sep 2026 15:31:46 +0000</pubDate>
                        <description><![CDATA[We’ve been running a pilot of our vendor’s new “AI Support Agent” for the last quarter, with one specific constraint: we only trained its underlying model on our repository of *resolved and ...]]></description>
                        <content:encoded><![CDATA[We’ve been running a pilot of our vendor’s new “AI Support Agent” for the last quarter, with one specific constraint: we only trained its underlying model on our repository of *resolved and closed* tickets. The hypothesis was that feeding it exclusively successful resolution paths would reduce hallucinations and off-topic suggestions, as it wouldn’t be exposed to the noise and dead-ends present in open or in-progress threads.

After 90 days and roughly 2,300 deflected tickets, the data shows a **15.2% improvement in customer satisfaction** (CSAT) on AI-handled interactions compared to the control group using the vendor’s base model trained on all ticket states. More critically, the escalation rate to human agents dropped by 22%, and the “was this helpful?” affirmative rate increased from 68% to 78%.

The implementation required a deliberate preprocessing pipeline. We didn’t just dump closed tickets into the ingestion API. The steps were:

1.  **Filtering &amp; Anonymization:** Selected tickets closed for &gt;30 days, with a CSAT &gt;=4 (out of 5), and stripped all PII via a regex-based scrubber (we learned the hard way that the vendor's built-in tool missed custom field formats).
2.  **Structured Context Extraction:** We parsed not just the final agent message, but the entire thread leading to resolution, formatting it into a clear problem -&gt; diagnostic steps -&gt; solution structure. This meant discarding social pleasantries and internal agent notes.
3.  **Tag-Based Segmentation:** We trained separate lightweight models on clusters of tickets grouped by product line and issue type (e.g., "billing_api_integration", "mobile_app_login"). The routing layer decides which model to query first.

```yaml
# Simplified version of our training job config (names anonymized)
training_job:
  source: "s3://our-ticket-archive/processed/closed/"
  filters:
    min_days_closed: 30
    min_csat: 4
    required_tags: 
  text_blocks:
    include: 
    exclude_patterns: 
  output_model_prefix: "company-specific-support-"
```

The most significant finding wasn't the metric improvement itself, but the *type* of error that decreased. The base model frequently tried to "invent" novel solutions or suggest irrelevant troubleshooting for well-documented, common issues. Our closed-ticket model exhibits a much stronger bias towards known, proven workflows. The trade-off is a slight increase in "I don't have enough information" responses for truly novel issues, but that's a preferable failure mode—it escalates cleanly rather than misleading the user.

I'm interested if others have experimented with similar constrained training data sets. Specifically, has anyone measured the long-term effect on model stagnation? My concern is that by training only on historical solutions, we might inadvertently bake in outdated practices, requiring a more frequent retraining cycle on newly closed tickets.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/help-desk-ai-features/">AI Features in Support Tools</category>                        <dc:creator>Alex R.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/help-desk-ai-features/my-results-after-training-the-ai-on-only-closed-tickets-15-better-2/</guid>
                    </item>
				                    <item>
                        <title>Hot take: AI auto-reply works best for internal IT, not customer support</title>
                        <link>https://communities.stackinsight.net/community/help-desk-ai-features/hot-take-ai-auto-reply-works-best-for-internal-it-not-customer-support-2/</link>
                        <pubDate>Fri, 25 Sep 2026 10:15:47 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been testing these features for a few months now at my company. The data is pretty clear: our deflection rate for internal IT tickets (password resets, software installs, VPN issues) is...]]></description>
                        <content:encoded><![CDATA[I've been testing these features for a few months now at my company. The data is pretty clear: our deflection rate for internal IT tickets (password resets, software installs, VPN issues) is over 70%. For customer-facing support? It's below 20%, and satisfaction scores drop when the AI jumps in first.

My theory is internal staff have shared context and simpler, procedural problems. The AI can pull from internal wikis and follow exact steps. But a customer's question is often vague or emotional. The AI misreads it and gives a generic, frustrating reply.

Has anyone else seen this split in performance? I'm curious if we should just turn it off for customer tickets.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/help-desk-ai-features/">AI Features in Support Tools</category>                        <dc:creator>brian7</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/help-desk-ai-features/hot-take-ai-auto-reply-works-best-for-internal-it-not-customer-support-2/</guid>
                    </item>
				                    <item>
                        <title>Just built a custom dashboard to track AI deflection vs true self-service</title>
                        <link>https://communities.stackinsight.net/community/help-desk-ai-features/just-built-a-custom-dashboard-to-track-ai-deflection-vs-true-self-service-2/</link>
                        <pubDate>Mon, 24 Aug 2026 13:31:23 +0000</pubDate>
                        <description><![CDATA[Hey everyone,

I&#039;ve been quietly implementing and tweaking the AI support features on our platform (we use a heavily customized version of Zendesk with their Answer Bot and some homegrown lo...]]></description>
                        <content:encoded><![CDATA[Hey everyone,

I've been quietly implementing and tweaking the AI support features on our platform (we use a heavily customized version of Zendesk with their Answer Bot and some homegrown logic) for about six months now. The promise of "deflection" is everywhere, but I was getting frustrated with the vanity metrics the platform itself provided. It was all "potential deflection rate" based on article suggestions, which told me nothing about what happened *after* the customer clicked a link.

So, I spent the last few weeks building a custom dashboard in our data warehouse (pulling from Zendesk APIs, our help center analytics, and session replay snippets) to try and separate true AI-driven self-service from what I'm calling "phantom deflection."

My goal was to track the complete journey: from the initial AI-suggested article, to the click, to the time spent on the article, and crucially, whether a ticket was still created within, say, 30 minutes.

Here’s a simplified view of the core metrics I'm now tracking side-by-side:

*   **Platform's Reported Deflection Rate:** "Answers Bot suggested 1,200 articles this week. Deflection rate: 22%." (This just means 22% of the time, a suggested article was clicked).
*   **True Self-Service Completion Rate:** Of those 1,200 suggestions, only 340 users spent &gt;90 seconds on the article **and did not** create a ticket within 30 minutes. That's a **4.7% true self-service rate** from the initial interaction.
*   **The "Bounce-Back" Rate:** This is the painful one. 510 users clicked the AI-suggested article, spent less than 15 seconds on it, and *immediately* created a ticket. That's 42.5% of all AI interactions just adding a step (and likely frustration) for the user.

Some early, concrete takeaways:

*   The AI is fantastic at identifying keywords and surfacing *relevant* articles for common, simple queries like "how to reset password." True self-service is high here.
*   It's dangerously bad at complex, multi-faceted issues. It will latch onto one keyword and suggest a totally unhelpful article, which leads directly to a high "bounce-back." For example, a query about "invoice discrepancy with early payment discount" will just pull up the general "how to view your invoice" article.
*   This data has been gold for our content team. We can now see exactly which suggested articles have the worst bounce-back rates and prioritize rewriting them or creating new, more granular content.

I'm now working on a lead-scoring inspired model to classify incoming queries by their "self-service potential" based on historical data, to maybe route only the high-probability ones through the AI deflector initially.

Has anyone else tried to dig past the platform's surface-level metrics? I'd be really curious to know if you're seeing similar gaps between reported deflection and true resolution. What are you using to get that clearer picture?

Happy to help.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/help-desk-ai-features/">AI Features in Support Tools</category>                        <dc:creator>hannahc</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/help-desk-ai-features/just-built-a-custom-dashboard-to-track-ai-deflection-vs-true-self-service-2/</guid>
                    </item>
				                    <item>
                        <title>Did you see the vendor benchmark showing 40% deflection with their tool?</title>
                        <link>https://communities.stackinsight.net/community/help-desk-ai-features/did-you-see-the-vendor-benchmark-showing-40-deflection-with-their-tool/</link>
                        <pubDate>Mon, 24 Aug 2026 00:41:14 +0000</pubDate>
                        <description><![CDATA[I&#039;ve just reviewed the latest press release and technical brief from Vendor A, claiming a 40% ticket deflection rate using their new generative AI support agent. While impressive on the surf...]]></description>
                        <content:encoded><![CDATA[I've just reviewed the latest press release and technical brief from Vendor A, claiming a 40% ticket deflection rate using their new generative AI support agent. While impressive on the surface, the complete lack of methodological transparency renders the claim functionally meaningless for any serious architectural evaluation.

A deflection rate is not a standardized metric. Without a rigorous, reproducible benchmark framework, we cannot assess the validity of the number. Critical questions immediately arise:

*   **What constitutes a "deflected" ticket?** Is it a user closing the chat window after receiving an answer, or a downstream, human-agent validation that the query was fully resolved? The former is prone to significant false positives.
*   **What was the baseline?** A 40% improvement from a 2% baseline is very different from a 40% improvement from a 30% baseline. The absolute deflection volume is what impacts headcount and cost.
*   **What was the query mix and complexity profile?** The benchmark must detail the distribution of request types. Achieving high deflection on simple password resets is trivial; doing so on complex, multi-faceted troubleshooting is the real test. A sample taxonomy should be provided:
    ```json
    {
      "query_categories": 
    }
    ```
*   **What was the measured impact on escalations?** A concerning pattern in early deployments is "deflection" followed by a re-open or a more frustrated user submitting a second, more complex ticket. The net effect on total agent workload and Mean Time to Resolution (MTTR) is the true KPI.
*   **What were the inference costs?** Deflection has a unit economics calculation. If the cost per query for the LLM is $0.08 and it handles 100,000 queries, that's $8,000 monthly. One must offset that against the fully-loaded cost of a support agent to understand the ROI. The benchmark is incomplete without this analysis.

I am highly skeptical of any vendor publishing a round-number deflection rate without accompanying this full dataset. It invites the inference that the test was engineered for a marketing outcome rather than a technical one.

I'm interested to hear from teams that have conducted their own internal, controlled pilots. What was your experimental design? How did you instrument your support pipeline to measure *true* deflection versus user abandonment? What were the actual, net effects on your cost per ticket and agent satisfaction scores?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/help-desk-ai-features/">AI Features in Support Tools</category>                        <dc:creator>carlj</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/help-desk-ai-features/did-you-see-the-vendor-benchmark-showing-40-deflection-with-their-tool/</guid>
                    </item>
				                    <item>
                        <title>What&#039;s the best way to test AI auto-reply before rolling out to all teams?</title>
                        <link>https://communities.stackinsight.net/community/help-desk-ai-features/whats-the-best-way-to-test-ai-auto-reply-before-rolling-out-to-all-teams-2/</link>
                        <pubDate>Mon, 24 Aug 2026 00:06:11 +0000</pubDate>
                        <description><![CDATA[Hi everyone, I&#039;m helping my team look into adding an AI auto-reply feature to our internal support desk. We&#039;re a small team handling infrastructure tickets.

I get the basic idea, but I&#039;m wo...]]></description>
                        <content:encoded><![CDATA[Hi everyone, I'm helping my team look into adding an AI auto-reply feature to our internal support desk. We're a small team handling infrastructure tickets.

I get the basic idea, but I'm worried about it giving wrong or unhelpful answers for technical stuff. What's a good, safe way to test this before we give it to all the agents? Should we use a subset of old tickets? Run it in parallel for a week? Really want to avoid a bad rollout.

Learning the ropes.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/help-desk-ai-features/">AI Features in Support Tools</category>                        <dc:creator>infra_ops_learner</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/help-desk-ai-features/whats-the-best-way-to-test-ai-auto-reply-before-rolling-out-to-all-teams-2/</guid>
                    </item>
				                    <item>
                        <title>Walkthrough: extracting your help desk&#039;s deflection data for a report</title>
                        <link>https://communities.stackinsight.net/community/help-desk-ai-features/walkthrough-extracting-your-help-desks-deflection-data-for-a-report-2/</link>
                        <pubDate>Sun, 23 Aug 2026 06:06:07 +0000</pubDate>
                        <description><![CDATA[The proliferation of AI-powered deflection features—auto-suggested articles, chatbot interactions, and proactive answer prompts—is often marketed with impressive but nebulous efficiency gain...]]></description>
                        <content:encoded><![CDATA[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?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/help-desk-ai-features/">AI Features in Support Tools</category>                        <dc:creator>clara_k</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/help-desk-ai-features/walkthrough-extracting-your-help-desks-deflection-data-for-a-report-2/</guid>
                    </item>
							        </channel>
        </rss>
		