Kahuna Labs Blog

By John Ragsdale, SVP Marketing, Kahuna Labs

Most AI strategies in support are unintentionally building the business case to eliminate themselves.

That’s the uncomfortable reality support leaders need to confront.

Yesterday, Tom Sweeny, CEO of ServiceXRG, published the latest edition of his Support Leadership Unfiltered newsletter, Edition 12: AI Efficiency Is a Start. Not a Strategy, based on his Support Attribution Framework. One point in particular stood out to me: when AI enables support to handle more volume with fewer resources, the business does not automatically conclude that freed-up support expertise should be reallocated to higher-value customer work. More often, the business concludes that support simply needs fewer people. 

That conclusion makes sense if efficiency is the only story support leaders tell.

Most AI business cases in support focus heavily on efficiency. Deflect more cases. Reduce handle time. Shorten time to resolution. Improve agent productivity. Lower cost to serve. All of these are valid goals, and in a cost-conscious environment, they are difficult to ignore.

But there is a strategic risk in building an AI plan around efficiency alone.

If the only benefit support leaders can articulate is that the same work can now be done with fewer people, then the obvious executive response is headcount reduction. A 20% productivity improvement quickly becomes a conversation about cutting 20% of the resources. That may satisfy a short-term financial target, but it misses the larger opportunity AI creates for support organizations.

Every support leader I know has a long list of valuable work their teams never have enough time to do. Support engineers are so consumed by managing queues, closing cases, handling escalations, and keeping up with customer communications that strategic work gets pushed aside. Not because it lacks value, but because there is no capacity.

That work includes cross-training newer engineers, sharing troubleshooting knowledge across teams, improving internal diagnostic playbooks, collaborating with engineering on better log analysis, identifying product friction points, documenting customer configuration patterns, supporting customer success with technical insight, and helping product teams understand where customers are struggling.

In many organizations, senior support engineers also have the expertise to contribute directly to revenue-generating activities. They can support Technical Account Management programs, participate in premium support offerings, advise customers on best practices, help with complex onboarding, and identify accounts that would benefit from additional services or training. But these opportunities are often left underdeveloped because the same experts are trapped in reactive case work.

This is where many AI strategies are incomplete.

When an AI tool is proposed, the plan usually includes a productivity assumption. It may estimate that engineers will resolve cases faster, handle more volume, or reduce manual research time. What is often missing is the next question: what will we do with the capacity we free up?

That question should not be an afterthought. It should be part of the AI strategy from the beginning.

Every support AI business case should include two components. The first is the traditional ROI model: how much time, cost, or effort can be reduced. The second is a redeployment model: how freed-up capacity will be redirected toward higher-value business outcomes.

Without that second model, support leaders leave the conclusion to finance. And finance will often draw the simplest conclusion: fewer people are needed.

With a redeployment model, the conversation changes. Instead of saying, “AI will reduce support effort by 20%,” the support leader can say, “AI will free up capacity that we will redeploy into escalation prevention, product feedback loops, customer enablement, premium support, TAM coverage, and proactive account intelligence.” That is a very different business conversation.

It also creates a more complete way to measure the value of AI.

The ROI of support AI should not be limited to cost savings. It should also include the business impact of what newly available capacity makes possible. Did escalations decline because senior engineers were able to intervene earlier? Did customer onboarding improve because support had time to identify common training gaps? Did product quality improve because support partnered with engineering on recurring diagnostic patterns? Did premium support revenue grow because SMEs were available for higher-value customer engagements?

Those outcomes are harder to measure than handle time reduction, but they are much more strategically important.

This is also where support has an opportunity to reposition itself inside the business. If support uses AI only to become more efficient, it risks reinforcing its identity as a cost center. But if support uses AI to free expert capacity for higher-value work, it begins to operate as a strategic source of customer intelligence, product insight, and revenue enablement.

That shift will not happen automatically.

AI will expose capacity. It will not decide how that capacity should be used. That is a leadership responsibility.

Support leaders should be asking a new set of questions every time an AI initiative is proposed. What work will this automate or accelerate? Which roles will gain capacity? How much capacity will be created? Which higher-value activities are currently underfunded or ignored? How will those resources be redeployed? How will we measure the business impact of that redeployment?

These questions should be answered before the tool is implemented, not after savings appear.

The companies that fail to do this will likely use AI to shrink support. The companies that get it right will use AI to expand the strategic contribution of support.

That is the real opportunity.

AI efficiency is important. But efficiency without a redeployment strategy is just a cost-cutting argument waiting to happen.

Support leaders need to make the next move before someone else makes it for them.

Why Support Teams Need More Than Another Dashboard

By John Ragsdale, SVP Marketing, Kahuna Labs

Support organizations already have no shortage of escalation signals.

Managers are flooded with dashboards, SLA warnings, aging-ticket reports, customer sentiment indicators, inactivity alerts, and customer health scores. The problem is rarely lack of visibility. The real problem is understanding which signals actually matter, why escalation risk exists, and what action should be taken before customer frustration spirals into a formal escalation.

This is where many current escalation prediction tools fall short.

Most approaches focus primarily on aggregating signals. They identify symptoms such as declining sentiment, slow response times, missed milestones, or unusually long ticket duration. While these indicators can be useful, they often lack the operational context necessary to help support teams intervene effectively.

As a result, support managers are frequently left staring at yet another dashboard without clear answers to critical questions:

• Why is this case actually at risk?
• Is the support engineer struggling, waiting on engineering, or simply overloaded?
• Is the customer frustrated because of delays, repeated requests, or the business impact of the issue itself?
• What intervention is most likely to prevent escalation?

Prediction alone does not solve the problem.

In many cases, escalation management has become an exercise in signal overload. Support leaders are inundated with alerts but still rely heavily on manual interpretation, tribal knowledge, and reactive management practices to determine where to focus attention. Important cases still fall through the cracks, particularly lower-priority cases that quietly deteriorate over time before suddenly becoming executive-level issues.

At Kahuna, we believe escalation prediction needs to be approached differently.

Rather than treating escalation risk as a standalone analytics problem, we approached it as an extension of the same core architecture that powers effective troubleshooting guidance. Our escalation prevention and proactive support capabilities are built on the same foundational technologies that drive Kahuna’s Troubleshooting Map™ and snapshot analysis engine.

That distinction matters because not all escalation signals mean the same thing.

For example, consider a ticket that has seen no meaningful activity for several days. Traditional escalation tools might simply flag the case as “inactive.” But inactivity itself is not the real insight. The important question is why the inactivity exists.

Is the support engineer waiting for engineering to provide an update? Is the engineer unfamiliar with this type of issue and unsure what troubleshooting step should happen next? Or has the case simply been overlooked in a crowded queue? Kahuna’s approach attempts to differentiate between these scenarios and recommend actions appropriate to the likely root cause.

The same principle applies to customer sentiment.

Many systems can identify that customer sentiment is becoming more negative. But understanding why sentiment is deteriorating is far more valuable operationally than simply assigning a red score. Is the customer frustrated because this is a repeat issue? Is there a looming business deadline? Has the customer received multiple requests for additional logs and diagnostics without visible progress? Has communication frequency dropped below expectations?

These distinctions fundamentally change the recommended intervention.

In some situations, the best next step may be engaging an SME who has handled similar cases at comparable complexity levels. In others, the correct action may be proactively updating the customer while waiting on engineering, escalating internally, or simply helping an overwhelmed engineer reprioritize work.

This is where snapshot analysis becomes especially important.

Because Kahuna continuously analyzes historical troubleshooting journeys, the system can compare active cases against similar historical “snapshots” to identify patterns associated with escalation risk. The platform evaluates how long comparable cases typically took to progress, where delays usually occurred, what successful resolution paths looked like, and which engineers or SMEs historically handled similar scenarios effectively.

That contextual understanding enables escalation prediction to move beyond generic health scoring into something operationally actionable.

Another important distinction is that escalation risk is not viewed solely through the lens of customer sentiment or SLA compliance. In many support organizations, cases escalate because progress stalls even though activity remains high. Multiple back-and-forth interactions occur without narrowing the root cause or path forward. Engineers repeatedly request additional diagnostics. Resolution paths drift without clear momentum. These patterns often signal that the troubleshooting process itself is breaking down long before a customer formally escalates the issue.

Traditional dashboards often struggle to identify these nuances because they focus primarily on isolated metrics rather than contextual case progression.

The broader industry challenge is that support organizations already have plenty of tools capable of surfacing problems. What they increasingly need are systems capable of helping teams operationalize those signals in real time.

That means:

• identifying likely root causes behind escalation risk,
• understanding how similar cases evolved historically,
• recommending corrective actions,
• and helping both engineers and managers intervene before customer relationships deteriorate.

This is ultimately the larger shift happening across support operations.

The first generation of support AI focused heavily on visibility, analytics, and signal aggregation. The next generation will focus on operational guidance, orchestration, and proactive intervention.

Prediction alone is no longer enough.

The real opportunity is preventing escalations before they happen. This involves recommending the appropriate action in each situation to the SE and support manager, and providing visibility to support leadership on whether recommended actions were followed or ignored.

If you are interested in learning more, you can request a link to view a Kahuna AI overview and demo. If you would like to see our Escalation Prevention demo, send an email to info@kahunalabs.ai.

By Chaitanya Potluri, Co-Founder, Kahuna Labs

Enterprise technical support is a full-context problem. When a customer’s environment fails, the resolution almost always depends on the intersection of their specific implementation, the patches they’ve applied, the product version they’re running, and the history of prior issues on that account. The knowledge needed to resolve a case is rarely in one place, and the relevance of any given source depends on all of these factors at once.

As enterprises have looked to AI for help with technical support, most have reached for RAG (Retrieval-Augmented Generation), the conventional approach for grounding language models in company data. The pitch seems compelling: connect an LLM to your company’s documents, let it retrieve what’s relevant, and generate accurate answers grounded in real data instead of hallucinations.

For many use cases, RAG is useful: internal doc search, policy Q&A, employee onboarding: anywhere the question is clear and the answer lives in a single, well-written document. But in enterprise technical support for complex products, that describes a small fraction of incoming cases. KB coverage is structurally thin.

The combinatorial space of product versions, customer configurations, and deployment environments is too large to document comprehensively. Products evolve faster than documentation, engineers resolve cases and move on, and the knowledge accumulates in ticket histories and tribal memory. In cases where RAG has been force-fitted into technical product support, the results have been consistently disappointing. The cases that drive escalations, consume senior engineering time, and frustrate customers, stubbornly remain out of reach.

The reason is architectural, and not a matter of tuning.

Failure Mode 1: Support Tickets Are Not Documents

RAG was designed to work with clean, authored text: knowledge base articles, product documentation, policy manuals. Support tickets are none of these things. A typical enterprise ticket is a messy, multi-turn conversation containing:

• The customer’s initial report, often incomplete or imprecise.
• The engineer’s diagnostic questions and the customer’s replies, sometimes with log files pasted inline, sometimes with screenshots that are unreadable by RAG.
• Follow-up threads, internal notes, and eventually, if the ticket was resolved, a description of what worked.
• Noise layered throughout: email signatures repeated in every reply, auto-generated headers, PII, boilerplate disclaimers, and previous email chains quoted in full.
• Sensitive customer data embedded throughout: IP addresses, credentials, account-specific configuration details, and in some industries, protected health information, all of which creates a compounding cross-customer contamination risk when past tickets feed recommendations for different accounts.

Beyond what’s in the ticket, significant troubleshooting activity happens outside the ticketing system entirely: in Zoom calls, Remote Sessions, Slack threads, linked Jira or Linear tickets, and referenced documents. RAG can only retrieve what is indexed. If the ticket is the only indexed artifact, all of the reasoning and decisions that occurred in those other channels are invisible. The system is working from an incomplete record, and the recommendations it produces reflect that incompleteness.

When a RAG system retrieves a past ticket as a relevant document, it retrieves all of this. The language model then has to make sense of a conversation that may span weeks, extract the actual resolution from an abundance of noise, and determine whether that resolution applies to the current situation, all in a single generation pass. In practice, the model often either surfaces generic advice or latches onto an irrelevant detail buried in the noise. Neither outcome helps the engineer.

Tickets also have internal structure that RAG overlooks. A ticket is a conversation between at least two actors, the customer and the support engineer, with different roles and different levels of access. RAG retrieves this as an undifferentiated block. It cannot distinguish customer-reported symptoms from engineer-recommended actions, or unanswered questions from confirmed resolution steps. And when a single ticket covers multiple distinct problems over weeks, RAG retrieves the entire conversation as one unit rather than matching at the level of individual problem states.

This structural blindness has a safety consequence. Some troubleshooting steps are destructive or irreversible: restarting a production service, clearing a cache that triggers a full rebuild, modifying firewall rules. Because RAG cannot distinguish who performed each action in a past case, it also cannot assess whether a recommended step is safe for the person who will execute it now. A step that is routine for a senior engineer with direct infrastructure access may be catastrophic if followed by a customer or a new engineer working through a remote session. RAG retrieves what was done and presents it as what should be done, with no assessment of the risk.

The real-world diagnostic patterns buried in past tickets are genuinely valuable. But extracting them requires techniques purpose-built for this kind of data, not a general-purpose retrieval pipeline treating tickets as if they were authored documents.

Failure Mode 2: Blind to Trust, Relevance, Reliability, and Coverage

Even when RAG retrieves a relevant document, it has no way to assess how much that document should be trusted.

RAG ranks by similarity. It has no mechanism to filter or weigh results by the customer’s product version, configuration, or environment. A resolution that applies to version 4.2 is retrieved with the same weight as one for version 3.1, even when those versions are incompatible. Customer context, the very thing that makes a troubleshooting step relevant or irrelevant, plays no role in retrieval.

Reliability is similarly invisible. A two-year-old ticket on a deprecated version where the customer never confirmed the fix is ranked by the same criterion as a recently validated resolution on the current release. Whether the resolution was ever confirmed, how frequently it has been reused across other cases, and how recently it was validated are factors RAG does not consider.

Coverage is the most deceptive blind spot. Tickets frequently have gaps: critical steps that happened on a remote session with no transcript, diagnostics collected but never documented, engineers who resolved an issue over a call and closed the ticket with a summary that omits key reasoning. RAG retrieves these incomplete records and presents them as if they were full resolutions. An incomplete resolution pattern is worse than no pattern at all, because it gives engineers false confidence in a partial answer.

Failure Mode 3: The Query Problem

RAG assumes the question is known. A query goes in, the system retrieves documents that match, and the model answers. This works when the problem is well-defined: “What is the default timeout for service X?” has an answer that a good query will find.

But in troubleshooting, the problem statement itself is often the thing that needs to be figured out. A customer reports intermittent network latency after applying a recent patch. That could be:

• a configuration conflict introduced by the patch,
• a known issue with that build on the customer’s OS version,
• a network topology problem unrelated to the patch, and/or
• interaction between the patch and the customer’s load balancer settings.

The initial query that a RAG system would construct from this description is almost guaranteed to retrieve documents about network latency in general rather than the specific intersection of factors at play.

Expert troubleshooters handle this by iterating: they form a hypothesis, consult a source, refine their understanding, and consult a different source. A single retrieval pass does not capture this reasoning process. By the time the RAG pipeline returns results, it has already committed to one interpretation of the problem.

Failure Mode 4: One Ranked List and Many Knowledge Types

Enterprise support artifacts are not monolithic. They are spread across fundamentally different types of sources, each with its own structure, signal-to-noise ratio, and reliability characteristics:

• Official documentation is authoritative but often lags behind the actual product. It describes how things should work, not always how they do work.
• Past resolved tickets contain real-world patterns but are noisy, incomplete, and may reflect workarounds rather than root-cause fixes.
• Compatibility matrices and release notes are precise but narrow: they answer specific factual questions but do not provide diagnostic reasoning.
• Internal runbooks and tribal knowledge capture expert judgment but are rarely written down comprehensively.

RAG pipelines collapse all of these into a single ranked list. An internal runbook written by a senior engineer sits alongside a two-year-old ticket where the customer never confirmed the fix, and both are ranked by the same criterion: semantic similarity to the query. The ranking has no way to account for whether a source type is appropriate for the kind of problem being investigated, or whether the source itself is reliable.

Even splitting retrieval into separate indexes, one per source type, does not solve the fundamental problem. Each index still returns results ranked by similarity rather than diagnostic relevance, and nothing in the pipeline arbitrates across them.

Failure Mode 5: Conflicting Information Without Arbitration

Perhaps the most damaging failure mode is what happens when retrieved documents disagree. A KB article written for v3.2 recommends one approach. A resolved ticket from v4.0 followed a different path. An internal note warns against the approach in the KB article for certain configurations.

In a single-pipeline RAG system, these sources are concatenated into the model’s context window and the Language Model is left to sort it out. Often it hedges, producing a response that tries to reconcile contradictions and ends up being too vague to act on. Occasionally it confidently picks the wrong one.

An expert engineer would recognize these conflicts and apply judgment: which source is most relevant given the customer’s specific product version and configuration? Which has the higher credibility? Which is more recent? A single-pass retrieval-and-generation pipeline has no mechanism for this kind of arbitration.

The Architectural Gap

These failure modes share a common root cause. RAG treats troubleshooting as an information retrieval problem, but troubleshooting is fundamentally a multi-source reasoning problem. The answer to a complex support case is rarely contained in any one document. It must be assembled from different knowledge types, weighted across several dimensions including relevance, reliability, and coverage, with conflicts explicitly resolved rather than glossed over.

There is also a pattern problem that cuts across all five failure modes. If 40 past cases all resolved the same class of problem with slightly different descriptions, RAG retrieves the top few by match score and misses the pattern they collectively represent. The most reliable troubleshooting signals often lives in the across many imperfect matches, not in any single well-matched result. It desperately needs a mechanism to detect these patterns or produce predictive signals from aggregate data: anticipated case complexity, likely resolution path, or resources needed.

At Kahuna, we recognize that RAG was one component but an insufficient architecture, and built our troubleshooting platform around a multi-agent approach that addresses these gaps directly.

In a companion post, The Excruciating Need for an Ensemble of Agents, we describe how that architecture works in detail. RAG is a useful idea, but an incomplete one. Every hard case that RAG cannot reach means a longer resolution cycle, another frustrated customer, and another senior engineer spending time rediscovering what the organization already knew. For the cases that matter most, incomplete is not good enough.

By John Ragsdale, SVP Marketing, Kahuna Labs

Every support leader will acknowledge the same issue: cases are not well documented.

Despite clear guidelines, quality reviews, and ongoing coaching, most support tickets still fail to capture everything that actually happened during the troubleshooting process. This is not a new problem, nor is it one that organizations have ignored. In fact, many have invested significant time and effort attempting to improve documentation quality. Yet the problem persists.

The reason is simple. It is not a discipline issue. It is a structural one.

Where Troubleshooting Actually Happens

A support ticket rarely reflects the full reality of how an issue was diagnosed and resolved.

In practice, troubleshooting extends well beyond what is recorded in the case management system. Engineers collaborate in Slack channels, conduct Zoom calls and remote sessions, analyze logs in backend systems, and often rely on real-time experimentation within the customer’s environment. Critical decisions are made dynamically, based on experience, context, and evolving signals.

What ultimately gets captured in the ticket is typically a partial summary. It may include references to actions taken—such as collecting logs or scheduling a call—but often lacks the detailed narrative of what was discovered, why certain steps were taken, and how those decisions led to resolution.

From an organizational perspective, this creates a fundamental problem. The knowledge exists, but it is not captured in a form that can be reused.

Why Case Completeness Matters

Case documentation is not simply an administrative requirement. It is the foundation of institutional knowledge within a support organization.

When similar issues arise, engineers rely on historical cases to guide their approach. A well-documented case can provide insight into which questions to ask, which diagnostics to run, and which signals are most relevant in narrowing down the problem space. It can significantly accelerate time to resolution.

However, when key steps are missing, each new case becomes a largely independent exercise. Engineers are forced to reconstruct the diagnostic process from scratch, even when similar issues have been encountered before. This leads to longer resolution times, duplicated effort, and inconsistent outcomes.

More importantly, it prevents organizations from scaling knowledge effectively. Instead of building a cumulative understanding of how problems are solved, knowledge remains fragmented and largely dependent on individual experience.

What the Data Shows

At Kahuna, we analyze historical support data as part of every proof of value engagement and generate a Data Quality Report. One of the key metrics we evaluate is the Completeness Score™, which measures how thoroughly a case documents the troubleshooting process.

Across millions of cases, the results are remarkably consistent. Only 15–20% of cases achieve a completeness score of 5 out of 5, indicating that they contain a fully documented, step-by-step resolution narrative. Nearly half of all cases score 3 out of 5 or lower, meaning they are missing critical elements required to understand how the issue was actually resolved.

These findings highlight a significant gap between how support knowledge is assumed to be captured and how it actually exists in practice.

Why Traditional Approaches Fall Short

Most organizations attempt to address this issue through process improvements. They introduce stricter documentation standards, implement quality review programs, and provide coaching to support engineers.

While these efforts are well intentioned, they do not address the underlying reality of how support work is performed. Engineers are primarily focused on resolving customer issues efficiently. Reconstructing every step of the troubleshooting process after the fact is time-consuming and often impractical, particularly in high-volume or high-pressure environments.

Additionally, retrospective quality reviews are inherently limited. They typically cover only a small percentage of cases, and when gaps are identified, the information required to fill them may no longer be readily available. As a result, documentation remains incomplete, and the problem persists.

From Individual Tickets to Reconstructed Knowledge

If individual cases cannot be relied upon as complete records, then knowledge cannot be built from any single ticket. It must be reconstructed across multiple cases.

This is where AI introduces a fundamentally different approach.

Rather than treating support tickets as complete sources of truth, Kahuna AI augments them by reconstructing the full troubleshooting process. This involves integrating information from multiple sources, including Zoom transcripts, Slack conversations, backend diagnostic activity, Jira tickets, knowledge articles, and relevant product documentation.

By assembling these elements, the system creates a comprehensive, step-by-step narrative of how each issue was actually diagnosed and resolved. This enriched dataset provides a far more accurate representation of real-world troubleshooting.

Replicating Tribal Knowledge

When augmented cases are analyzed collectively, patterns begin to emerge. Missing steps become visible, and the structure of effective troubleshooting can be identified.

What emerges is not simply a collection of documented fixes, but a representation of how experienced engineers think. It captures the sequence of decisions, the conditions under which specific actions are taken, and the signals that guide the diagnostic process.

This is often referred to as tribal knowledge—the implicit understanding that exists within experienced teams but is rarely documented in a structured way.

By reconstructing and analyzing this knowledge, Kahuna AI transforms it into a dynamic Troubleshooting Map™. This map provides dynamic contextual guidance to support engineers, helping them determine the next best action based on the specific conditions of the case.

Improving Completeness in Real Time

In addition to reconstructing historical knowledge, Kahuna AI also improves documentation quality moving forward.

The system calculates a Completeness Score™ in real time as engineers work on a case. When gaps are identified—such as missing details from a log analysis or an undocumented conversation—the system prompts the engineer to capture the necessary information before the case is closed.

Organizations can also establish minimum completeness thresholds, requiring that cases meet a defined standard before closure. This approach not only improves documentation quality but also ensures that new cases continuously enhance the underlying knowledge system.

A Shift in How Knowledge Is Defined

For many years, support organizations have treated the ticket as the system of record. However, tickets were never designed to fully capture the complexity of real-world troubleshooting.

They provide fragments of the process, but not the complete picture.

The implication is significant. Support knowledge does not reside in individual tickets. It emerges from patterns across them.

As technology environments become more complex and customer contexts more variable, the limitations of document-based knowledge systems become increasingly apparent. The future of support knowledge lies in systems that can reconstruct and interpret the full diagnostic process, rather than relying solely on static documentation.

Conclusion

Incomplete case documentation is not simply a quality issue. It is a structural limitation of how support knowledge has traditionally been captured.

Attempts to improve documentation through process alone have delivered limited results because they do not align with how support work actually happens.

The opportunity lies in a different approach: using AI to reconstruct the full troubleshooting process, capture implicit knowledge, and provide contextual guidance for future cases.

In doing so, support organizations can move beyond fragmented documentation and toward a more scalable, accurate, and actionable model of knowledge.

By Judith Platz, Field CCO, Kahuna Labs

“The knowledge base is dead.”

Not “evolving.”
Not “due for optimization.”

Dead.

And if that makes you uncomfortable, good, it should.

Because most support orgs are still pouring time, budget, and headcount into a model that’s actively slowing them down.

Let’s be honest about what’s really happening 

You’re producing more content than ever and resolving complex issues no faster.
That’s not a scaling problem. That’s a broken model.

We trained engineers to search… instead of think.
Real troubleshooting isn’t “find the right article.”
It’s: eliminate variables, test hypotheses, adapt in real time.

Your “single source of truth” is lying to you.
That beautifully written article?
It works for one version, one config, one moment in time.

Everything else? Edge cases.

Static knowledge has a half-life measured in hours.
But we still run it through weeks (or months) of reviews like it’s permanent infrastructure.

You’re ignoring your most valuable asset.
The real knowledge isn’t in your KB.
It’s buried in thousands of resolved cases you’re not leveraging.

Deflection became a vanity metric.
Congrats, you automated the easy stuff.
Now 80% of what’s left is complex… and your model wasn’t built for that.

AI on top of a broken process just breaks faster.
If your foundation is static documents, all you’ve done is speed up the wrong thing.

Here’s the uncomfortable truth:

• Support no longer has a content problem
• It’s a context + diagnosis problem

And the winners right now?

They’re not writing better articles.
They’re building systems that:

• Learn from every case
• Adapt in real time
• Deliver the next best action (not a link)

So before you greenlight another “knowledge base refresh” initiative…

Ask yourself:

Are we improving documentation…or actually improving resolution?

Because those are no longer the same thing.

Who’s ready to challenge this?

To dig deeper into this topic, view the OnDemand version of a recent webinar I did with John Ragsdale, as part of our “Frontline Unleashed” series. Here’s a link:

Frontline Unleashed: Death to the Knowledgebase

By Chaitanya Potluri, Co-Founder, Kahuna Labs, and Gurmeet Singh Manku, Co-Founder and Chief AI Officer, Kahuna Labs

A complex ticket arrives. The customer’s production environment is failing intermittently after a routine upgrade. On the surface it looks like a configuration issue, but the symptoms are ambiguous.

What makes this case hard is that the answer depends on the full context: the customer’s specific implementation, their environment, the patches they’ve applied, the product version they’re running, and the history of prior issues on this account.

The relevant knowledge is scattered across several places, for example:

• A knowledge base article covers similar symptoms but was written for an older product version.
• A resolved ticket from eight months ago followed a completely different diagnostic path and arrived at a fix that may or may not apply here.
• An internal note documents a compatibility edge case for this product line that was never published to the KB.
• Configuration-specific behavior that only surfaces under certain environmental conditions was discussed in an engineering thread but never shared.

The engineer finds the KB article in twenty minutes. The rest stays buried.

This plays out thousands of times a day across enterprise support organizations. Every instance means a longer resolution cycle, another frustrated customer, and another senior engineer spending time rediscovering what the organization already knew.

Troubleshooting Requires More Than “Search, Then Generate”

As enterprises have looked to AI for help with technical support, most have reached for RAG (Retrieval-Augmented Generation), the conventional approach for grounding language models in company data. The concept is straightforward: take a question, retrieve the most relevant documents, and feed them to a language model to generate an answer.

RAG was designed for scenarios where the question is clear and the answer lives in a well-written document. But in enterprise technical support for complex products, KB coverage is structurally thin. The combinatorial space of product versions, customer configurations, and deployment environments is too large to document comprehensively. Products evolve faster than documentation, engineers resolve cases and move on, and the knowledge accumulates in ticket histories and tribal memory. In cases where RAG has been force-fitted into technical product support, the results have been consistently disappointing. The cases that drive escalations, consume senior engineering time, and frustrate customers stubbornly remain out of reach. Enterprise troubleshooting demands something fundamentally different.

Support tickets are noisy, multi-turn conversations where the problem statement itself evolves as the engineer and customer exchange information. The initial description of “the system is slow” could point to a network issue, a misconfiguration, a version-specific bug, resource contention, or something entirely novel. A single retrieval pass commits to one interpretation of the problem before the problem is even fully understood.

Beyond the query problem, a standard RAG pipeline produces one ranked list of results. A compatibility note competes for the same retrieval slots as a past ticket and a KB article. The ranking is based on semantic similarity to the query, not on whether the source type is appropriate for the kind of problem being investigated. And when retrieved documents disagree, as they often do across product versions and customer configurations, the language model is left to reconcile contradictions on its own, frequently producing responses too vague to act on.

A Glimpse into How Experts Actually Solve Problems

When we watched a senior support engineer work through a hard case and we saw that patterns emerged. They do not follow a single retrieval path. They consult multiple knowledge sources, weigh them differently depending on the situation, and synthesize a recommendation that no single source contains on its own.

They often start with official product documentation to establish expected behavior, then check past cases to see how similar symptoms were resolved in practice. They know past cases are noisy and incomplete, but they also know those cases contain real-world signals that documentation often lacks. They might cross-reference a compatibility matrix to rule out a known conflict, or recall an informal pattern from experience where a cluster of similar issues pointed to a root cause that was never formally documented.

Each knowledge source has different structure, different reliability, and different relevance depending on the case at hand. The expert’s skill lies in knowing which sources to consult, how much to trust each one, and how to combine their insights into a coherent recommendation. This process can be studied, decomposed, and systematized.

How Multi-Agent Architecture Works

The architectural insight directly follows how experts operate. If troubleshooting requires reasoning across multiple knowledge sources with different characteristics, the system that automates it should be designed the same way.

A multi-agent architecture deploys a collection of specialized agents, each designed to extract troubleshooting guidance from a different type of knowledge, using techniques tuned to that knowledge type’s unique structure and noise profile. These agents work in parallel on the same problem. Each contributes its best recommendation along with a confidence signal that reflects how certain it is in its output.

A coordination layer evaluates these parallel recommendations, selects the highest-confidence outputs, resolves conflicts between them, and synthesizes a unified response that draws on multiple perspectives.

The key properties of this design matter in production:

• Modular. Each agent can be improved or replaced without disrupting the rest of the system.
• Debuggable. When a recommendation is wrong, the trace shows exactly which agent contributed it and the reasoning behind it.
• Extensible. When new knowledge sources become available, whether a new documentation set, a new class of historical data, or a new product line, a new agent can be added without re-architecting the core system.

Extensibility, however, introduces a real engineering risk: agent sprawl. Our philosophy, at Kahuna, is that every agent must earn its place. As each one requires dedicated engineering to build, evaluate, and maintain, adding surface area to the system, and technical debt.

Each agent needs a justification grounded in two questions: does the knowledge this agent handles have fundamentally different structure or noise characteristics from what others already cover, and what measurable fraction of problem scenarios will it address? This discipline is crucial to make sure the number of agents in the system reflects the true structure of the collective knowledge rather than it proliferating unchecked.

Learning from Traces of Past Troubleshooting and Expertise

One of the most valuable capabilities this architecture enables is learning from how experts have solved problems in the past. Resolved cases contain decision traces: the diagnostic paths engineers chose, the reasoning behind their steps, and the outcomes of those choices.

It is worth noting that these traces vary enormously in quality. Some tickets are thoroughly documented with clear reasoning and confirmed resolutions. Others are incomplete, outdated, or low-credibility because the customer never responded to confirm the fix, or because the workaround was applied under time pressure and never validated.

A case from two years ago on a deprecated version carries different weight than a well-documented resolution from last quarter on the current release.

A multi-agent architecture can assess the quality of these decision traces and weight them accordingly. Rather than treating all past cases as equally valid retrieval candidates, the system can evaluate credibility, completeness, and relevance before incorporating historical expertise into its recommendations. The result is that the accumulated judgment of an organization’s best engineers becomes a structured, quality-weighted asset rather than an unfiltered archive.

Implications for Support Organizations

The practical implications of this architecture center on the quality and trustworthiness of AI-generated recommendations:

• Measurable accuracy. Because each agent specializes and produces confidence signals, the overall system’s accuracy can be measured and improved at the level of individual agents. When a recommendation misses, the organization can identify where and why, and improve that specific agent rather than trying to tune a monolithic pipeline where failures are opaque.
• Independent calibration. If a particular knowledge type is producing lower-quality outputs for a class of cases, it can be adjusted without destabilizing the system’s performance on other case types.
• Transparent reasoning. Support engineers receiving AI-generated troubleshooting steps can see the reasoning behind them. This changes the dynamic from an opaque suggestion to a transparent recommendation that an engineer can evaluate, trust, and act on with confidence.
• Pluggable growth. New product lines, new documentation sources, and new types of historical data can each be onboarded by adding specialized agents rather than re-engineering the existing system. The architecture adapts to the complexity of the knowledge landscape rather than forcing that landscape into a single pipeline.

At Kahuna, we are building our platform around this multi-agent architecture because these properties are what it takes for AI to earn a real place in enterprise support. The quality of recommendations, the ability to trace and debug them, and the confidence that the system can be established and extended over time: these are the requirements that the prevailing single-pipeline approach cannot meet.

By John Ragsdale, SVP Marketing, Kahuna Labs

For the past two years, Kahuna AI has focused on helping support engineers solve the hardest, most complex issues faster. We built a Troubleshooting Map™ from real ticket journeys. We enabled structured diagnostics instead of guesswork. We focused on orchestration rather than reactive firefighting.

But along the way, we discovered something equally important.

A meaningful percentage of support volume never required a human engineer in the first place.

Our Data Quality Report, based on two years of historical ticket analysis, consistently shows that up to 25% of support cases are fully self-serviceable—meaning every required action was performed by the customer, and the support engineer only played a consultative role.

Yet those cases still enter the queue. They still consume time. They still create backlog.

Why?

Because traditional self-service tools were never designed to troubleshoot. They were designed to retrieve information.

Most of today’s “AI-powered” self-service solutions rely on RAG search. They synthesize help articles, surface documentation, and return links. That works reasonably well for answering questions. But resolving a technical issue—especially in a complex, configurable enterprise product—is not the same as answering a question.

Troubleshooting requires structure. It requires context. It requires asking the right next question based on the previous answer. It requires understanding which actions are customer-doable and which require an engineer. It requires continuously evaluating whether the issue is still self-serviceable.

Search alone cannot do that.

And that’s why deflection rates plateau.

What We Learned from Auto Resolve

We’ve already proven this internally with Auto Resolve.

When a ticket enters the system, Kahuna AI evaluates the issue against the product’s Troubleshooting Map™. If the forward-looking path shows that every required step can be performed by the customer, Kahuna AI takes ownership of the case.

It doesn’t simply send documentation. It runs the diagnostic journey.

It asks probing questions. It gathers required information. It recommends structured next steps. It collects inputs that an engineer would otherwise have to chase down. And if the issue evolves into something that is no longer self-serviceable, it routes the case transparently to the correct engineer.

No wandering. No blind escalation. No wasted Level 1 cycles collecting data that should have been gathered up front.

Auto Resolve demonstrated something critical: a significant portion of support volume doesn’t require human expertise—it requires disciplined execution of a known diagnostic path.

That insight led directly to Kai.

Introducing Kai: The AI Support Engineer

Kai brings the intelligence of Auto Resolve directly to your customers.

Instead of interacting with a chatbot that retrieves knowledge articles, your customers engage with an AI support engineer that understands your entire Troubleshooting Map™—the same intelligence that powers Kahuna Navigator and Auto Resolve.

Kai actively troubleshoots.

It asks multi-turn diagnostic questions in context. It evaluates the customer’s configuration, environment, product version, and history. It gathers structured inputs from your product backend using APIs and MCP servers. It determines whether the issue remains self-serviceable or requires escalation. And when human intervention is needed, it makes that transition explicit rather than letting the customer drift in frustration, or waste time researching a problem via self-service they can never solve on their own.

Kai also remembers every issue in your historical data where customers performed all the required steps themselves. That full universe of self-serviceable scenarios becomes live, contextual intelligence—not static documentation.

This is not another answer engine.

It is a structured diagnostic system delivered through a conversational interface.

Redefining What “Deflection” Means

For years, the industry has measured deflection by how many questions can be answered without creating a ticket.

We believe that definition is incomplete.

Deflection should be measured by how many issues are actually resolved without engineer involvement.

There is a meaningful difference between giving someone information and guiding them through resolution. The former reduces friction slightly. The latter eliminates work entirely.

Kai addresses the biggest failure mode of traditional self-service: customer misdirection. Instead of sending customers into a maze of links and hoping they follow the correct path, Kai continuously evaluates:

• Is this issue still self-serviceable?
• Do I have enough diagnostic confidence?
• Should a human be brought in now?

Kai is self-aware of its confidence level and defaults to a human when appropriate. That transparency protects the customer experience and prevents the trust erosion that can happen when automation overreaches.

The result is not just incremental improvement.

It is a higher ceiling on deflection, lower repetitive ticket volume, and more capacity for engineers to focus on genuinely complex issues—the problems that truly require human judgment.

Why This Matters Now

Until now, much of our messaging has focused on solving complex tickets faster—and that remains a core strength of Kahuna AI.

But solving complexity is only half the equation.

The other half is eliminating the work that never should have reached an engineer in the first place.

As AI capabilities mature, customers will expect more than search. They will expect diagnosis. They will expect guided resolution. They will expect support systems that understand context—configuration, environment, telemetry, version—not just keywords.

Kai is the next evolution of Kahuna’s platform and the first step toward a future where AI is embedded directly into the product experience, providing proactive and reactive guidance as customers navigate your software.

Not just answering questions.

Driving outcomes.

The Bottom Line

Up to 25% of your historical support cases were already self-serviceable. Traditional chatbots cannot capture that opportunity because they were never designed to execute diagnostic journeys.

Kai can.

This is not about marginal improvements in search accuracy. It is about redefining what autonomous support actually looks like.

For more information about Kai and how it can transform your self-service strategy, contact us at info@kahunalabs.ai.

By Judith Platz, Field CCO, Kahuna Labs

For the last decade, support organizations have been telling themselves the same story:

“If we just answer faster, deflect more, and close tickets cheaper, we’ll win.”

That story is tired. And worse, it’s misleading.

Not because speed, efficiency, and automation don’t matter. They do. But because in 2026, they no longer differentiate. Everyone can automate the obvious. Everyone can deflect the easy work. Everyone can shave seconds off response times.

What separates average support teams from elite ones is no longer how fast they respond, it’s how intelligently they operate under complexity.

As we head into 2026, support organizations face a stark reality:

They will either be overwhelmed by rising complexity
or
They will become one of the most strategic capabilities in the enterprise.

There is no middle ground.

Here are my Six in ’26 predictions for where support is headed and why the shift is already underway.

Prediction #1: Tickets Stop Being the Unit of Work

In 2026, high-performing support organizations will stop managing work through tickets.

Tickets are artifacts, not the work itself.

The real work of modern support is:

• Understanding customer context
• Diagnosing across products, configurations, and environments
• Coordinating expertise and action
• Making high-confidence decisions under pressure

The ticket is just the container. The work happens elsewhere.

In 2026, the true unit of work becomes the decision flow, not the ticket.

AI systems will assemble context before a human ever engages:

• Product state and versioning
• Customer journey and history
• Configuration and telemetry
• Prior resolution paths
• Known risks and confidence levels

Support engineers won’t start from zero.  They’ll start mid-decision.

Implication:
Organizations still running support through queues, handoffs, and SLA dashboards will move materially slower than competitors operating with orchestration layers designed around decisions, not tickets.

Prediction #2: The Support Engineer Role Splits in Two

The traditional Tier 1 / Tier 2 / Tier 3 model collapses under modern complexity.

In its place, support engineering bifurcates into two distinct roles:

Orchestrators

• Navigate systems, AI insights, and decision paths
• Manage ambiguity and customer trust
• Decide when automation applies and when it doesn’t
• Act as force multipliers, not task executors

Exception Experts

• Deep domain and product specialists
• Handle truly novel, high-risk, high-impact cases
• Feed learnings back into the orchestration layer

This is not de-skilling. It’s value migration.

Most engineers move up the value chain away from repetitive diagnostics and toward judgment, coordination, and system-level thinking.

Implication:
Hiring shifts away from pure technical depth toward judgment, systems thinking, and orchestration capability. Teams that keep hiring for yesterday’s role will struggle to scale.

Prediction #3: Knowledge Bases Die; Intelligence Systems Replace Them

Static knowledge articles cannot keep pace with:

• Rapid product velocity
• Massive configuration variance
• Customer-specific environments

In 2026, knowledge is no longer:

• Document-based
• Generic
• Manually curated

Instead, knowledge becomes:

• Path-based, not article-based
• Contextual, not one-size-fits-all
• Continuously learned, not updated quarterly

AI systems observe how problems are actually solved in the real world and then cluster, optimize, and standardize those paths.

The most valuable knowledge is no longer what to do.

It’s when, why, and under what conditions to do it.

Implication:
Organizations still asking SMEs to “write more docs” will lose institutional knowledge faster than they can capture it.

Prediction #4: Escalations Become a Design Smell

In 2026, frequent escalations won’t signal unavoidable complexity.

They’ll signal poor orchestration.

High-performing teams will treat escalations the way engineering teams treat defects:

• Why wasn’t this path recognized earlier?
• Why wasn’t the right expertise surfaced?
• Why did the customer have to repeat themselves?
• Why did confidence degrade?

AI enables early detection of escalation patterns, long before customers feel the pain.

Escalations don’t disappear. But they become intentional, rare, and high-value, not the default.

Implication:
Support leaders will no longer be praised for “handling escalations well.”
They’ll be evaluated on how effectively they design escalations out of the system.

Prediction #5: Support Metrics Finally Grow Up

By 2026, serious organizations abandon vanity metrics.

Instead of obsessing over:

• Tickets closed
• Average handle time
• First response SLA

They’ll focus on metrics that reflect real business impact:

• Time to first meaningful action
• Decision confidence at each step
• Escalation avoidance rate
• Customer effort in complex cases
• Impact on renewals, expansion, and product quality

Support leaders will sit at revenue and product tables with data that actually changes decisions.

Implication:
If your metrics don’t map to business outcomes, your function won’t be treated as strategic…no matter how efficient it is.

Prediction #6: Support Becomes the Most Honest Signal in the Company

Support already knows:

• Which features don’t work in the real world
• Where customers struggle to adopt
• Which configurations are fragile
• Where product intent breaks down in practice

In 2026, winning organizations will:

• Treat support data as strategic intelligence
• Feed insights directly into product, success, and GTM
• Use support as an early warning system for churn and expansion

Support becomes the sensor network of the enterprise by detecting issues before they surface in revenue or retention metrics.

Implication:
Companies that ignore support insights will continue to be surprised by churn, dissatisfaction, and competitive losses even when the signals were there all along.

The Real Choice Ahead

The future of support isn’t about replacing people with AI.

It’s about:

• Replacing chaos with orchestration
• Replacing tribal knowledge with intelligence
• Replacing reaction with intent

By 2026, the gap between average and elite support organizations will be enormous.

One group will still be closing tickets.
The other will be quietly winning customers for life.

That’s the decade-defining shift now underway.

By John Ragsdale, SVP Marketing, Kahuna Labs

For the past few years, many B2B support organizations have found themselves in a holding pattern with AI.

They invested early. They piloted chatbots, summarization tools, routing automation. The results were… fine. Some incremental gains. Some lessons learned. But not enough to justify bold follow-on investment. And certainly not enough to inspire confidence when asking for more budget.

So they paused.

Meanwhile, a smaller set of organizations quietly kept going — not by adding more AI tools, but by rethinking what AI should actually change. They shifted focus from productivity gains to decision-making, from automation experiments to system redesign.

As we move into 2026, the distance between these two groups is becoming impossible to ignore.

This is not a story of “AI haves and have-nots.” Most companies have AI. The real divide is between organizations that are redesigning support around AI — and those that are still trying to bolt AI onto yesterday’s operating model.

That gap is about to widen.

1. AI Becomes a Competitive Weapon — Not a Tool

For years, AI in support was framed as an efficiency project: deflect a few tickets, shorten response times, reduce cost at the margins. That framing is no longer sufficient.

In 2026, AI increasingly becomes a source of competitive advantage.

Support organizations that restart their AI efforts with a focus on decision-making and scale will consistently out-execute peers who stalled after early pilots failed to deliver strategic value. Over time, this advantage compounds. Better decisions lead to better outcomes. Better outcomes generate better data. Better data further improves AI performance.

The result won’t be dramatic or sudden. It will be subtle — and relentless. Quarter after quarter, pacesetters will resolve issues faster, prevent escalations earlier, and protect customer confidence in ways others simply can’t replicate.

2. Support Emerges as the Most Leverageable AI Surface in the Enterprise

Among all enterprise functions, technical support is uniquely suited for advanced AI adoption.

It combines high interaction volume, rich historical data, clear success and failure signals, and immediate business consequences when things go wrong. Every support case represents a sequence of decisions: what to ask, what to collect, what to try next, when to escalate.

In 2026, leading organizations will increasingly focus AI investment here — not because support is simple, but because it is dense with repeatable decision patterns.

Most support work follows known paths. When AI can reliably execute those paths, the remaining work is no longer “more tickets.” It is true exceptions: novel failures, ambiguous environments, and high-stakes customer moments.

This is where the support engineer role fundamentally changes — from primary troubleshooter to orchestrator of an autonomous system, overseeing flows, intervening when confidence is low, and applying human judgment where it truly matters.

3. Context Becomes the Defining Advantage — Driving In-Network AI Adoption

One of the clearest lessons from first-generation AI efforts is that context matters more than models.

Generic AI, loosely connected to enterprise systems, struggles with the realities of complex B2B support: unique configurations, versions, integrations, telemetry, and customer history. Without context, even accurate answers feel wrong — or risky.

In 2026, more organizations will deploy AI inside their own networks, close to their data and systems of record. This allows AI to reason with full situational awareness — making decisions that are not just plausible, but appropriate.

Orchestration only works when AI understands the environment in which it is operating. Without context, automation stalls and humans are forced back into every step. With it, AI can act confidently on known paths and escalate only when uncertainty truly exists.

4. Support Becomes a Strategic Input to Product — or a Missed Opportunity

Support has always known where products break, where customers struggle, and which issues threaten adoption. What changes in 2026 is the ability to systematically surface and operationalize that insight.

AI can aggregate patterns across thousands of cases to identify recurring friction points, configuration risks, version-specific failures, and adoption blockers that no single team could see in isolation.

Organizations that recognize support as a strategic intelligence function will move faster on product improvements, reduce future support demand, and improve customer outcomes. When AI handles the repeatable work, support engineers finally have the time — and the signal — to shape product priorities instead of reacting to downstream failures.

Companies that ignore this input won’t just miss insights. They’ll continue investing in features while unknowingly shipping friction.

5. Decision Velocity Becomes the Engine of Frontline Productivity

For decades, support optimization has focused on productivity metrics like tickets closed, handle time, and response SLAs. Those measures still matter — but on their own, they don’t explain why customers lose confidence or why teams stall under complexity.

In 2026, leading organizations focus on decision velocity: how quickly the system identifies the right next step and moves work forward with confidence.

When decisions happen faster — and with greater clarity — productivity follows naturally. Backlogs shrink, escalations drop, and engineers spend less time navigating uncertainty and more time resolving real problems.

Decision velocity doesn’t replace productivity. It’s how productivity finally scales in complex environments.

A Final Thought

The most important change in 2026 won’t be which AI tools companies buy.

It will be whether leaders are willing to rethink support as a system — one designed for autonomy, context, and exception handling — or whether they continue optimizing workflows that assume humans must touch everything.

The technology is ready.
The data already exists.

What’s increasingly scarce is the organizational courage to start over.

Those who do will move faster than their competitors expect.
Those who don’t may not realize how far behind they’ve fallen — until the gap is no longer bridgeable.

By Hitesh Sharma, VP of Engineering, Kahuna Labs, and Chaitanya Potluri, Co-Founder, Kahuna Labs

Kahuna Labs just completed a Proof of Value (PoV) to assess the Kahuna Platform’s potential impact on technical support cases for a recent customer. The goal was straightforward: provide AI recommendations that support engineers (and customers) actually find useful.

Methodology & Feedback

We trained Kahuna AI on two years of historical data to build a Troubleshooting Map™. The system was refined through “friendly feedback” sessions with the customer’s support SMEs. These sessions enabled customer-specific tuning, ensuring the AI recommendations aligned with and benefited from the customer’s internal best practices and domain knowledge.

Customer Profile

• Multi-product global leader in a specific class of infrastructure products
• ~3,500 customers globally
• Support team: 250 engineers across three tiers
• Cost per case: $120–$500
• Documentation: ~30–40K documents, ~80% believed to be stale (specific documents are difficult to identify)
• Existing state:
  • Case deflection maximized using chatbots and self-service
  • Homegrown advanced AI-based knowledge search tool in place

Limited Scope

The PoV was limited to a single product line and trained only on past cases and centrally maintained troubleshooting documents.

Excluded from training:

• Case attachments
• Zoom call transcripts (32% of cases had Zoom calls)
• Microsoft Teams conversations
• Jira tickets
• Fragmented troubleshooting documents maintained locally by Support Engineers

These data gaps will be addressed prior to a production rollout.

Product in scope for PoV: Infrastructure product with both on-prem and cloud deployments. Case volume for the product in scope: 1,900 cases per month.

Data Quality

As part of the PoV, we first evaluated the quality of historical case data. Key findings by Kahuna AI:

• 52% of cases had a Completeness Score™ of 3, 4, or 5; the rest lacked meaningful documented steps
• 26% of cases had more than one grammar or spelling error in outbound customer communications
• 21% of outbound messages showed minimal or no empathy
• 15% of customer messages had moderate-to-high negative sentiment
• 32% of cases required Zoom calls
• 20% of outbound messages contained customer-sensitive information
• In 25% of cases, every troubleshooting step was performed by the customer; these cases were fully self-serviceable and could have been deflected using multi-turn troubleshooting driven by the Troubleshooting Map

Evaluation

After training, the customer selected a representative set of cases that Kahuna had not seen before, at various stages of troubleshooting and asked Kahuna AI to generate next-step recommendations.

Findings:

• ~70% of Kahuna recommendations matched the Support Engineer’s eventual actions (fully or partially)
  • Low confidence recommendations would be suppressed in production
  • Expected accuracy is significantly higher after ingesting Zoom transcripts (~32% of cases), case attachments, and enabling reinforcement learning in production
• 25% self-service potential: One-quarter of cases were identified as candidates for Kahuna Auto-Resolve, requiring no support engineer involvement
  • For remaining cases, the customer observed potential for left-shift from L3 to L2 and L2 to L1
• Faster diagnostics: AI reduced manual back-and-forth for diagnostic data collection
  • Zoom call predictions were highly accurate and could eliminate 3–4 message exchanges for ~32% of cases
  • Meaningful first responses enabled contextual probing questions before case assignment
• Quality communication: Suggested responses improved professionalism and empathy while reducing engineer time spent drafting emails

Conclusion

The readout demonstrated that Kahuna can materially improve support operations for this customer by providing troubleshooting recommendations based on a comprehensive Troubleshooting Map. The PoV showed potential to reduce resolution time, increase self-service, enable support tier left-shift, and improve consistency and quality of customer communications.