We built an AI assistant for a product-based CRM software company, and it lives inside the client’s existing software. Their users, already logged in, open a chat with no separate login, ask about their own business data in everyday words, and get a written answer plus a results table. It respects the access limits the client’s software sends it, only reads data and never changes it, and runs as a lightweight self-hosted service that the client’s software calls.
This write-up is for software companies and teams that already have a product with users and data, and want to know what an AI assistant inside that product involves. It describes what was delivered in plain words. It does not include usage numbers, results or timelines, because none have been approved for publication, and we would rather say so than invent one. For the wider picture, see our AI development services and our write-up on AI chatbot development, which includes this project.
What the assistant does
- Inside their existing software. The assistant sits within the client’s product. Their users, already logged in, open a chat with no separate login.
- Plain-language questions. Users ask about their own business data in everyday words and get a written answer plus a results table.
- Each user sees only their own permitted data. The assistant respects the access limits the client’s software sends it, and it only reads the data, never changes it.
- Remembers the conversation. It keeps track of earlier questions and asks a clarifying question when a request is ambiguous.
- Your choice of AI provider. It works with the AI provider the client chooses, not locked to one model, and runs as a lightweight self-hosted service that the client’s software calls.
How a question travels
- 1. AskA logged-in user types a question about their own business data, in everyday words.
- 2. Check and readThe assistant respects the access limits the client’s software sends it, and only reads the data.
- 3. AnswerThe user gets a written answer plus a results table, and can follow up in the same conversation.
Illustrative diagram of the flow, not a screenshot of the product.
Why these choices matter
Each point above is a design decision, and each one answers a question that software buyers ask before they trust an AI assistant with real data.
- Inside the product, not beside it. Users stay where they already work and do not need another login.
- Read-only. The assistant answers questions about the data. It does not change it.
- Access limits come from your software. Your product usually already knows who each user is and what they may see, so it can send those limits with each request.
- No lock-in to one model. The client chooses the AI provider.
- A clarifying question beats a wrong answer. When a request is ambiguous, the assistant asks.
What we are not claiming
We have not published the client’s name, usage numbers, results or delivery dates for this project, and we do not describe its internals here. What you see above is the set of capabilities we are comfortable describing in public. On a call we can talk through the approach in more depth and tell you what we can and cannot share.
What this means for your project
If you own a product that holds customer data and you are thinking about an assistant inside it, settle these points first. They shape the scope far more than the choice of AI model:
- Where it lives. Inside your existing screens, with your users already logged in, or as a separate tool.
- What it may read. Which data the assistant can see, and whether it should only read or also act.
- Who sees what. How your software will tell the assistant each user’s access limits on every request.
- Which AI provider. Whether you want to choose, and change, the provider rather than be tied to one model.
- How it answers. A written answer, a table of results, or both, and how it should behave when a question is ambiguous.
- Where it runs. A lightweight service that you host and your software calls, or something else.
The assistant described here is one kind of project. If you want a customer-facing chatbot, a WhatsApp bot or a tool that connects several systems, the scope looks different. Our AI development page covers the range, and our AI chatbot development cost guide explains what drives the budget.
Plan an AI assistant for your software
Tell us about your product, the data your users ask about and who may see what. We will reply with a written scope that shows what is included and what is not. Client name withheld; on a call we can talk through the approach and what we can and cannot share.
Questions buyers ask
Can an AI assistant be added to software we already have?
Yes, that is what this project did. The assistant sits inside the existing product, so users who are already logged in open a chat with no separate login. What it takes for your software depends on your data, your access rules and how your product can call it, and we confirm that in a scoping call.
Can the assistant change our data?
In this project it only reads the data and never changes it. For your project, whether an assistant may read only or also act is a scoping decision, and we would put it in the written scope.
How does it make sure users only see their own data?
In this project the assistant respects the access limits that the client software sends it, so each user sees only their own permitted data. Your product usually already knows who each user is, so it is the right place to decide what they may see.
Which AI provider does it use?
In this project it works with the AI provider the client chooses, and it is not locked to one model. For your project we would discuss the provider with you in the scoping call.