Software and SaaS grow through the number of their users, and with every new user the number of questions grows too: how do I set this up, where is the setting, why does the import not work, how do I change my invoice? At first the team answers such questions on the side. But what works at a hundred users becomes a constant strain at a thousand, and support grows faster than the product. This is exactly where an AI chat assistant helps that sits directly inside the product: it answers onboarding questions and how-tos from your own documentation, catches recurring support cases before they become tickets, and hands the few complex cases to your team with full context. That self-service has become the first port of call is shown by a broad study: around 70 percent (Gartner) of customers use a self-service channel at some point on their resolution journey. The catch: only 14 percent (Gartner) of issues are also fully resolved there. This article shows how an individually trained assistant closes that gap and scales along with user growth, rather than letting the support effort scale instead.
Why Self-Service Often Fails at the Gap
Self-service promises a lot: users solve their issue themselves, instantly and without a queue, and the team is relieved. In practice, though, a gap opens between aspiration and outcome. Even for issues users themselves rate as very simple, only 36 percent (Gartner) are fully resolved in self-service. The most common reason is both banal and expensive: in 43 percent (Gartner) of cases, users simply cannot find content that fits their specific problem. The answer is in the documentation, but not where they look, or not in the words the user uses. Those who do not find it switch channels, open a ticket or drop off, and the intended self-service turns into extra work.
Classic help centres and static FAQs assume that the user finds the right page and transfers the answer to their situation. Standard chatbots with rigid decision trees rarely help here: around 75 percent (Forrester) of consumers say chatbots cannot handle more complex questions, and more than half find it difficult to find a solution through a chatbot at all (Forrester). An AI assistant that is bound to your own documentation and knowledge base works differently: it understands the question in the user's language, finds the right place in your content and phrases an answer to exactly that case, instead of pointing to a list of search results. What a robust knowledge base looks like is described on the knowledge base page.
Briefly explained: onboarding, deflection and escalation
Answer Onboarding Questions Inside the Product
A new user's decisive questions do not arise on the marketing website but in the middle of the product, at the moment of first setup. Those who get stuck on the first import, when creating the first project or setting up SSO quickly lose momentum, and it is exactly this early momentum that often decides whether a trial turns into a paying user. An assistant that sits directly in the application answers these questions where they arise: without switching to a separate help centre, without searching, without waiting. It knows the steps from your documentation and guides the user through the setup instead of pointing to a docs article they would have to assemble themselves.
The value stands or falls on the assistant answering only from your own sources. An assistant that makes things up does more harm than good in onboarding, because a wrong instruction costs trust. That is why an in-product assistant is bound to your documentation, your help articles and your product logic and says openly when it does not know something, instead of guessing. How to safeguard this technically is shown in the article on preventing hallucinations via a knowledge base. The embedding itself happens with a short snippet in your application, as described in the article on embedding the assistant in your website and product.
Faster to first success
The assistant guides new users through setup and first steps, without switching to a separate help centre.
Answer from the docs
How-tos and settings it answers directly from your documentation, in the language of the given question.
In the flow of use
Because it sits in the product, it helps in the moment of need instead of pulling the user out of their workflow.
Catch Recurring Support Cases
A large share of the support volume in software and SaaS consists of the same questions in ever new wording: reset password, invite users, change permissions, start an export, download an invoice. These cases are rarely difficult, but in sum they tie up a considerable part of the team's time, and in practice (from our own projects) it is exactly these recurring questions that make up the largest part of the volume. An assistant that reliably answers them from the documentation catches them before they become tickets. How much routine can be shifted this way is shown by a Gartner forecast: by 2029, agentic AI is expected to resolve around 80 percent (Gartner) of common service issues without human intervention and to cut operational costs in service by about 30 percent (Gartner).
Even where a human stays involved, an assistant changes the picture. In a service organisation with around 5,000 staff studied by McKinsey, the number of issues resolved per hour rose by 14 percent (McKinsey) with generative AI, while handling time per issue fell by 9 percent (McKinsey) and the cases in which a manager was requested dropped by 25 percent (McKinsey). Notably, the effect was largest among less experienced staff, because the assistant provides knowledge that would otherwise only grow over time. For a growing SaaS team that continually onboards new support staff, that is precisely a lever.
- Account and access: reset password, invite users, adjust permissions
- Setup: connect integrations, configure SSO, create an API key
- Billing: download invoice, change payment method, compare plans
- Usage: start import and export, filter data, generate reports
- Product knowledge: which feature solves which problem, where is which setting
Not every question is suited to automation, and the assistant should not force an answer at any price. The scope of features with which it captures, answers and, when needed, forwards support requests is described on the support assistant page; how a team is noticeably relieved by it without closing the human channel is shown in the article on easing support with a 24/7 assistant.
Hand Complex Cases Over With Context
As much as an assistant catches, its limits are just as clear. A suspected bug, an individual billing problem, a data loss or a security-relevant question belong to a human, and promptly at that. What matters is how this handover happens. An assistant that merely shows a contact form at every hurdle only shifts the work. A good assistant hands over with context: it summarises what the user tried and which steps were already taken, and passes along the details relevant to the case. That people expect a human contact for real problems is well documented: 62 percent (Bitkom) want to turn to a human when they have a problem. The assistant does not contradict that; it prepares this contact.
In software and SaaS in particular, context is more than the previous conversation. It is useful which plan the user is on, how long the account has existed, which feature is affected and which error message last appeared. Through clearly permitted, read-only actions the assistant can add such details, so that a complete picture reaches the team instead of a cascade of follow-up questions. When a handover makes sense and how it succeeds cleanly is covered in the article on when the assistant should hand over to humans; which actions the assistant may perform in a controlled way is set out on the tool control page.
A good assistant is not measured by how many cases it closes on its own, but by how cleanly it hands over the one case that needs a human.
Scale With User Growth
The real reason an in-product assistant is interesting for SaaS lies in how it scales. Support effort normally grows linearly with the number of users: twice as many users, roughly twice as many requests, so more staff. An assistant that catches a growing share of the routine decouples the two to a good extent, so the user base can grow without support growing at the same pace. McKinsey puts the potential clearly: in individual industries the share of human-serviced contacts could be reduced by up to 50 percent (McKinsey). At the same time, around 75 percent (McKinsey) of the economic potential of generative AI concentrates in a few functions, among which customer service is one of the most immediate.
That software itself is increasingly becoming the carrier of such assistants is emerging in the market forecasts: Gartner expects that by 2028 around 33 percent (Gartner) of enterprise applications will include agentic AI, up from less than 1 percent (Gartner) in 2024. For a SaaS provider this means an integrated assistant is moving from a special case to an expectation. So that it grows with the product, it can be extended with product-specific capabilities, as described on the custom functions page, and from the guided conversations the team continually learns which onboarding hurdles and support topics recur, made visible through conversation analytics.
From cost centre to data asset
Assistant, Docs or Ticketing System?
An assistant replaces neither your documentation nor your ticketing system; it connects both and closes the gap between them. Well-kept documentation remains the source of truth from which the assistant draws. A ticketing system remains the place where complex cases are handled. The assistant sits in front: it answers what the docs allow, in the language of the question, and only creates a ticket when a human is needed. For providers with an international user base, the same assistant answers questions in several languages from the same sources, as the article on the multilingual assistant for international customers shows. The following comparison places the three routes side by side.
| Aspect | Static docs / ticketing system | In-product AI assistant |
|---|---|---|
| Answer to a specific question | User searches and transfers it | Phrased in the language of the question |
| Onboarding | Article to read up on | Guided in the moment of need |
| Recurring cases | A new ticket every time | Caught before the ticket |
| Availability | Ticket waits to be handled | Around the clock in the product |
| Complex cases | Land unfiltered in the queue | Handed over with context |
| Scaling | Effort grows with the user count | Routine decoupled from growth |
Set It Up Right for Software and SaaS
An assistant that genuinely helps in the product does not come from a generic chatbot on the home page, but from three deliberate decisions. First, the knowledge binding: the assistant answers from your documentation, your help articles and your product logic, not from general world knowledge. Second, the actions: through clearly permitted, controlled functions it can add context in a read-only way or trigger simple steps, as described in the article on function calling and tool control. Third, the limits: what the assistant should not decide, it escalates. The technical embedding into your application happens via a lean snippet, explained under integration.
Because a support chat regularly touches personal data, data protection is not an add-on but part of the basic setup. XICBOT processes this data on servers in Germany, on the basis of a data processing agreement and with a clear deletion policy, as the page on data protection and hosting explains. How such an assistant is tailored specifically for software providers is bundled on the assistant for software and SaaS page; an overview of further fields of use is given on the industries page. And where a SaaS product has a self-checkout for subscriptions, the same conversation logic applies there too, for example when the assistant helps to recover abandoned checkouts in chat.
Limits and an Honest Approach
Part of being honest is naming the limits openly. An assistant does not solve every case, and it should not. It can err, which is why it is bound to your sources, shows its uncertainty and hands over sensitive cases. The market, too, calls for sobriety: Gartner expects that more than 40 percent (Gartner) of projects around agentic AI will be cancelled by the end of 2027, mostly where they started without clear value, without a sound data basis and without realistic expectations. The flip side is encouraging: projects with a clearly defined purpose, a well-kept knowledge base and clean escalation are less likely to belong to that group. How an individually trained assistant differs from a standard chatbot is set out in the article on a custom assistant versus a standard chatbot.
The direction is nevertheless clear. Gartner expects self-service and live chat to overtake the classic channels as the leading service technologies by 2027. For software and SaaS providers, the assistant in the product is therefore less a question of whether than of how: well scoped, bound to your own content and with clean handover to humans. Which package fits the scope of your product and your user base is set out on the pricing page.
- Answer onboarding questions and how-tos directly in the product, in the moment of need
- Bind answers strictly to documentation and knowledge base instead of phrasing freely
- Catch recurring support cases before they become tickets
- Hand complex cases to the team with plan, account and history as context
- Learn from the conversations which onboarding hurdles and topics recur
- Design in data protection with hosting in Germany and a clear deletion policy from the start
- Start with a clearly defined purpose and extend the assistant along with the product
Sources and Studies