Every company with physical products knows that product support is high-stakes work. A leaking dishwasher, a blinking air fryer, or a home security system that isn't connecting can cause real damage and leave customers in difficult or dangerous situations. And unlike a billing question or a return request, there is rarely one right answer. It depends on what's actually happening in front of the customer.
The scale makes it harder. A single brand might support hundreds of SKUs across multiple markets, and the same question from two different customers can require completely different answers depending on the product model, firmware version, or how it was configured at install. Beyond the immediate safety risks, the business costs of getting it wrong add up fast.
Most companies dealing with this have tried one of three approaches: running support through human agents, deploying a general-purpose chatbot, or building something in-house. Each one has a real logic behind it, but none were designed for what product support actually requires. This blog looks at why.
Approach 1: Manual support operations
Manual support operations (human agents handling inbound tickets) is still the most common approach. Customers call in or submit a request, and an agent picks it up. It is the most straightforward model, and for a long time, it was the only viable one.
Manual operations work until volume outpaces the team. Hiring and training can't scale as fast as a product portfolio grows, and the economics reflect that: $2,000–$3,000 per agent per month plus BPO fees, scaling directly with every new SKU, every firmware update, every seasonal spike. For lower-margin products and long-tail catalogs, the math never works at all. The cost to serve exceeds what the product can absorb. And the agents hired to handle the volume burn out on the repetitive requests that make up most of it, making retention as much of a problem as recruitment.
To the customer, the symptoms are familiar. Long hold times, repeated explanations, being handed off between agents who lack context. Both sides pay the cost of a model that was never built to scale.
Approach 2: The general chatbot
General-purpose chatbots, whether standalone or embedded in a CRM platform, share the same underlying architecture: they search indexed content and retrieve the most plausible match. For simple, predictable queries like order status or return policies, that works well. The customer gets an answer and no ticket is created.
But Product support is different. When a customer's device won't connect or a crane on a construction site stops responding mid-operation, there is no single answer waiting to be retrieved. In these cases, the path to a solution depends on context, like how the product is behaving or what happens after each diagnostic step. Retrieval-based systems may return a match, but they weren't designed to follow a problem as it unfolds.
Neither was the troubleshooting tree – the scripted, branching logic that routes a customer through a pre-authored sequence of questions. Here, the path is fixed before the conversation starts, which means it can only handle failures the author anticipated. A product portfolio spanning regional configurations, installation variables, and years of model variants produces far more failure combinations than any tree can map. And when the customer’s situation falls outside the branches (which, in product support, it often does), the tree has nowhere left to go.
Retrieval-based or scripted, the chatbot is not built to handle an open diagnostic process. The deeper problem is that it’s usually text-based and depends on the customer being able to describe what's wrong in a format the system can act on, and research suggests only 10% can. Voice features can help with articulation, but when the fix requires a visual step like identifying a part or checking a connection, voice alone can't carry it. Without a visual handoff, it's still just a troubleshooting tree.
When a chatbot reaches the edge of what it can handle, the impact on the customer is clear: the bot returns something plausible, the customer follows the wrong advice, and is left with an unsolved problem and a poor experience. For some, that's the last interaction they have with the brand. Yet many chatbots would report that last interaction as a success. The metric is “containment”: whether the customer escalated or not. Containment says nothing about whether the problem was actually resolved. A customer who calls back with the same issue, or gives up and requests a return, counts as contained. The repeat contacts, the unnecessary returns, and the eroded loyalty are invisible to that metric. They instead show up in churn, and in support costs that compound with every unresolved interaction.
The chatbot logs a containment. The business absorbs the rest, and so does the customer. As Derek Carder, COO of Frontpoint, put it after moving from a general-purpose support tool to a purpose-built one: "Customers don't want to chat, they want to solve."
Approach 3: Building an in-house solution
The case for building a support solution in-house usually starts with a sound premise: no one knows our products better than we do. And with the excitement of a shiny demo and the promise of lower costs, the decision to build often follows. But what gets underestimated is the gap between product knowledge and product knowledge modeling, and the full infrastructure required to support it.
What a demo rarely shows is everything underneath: multi-turn conversation design, escalation flows, multilingual support, LLM orchestration with fallbacks, retrieval pipeline, governance, analytics, and scaling knowledge ingestion across complex documentation. That's the unglamorous work, and the reason most in-house builds stall before they ever launch. In fact, the last 20% of an in-house build takes longer than the first 80%, while the final 5% often never ships (source).
The infrastructure gap is only part of the problem. Even a well-built in-house system using LLMs and RAG still runs into the same limitation as retrieval-based architectures: it surfaces information, but it doesn't diagnose. Understanding what's actually failing and what resolution path applies to a specific customer requires diagnostic logic built on deeply modeled product knowledge, and most teams have no real sense of what that modeling actually involves.
What many point to as product knowledge (documentation, manuals, knowledge bases) is the starting point, not the model. For the AI to diagnose, it needs to understand how failures present across product variants and firmware versions, and how to connect a specific customer's symptom to the right resolution path. That level of structure is what turns product knowledge into something the AI can reason from, and it doesn't exist in raw documentation. That kind of modeling can take years to develop, and it's precisely the kind of work that gets missed in the planning phase.
An in-house solution typically runs $300–500K a year to build and operate, with a 12–18 month lead time to first resolution (assuming it launches at all). What that estimate rarely accounts for is the ongoing cost of keeping it current: new product lines, firmware updates, and the iteration required to reach competitive resolution rates. Research consistently shows that 60–70% of the total cost of software accrues after launch. As Roja Buck phrased it:
“Development is the down payment. Maintenance is the mortgage.”
The alternative: Purpose-built AI
Resolving a product issue is a diagnostic problem. The AI designed to solve it must be able to reason about what's actually failing and where, and guide the customer through resolution. That’s a different job from retrieving information or routing calls, and it requires a specific architecture.
That's the problem Mavenoid was built to solve. Trained on millions of real product support interactions across thousands of brands, the platform combines diagnostic logic with deep product knowledge modeling. Customers get resolution through whichever channel fits the moment, and when a fix requires showing rather than telling, visual guidance is part of that.
With Mavenoid, Ecobee flipped their support ratio from 75% human-handled to 75% AI-resolved in three years, effectively adding the capacity of 80 full time agents. PetSafe achieved 350% self-service growth and $2.6M in FTE cost savings. Across the platform, customers typically see a 2.7X ROI and a 76% self-service resolution rate – a leading benchmark for manufacturers.
