Reducing support tickets is a possible outcome of better self-service, not a number to promise before you define what counts as resolved. A visitor who receives a clear cited answer may avoid a ticket. A visitor who closes the chat after a confusing answer may also avoid a ticket, but that is abandonment, not success.<\/p>\n
Choose definitions that a support and commercial team can both inspect. A useful starting point separates: conversations started, questions answered from an approved source, honest refusals, contact requests, live-agent handovers, and later tickets on the same topic where your systems can reasonably connect them. Do not call every answered turn a deflection; the visitor may still email when the answer is incomplete.<\/p>\n
RobiFox\u2019s usage view distinguishes conversations, answered turns, refusals and contact requests. Its wording explicitly avoids an \u201chours saved\u201d estimate because multiplying a count by an assumed time would create an invented figure. That is a sensible discipline for any support-impact report.<\/p>\n
Ticket volume follows traffic, seasonality, product launches, outages and policy changes. Compare equivalent periods where possible: the same weekdays, campaign status, markets and major releases. Record website sessions or eligible page loads alongside ticket counts. A decline in tickets during a traffic decline cannot show that the chatbot resolved more work.<\/p>\n RobiFox records bubble impressions, opens and conversations as separate figures, and warns that an attention-grabbing bubble can increase clicks without producing questions. That is an important distinction before treating chat activity as support success.<\/p>\n Define a deflected issue conservatively. For example, count it only when the visitor received a source-backed answer and did not contact support about the same issue within a defined observation window, subject to your privacy and data limits. Keep a separate \u201cunknown outcome\u201d category for chats that end without a clear sign of resolution.<\/p>\n Sample conversations regularly. Did the answer contain the condition the visitor needed? Did the citation lead to a usable policy? Did the visitor reformulate the question, ask for a person, or leave? This qualitative check prevents a dashboard from declaring victory over a silent failure.<\/p>\n Use the same definitions throughout the comparison. If a contact request is counted as a failure in one month but a qualified handover in the next, the trend becomes a reporting change rather than a service result. Keep a short annotation log for new campaigns, site outages, policy changes and staffing events that could explain an apparent movement.<\/p>\n Not every refusal should be removed. Account-specific questions and negotiated exceptions may belong with people. However, a recurring, answerable question is evidence that a paragraph, table or product page is missing or hard to find. RobiFox groups unanswered questions by frequency and lets a team either create an approved answer or link the visitor wording to existing knowledge after a retrieval failure.<\/p>\n That distinction matters to ticket reduction. A genuine gap may be fixed with better content; a retrieval failure may need better search wording; a human-only question needs faster routing. Combining all three into one \u201cbot failure\u201d count leads to the wrong investment.<\/p>\n Begin with one support topic that has stable traffic and a clear knowledge source, such as return eligibility or installation steps. Establish a baseline across comparable periods. Launch the chatbot with a source-based test set, then compare topic-specific contacts, chat outcomes and sampled conversation quality. Record concurrent changes such as a new promotion or help-centre rewrite.<\/p>\n RobiFox\u2019s public measurement method distinguishes answerable questions, required refusals, cited sources and latency, and says its internal benchmark does not predict a customer site. Apply the same caution to operational results: measure your own context and report uncertainty rather than inventing savings or customer outcomes.<\/p>\n A useful weekly report shows traffic context, the top question categories, source-backed answers, refusals, contact requests, handovers and the top missing topics. Add a short decision column: improve a source, test retrieval, assign a human owner or leave the boundary in place. This turns a ticket-count ambition into a content and service process.<\/p>\n For the underlying controls, see RobiFox features<\/a>, How it works<\/a> and How we measure<\/a>.<\/p>\n\n
\n \nMeasure<\/th>\n Interpret it with<\/th>\n<\/tr>\n<\/thead>\n \n Tickets by topic<\/td>\n Traffic, releases, seasonality and changes to help content.<\/td>\n<\/tr>\n \n Chat conversations<\/td>\n Widget impressions and opens, not tickets alone.<\/td>\n<\/tr>\n \n Source-backed answers<\/td>\n Question samples, cited-source validity and follow-up behaviour.<\/td>\n<\/tr>\n \n Refusals and handovers<\/td>\n Whether they reached a useful human route or revealed a content gap.<\/td>\n<\/tr>\n \n Contact requests<\/td>\n Qualification, response time and eventual outcome\u2014not merely form submission.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n Separate deflection from abandonment<\/h2>\n
Use unanswered questions as improvement work<\/h2>\n
Run a modest, reviewable experiment<\/h2>\n
Report what the team can act on<\/h2>\n