What chatbot features should an AI assistant in SaaS have?

01Why an assistant inside your product is different

Most lists of chatbot features were written for a website widget that answers visitors. That bot knows almost nothing about the person asking and can do very little harm. An assistant inside a B2B SaaS product is the opposite. It sits behind a login, it knows which account, role and record the user is looking at, and it may be able to change data that customers rely on.

That changes what "good" means. Natural language understanding is now table stakes: every serious model handles misspellings and loose phrasing. The features that decide whether your customers trust the assistant are the ones that tie it to your product: what data it may read, what it may do, how it shows where an answer came from, and what happens when it is wrong.

So the useful question for a product leader is not "how smart is the bot." It is "what does this assistant know about our product, and what is it allowed to touch."

02The chatbot features that matter inside a product

These are the features we would insist on before an assistant reaches paying customers, in roughly the order we build them.

1. 01

   Answers grounded in your own content and data.

   The assistant retrieves from your help center, documentation and the records the user can see, instead of answering from the model's general knowledge. This is retrieval-augmented generation, and it is the difference between a product answer and a plausible guess.

2. 02

   Citations on every factual answer.

   Each answer points to the article, document or record it came from, so the user can check it in one click and support can see why the assistant said what it said.

3. 03

   The user's own permissions and tenant boundaries.

   The assistant can only see and do what the signed-in user could see and do in the interface. Nothing more, ever, and enforced by the product, not by instructions in a prompt.

4. 04

   Context from the screen and the record.

   The assistant knows which page, account or record the user is on, so people do not have to explain their situation before getting help.

5. 05

   Actions through defined tools, with approval.

   When the assistant does more than answer, it calls typed product functions, and a person approves anything with real consequences before it happens.

6. 06

   A clean handoff to a person.

   When the assistant cannot answer, or should not, the user reaches support or the right team with the conversation attached, instead of starting again.

7. 07

   Admin controls per customer.

   Account admins can switch the assistant on or off, choose which content it uses and see what it has done for their users.

8. 08

   Logging, evaluation and measurement.

   Every answer and action is logged, scored against known correct cases and reviewed, so you can tell whether a change made the assistant better or worse.

Notice what is missing: avatars, a clever name, channels you do not already support. Multilingual answers and other channels are worth adding when your users need them, but they do not make an assistant trustworthy. The eight features above do.

03Permissions, approval and prompt injection

The highest-risk part of an in-product assistant is not the model saying something odd. It is the model doing something the user was not allowed to do, or being steered by text it read.

The OWASP Top 10 for large language model applications puts prompt injection first. OWASP separates direct prompt injection, where the user's own input changes the model's behavior, from indirect prompt injection, where the instructions arrive through outside content the model reads, such as a website or a file. An assistant that reads support tickets, uploaded documents or customer notes is exposed to the second kind every day. OWASP's mitigations include restricting the model's access to the minimum it needs, human-in-the-loop controls for privileged operations, and clearly separating untrusted content.

OWASP's entry on excessive agency is even more direct about design. It traces the problem to excessive functionality, excessive permissions and excessive autonomy. It recommends limiting the tools an agent can call, giving each tool least privilege, running actions in the context of the specific user, requiring a person to approve high-impact actions. It also recommends implementing authorization in downstream systems rather than relying on the model to decide.

In practice that means the assistant never holds a master key. Every retrieval and every action goes through the same permission checks your application already uses, under the identity of the person asking. We go deeper on why this matters once assistants start acting in why AI agents fail in production.

04Citations and grounding

Citations do two jobs. For the user, they turn "trust me" into "check here." For your team, they make every wrong answer traceable to a source that was missing, stale or misread.

Model providers now support this directly. Anthropic's documentation describes a citations feature that returns the exact passages supporting each claim, so answers can be verified and sources shown to users. Compared with simply prompting the model to cite its sources, Anthropic says the feature guarantees that citations contain valid pointers to the provided documents. In its evaluations, the feature was significantly more likely to cite the most relevant quotes. Whichever model you run, the principle holds: build citations into the response format, not into a polite request in the prompt.

Grounding also sets a rule for the hard cases. When retrieval finds nothing relevant, the right answer is "I could not find this" plus a handoff, not a confident paragraph.

05How to test each feature before launch

Each feature should come with a test you can run before customers see it.

If a row cannot be tested, the feature is not finished.

06What we see in production

Our view is simple: your AI strategy should not end with a chatbot. We think about assistants as three product patterns that build on each other: "Ask your product", "Let your product act" and "Keep humans in control". The assistant is the first step, and the features above are what let it grow into the other two safely.

The work behind that view looks like this. On a self-hosted document workspace, we built extraction, citation-backed retrieval and AI writing as a self-hosted product. On a property field-operations platform, the assistance is role-aware and multilingual, alongside maintenance communication and mobile task coordination. On a white-label dealership sales assistant, conversations are grounded in live inventory, dealership and financing knowledge, and connected to lead capture, CRM and appointments, so the assistant hands real work to real systems. On an investment administration platform, admins, investors and sub-clients each have separated access, and the AI-assisted onboarding, due diligence and document work sits inside those boundaries.

What these have in common is that the hard part was never the model. It was the context, the permissions, the tools and the checks around it. For the cost side, see how much production AI costs in SaaS. For the move from answering to acting, see how to add AI agents to an existing SaaS product without rebuilding it.

Frequently asked questions