AI chat inside a SaaS app: what to decide first

An AI chat inside a SaaS app is an assistant that talks to the already logged-in customer, knows who they are, and answers from the product documentation. Before building it, decide four things: where it appears on the screen, how it confirms identity, what it can do in the account, and when it hands the conversation to a person.

The question became more urgent in 2026. A Gartner survey released on August 4, 2026, conducted with 3,566 B2B and B2C customers, shows that 58% of those who use generative AI in customer service have already asked it to complete a task, not just to answer. In B2B, the rate rises to 74%. Your SaaS customer expects the chat to solve things, and solving things touches their account.

Wama built ManyFeed, its own social proof SaaS, with AI, and starts from a simple reading: the chat inside the app is a product feature, not a widget stuck in the corner of the screen. What changes in the business when AI enters the software is in the text on building a SaaS with AI; here the subject is the conversation inside the logged-in area.

What is an AI chat inside a SaaS app?

It is an assistant that lives in the logged-in area and works with three inputs: who the user is, what the product documentation says, and, when you allow it, account data read through the API. That combination sets it apart from the public website chat, which talks to anonymous visitors and only knows what is on the pages.

The questions from inside the app are also different. Someone who already pays wants to know how to do a task, why they hit the plan limit, where the invoice is, or what an error means. A good answer depends on the account context, and that is where the in-app chat beats a generic assistant open in another browser tab.

The content part works like the knowledge base of an AI agent: help center, release notes, and the answers support repeats every week. If that documentation is thin or outdated, the chat inherits the flaw and still answers confidently, which is worse than not answering.

Where the chat sits on the screen and when it appears

The chat's position is a design decision, not a configuration setting. A floating button in the corner works for a one-off question, but it can cover the save button or the cookie notice on dense screens. A side panel works for someone who needs to read the answer while using the product. A dedicated help page works for long conversations, like setting up an integration.

Also define when it offers itself. A chat that pops up on the screen during the first visit competes for attention with SaaS onboarding; one that appears on the billing screen, near the plan limit, arrives right when the question arises.

In Wama's SaaS projects, design is the longest phase, and decisions like this one fit into it: the chat's position, the empty state, the error message, and a clear notice that the conversation is with an AI. The rest of the interface follows the same logic as UI and UX for SaaS, in which roles, permissions, and error screens are scope from the first prototype.

How does the chat know who the user is?

Through your product's server, never through the browser. The app can pass name, email, and plan to the chat, but that data proves nothing, because anyone can change what the browser sends. The safe path is for the server to issue a signature or a short-lived token, and for the chat service to verify it before treating the user as identified.

In a SaaS, identity has two layers: the person and the client company they belong to. The OWASP guide on vector and embedding weaknesses, revised in April 2025, warns about context leaking between users when several classes of users share the same vector database, and recommends strict logical and access partitioning of the data. In practice, client A's internal document can never show up in client B's search, even when the question is similar.

That isolation needs to be in the database and in the search, not in an instruction written for the model. When the conversation involves personal data, the duties described in the text on the LGPD (Brazil's data protection law) and artificial intelligence also apply, such as a defined purpose and using only the data that is needed.

What the assistant can do in the customer's account

Start with read-only. Checking plan usage, invoice status, user limits, or the status of an order already solves a good part of the questions and changes nothing in the account. Writing, canceling, switching plans, or deleting data is for a second phase, with confirmation from the user themselves on a product screen.

The OWASP guide on excessive agency, updated in May 2025, names the risk: functionality, permission, or autonomy beyond what the task requires. The recommendation is to run each action in the context of the user who asked, with the least privilege possible, and to leave authorization in the system that receives the call, instead of the model deciding whether the action is allowed. A high-impact action calls for human approval before it happens.

At Wama, every AI result goes through human reading before it reaches the client, and the same reasoning applies to the chat: anything with consequences goes through a person, whether it is the user confirming on screen or someone on the team. The phased design, from reading to limited writing, is in the text on CRM integration with AI.

When should the conversation go to a person?

Whenever the customer asks, when the assistant cannot find the answer in the documentation, and when the subject is a billing dispute, an error that blocks work, or a data deletion request. The same Gartner survey shows that 87% of customers consider it essential to have the option of talking to a human agent when the company uses generative AI in customer service.

Gartner analyst Eric Keller recommends not using generative AI as a mandatory step for every problem. When the customer goes through several failed attempts before reaching a person, they become less willing to use the tool again. AI helps most when it collects information, understands intent, and only tries to resolve when confidence is high.

At the handoff, the team member receives the history and the account data, so the customer does not have to repeat everything. If your SaaS serves consumers through an app in a regulated sector, the text on the SAC decree (Brazil's customer service rules) in the fintech app shows what changes when human support becomes an obligation.

Common mistakes

• Treating the chat as a form. A chat that only asks for the email so someone can reply later is a form with a different face, and the customer notices by the second message.

• Trusting what the browser says. Identifying the user by an email sent from the screen, with no server signature, exposes any customer's account to anyone who knows how to edit a request.

• A single knowledge base for all customers. Without partitioning by company, a well-crafted search returns another customer's document.

• Forgetting that content also carries instructions. The OWASP guide on prompt injection, updated in April 2025, describes indirect injection: the model reads a file or a page with hidden orders and obeys. In a SaaS, that includes what the customer uploads to the product.

• Enabling actions before reading. Starting with automatic cancellation, before proving the chat reads the account correctly, inverts the order of risk.

• Not reading the conversations. The first month's questions show what is missing from the documentation and how much each conversation costs, a breakdown detailed in the text on how much it costs to implement AI.

Frequently asked questions

What is the difference between the website chat and the in-app chat?

The website chat talks to anonymous visitors and answers about plans, features, and integrations based on the public pages. The in-app chat serves those already logged in, knows the person's company and plan, and can look up the account. That is why it calls for verified identity and permission rules that the website chat does not need.

Do I need my own AI model to have chat in my SaaS?

No. Most products use an off-the-shelf model, accessed via API, with a documentation search step before the answer. The work is in what surrounds it: the knowledge base, identity, permissions, handoff to a human, and the screen. Training your own model is rarely a SaaS's bottleneck.

Can the AI chat change data in the customer's account?

It can, but it should not start that way. The safest path is to enable read queries first, like plan usage and invoice status. Actions that change the account come later, with authorization checked on the server and confirmation from the user on a product screen, as the OWASP guide on excessive agency recommends.

How do you measure whether the in-app chat is working?

Track four numbers: conversations resolved without going to a person, checked by sampling; support tickets per active customer, before and after; reasons for handoff to a human; and satisfaction in the conversations that reached the team. The handoff reasons show what is missing in the documentation or in the API integration.

Who should design the chat inside the SaaS?

Whoever designs the rest of the product, because position on the screen, empty state, AI notice, and the path to an agent are interface decisions. At Wama, one person follows the project from brief to deploy. What weighs on a product's scope and timeline is in the text on SaaS development.

If your SaaS is going to get an AI chat, start with the screen and permission decisions, before choosing the tool. To design the product with these rules from the first prototype, talk to Wama.