Before creating an internal assistant, look at where work gets stuck
In many companies, the information exists, but turning it into a decision is hard.
There are documents, CRM records, old emails, spreadsheets, shared folders, Slack or Teams conversations, internal manuals, sales decks and Notion pages. There is also a less visible layer: the judgment some people have built up over the years.
When someone asks “how should we respond to this case?”, the answer rarely comes from one place. It may depend on an approved document, a commercial criterion, an operational exception, a person who knows the process well, or a tool where the real status is recorded.
An internal AI assistant can help when it makes that internal way of working visible.
Its value should not be measured only by its ability to retrieve information, but by whether it helps the team understand which source to check, which criterion to apply, who needs to be involved before closing the case and what step should come next.
That is why, before thinking about tools, models or integrations, I would start with a very operational question: where does knowledge get stuck inside the organization today?
A common scene: the case that ends up in Teams
Imagine a fairly normal sales request.
A client asks for a service the company offers, but with a specific adaptation, a tight budget and a deadline. The sales person needs to reply, but the information is spread across several places.
The sales deck explains the general offer. A past proposal shows a similar case. The CRM shows that this client had already contacted the company a few months ago. The operations team knows whether the adaptation is feasible. And there is an internal criterion, maybe written somewhere or maybe only discussed in meetings, about when this type of request is worth accepting.
In the end, the question lands in Teams:
“Can we offer this or not?”
To answer well, you need to reconstruct the full thread: what is still valid, what applies to this client, who knows the operational part and what should be recorded if the case moves forward.
When this happens once, it feels like a normal question. When it happens every week, the team starts depending too much on the same people. There is always someone who “knows how this works”. And whenever that person is busy, on holiday or answering from memory, the quality of the decision drops.
A well-designed internal assistant can reduce that dependency. It can gather the pieces, show where each one comes from and propose a first orientation without forcing the team to chase information across five different channels.
When it makes sense to create an internal assistant
I would see it as a good candidate when similar questions come up repeatedly and the answer needs to connect several sources.
For example: sales questions about which service fits each client, support questions about internal procedures, onboarding for new people, criteria for classifying opportunities, recurring administrative questions or cases where it is necessary to know which internal owner should review a decision.
There are three fairly clear signals.
The first is repetition. If the team asks variations of the same questions every week, there is probably a part of the knowledge that is not accessible enough.
The second is dispersion. If answering requires checking a tool, a document, a record and asking a person, the assistant can help connect the dots.
The third is the need for judgment. When the answer involves understanding what step should happen next, finding a data point is only one part of the work. That data has to be placed in context.
This is where AI can add value: by looking for information, connecting it with the question and turning it into an answer that is contextual enough for a person to act better.
Sources of truth: documents, people, processes and tools
When we talk about your own sources, it is easy to imagine a folder full of PDFs. But inside a company, a source of truth can take many forms.
It can be a current service sheet. An internal procedure. A CRM record. A knowledge base. A person responsible for a criterion. A tool where the real status is always more up to date than in any document. It can also be a process: the usual way the organization moves from a question to a decision.
This forces you to design the assistant differently.
When a question comes in, it is not enough to find which document contains a similar sentence. The assistant needs to understand which process is involved, which team owns it, which tool contains the current state and when the case should be escalated to a person.
In the sales request from the example, the assistant may need to check the service sheet, but also the type of client, the CRM history, the fit criterion and the team’s availability.
That is the difference between answering with text and helping orient a decision with the knowledge that is available.
Before building, some cases need a bit of order
There are situations where an internal assistant arrives too early.
If nobody knows which source is the right one, the assistant will work on a weak base. If each team applies different criteria, AI may simply make that inconsistency more visible. If sensitive information is mixed with general information, permissions and access need to be considered first. And if a process only exists informally, it is worth writing down the basic parts before asking a system to follow it.
You also do not need to wait for perfect documentation. That can stop the project for months.
What helps is narrowing the first case well.
Instead of starting with “the internal assistant for the whole company”, I would choose one specific situation. For example: “an assistant that helps the sales team understand which service fits each type of client and what next step they should propose”.
That scope lets you learn without opening too many fronts at once. It also makes the gaps visible quickly: sources that need updating, criteria that need writing down, permissions that need separating or decisions that still depend too much on one person.
A good answer should feel like a small internal route
In an internal environment, confidence without context can create problems.
There will be questions without a clear source. Documents that do not match. Old procedures. Cases that depend on an exception. Information that only a specific person can validate.
In those cases, the assistant should be able to show the doubt. A useful answer might sound like this:
“With the information available, this case seems to fit service X. The main source is the sales sheet updated in May. However, the adaptation requested by the client affects operations and I do not see any written criterion for this specific scenario. The recommended next step would be to run it by operations before sending the proposal.”
This answer does not try to hide uncertainty. It puts it on the table.
I would ask the assistant’s output to include four elements:
- what seems to be needed now;
- where the answer comes from and which knowledge points are involved;
- what remains pending, uncertain or not sufficiently supported;
- what the recommended next step is.
This structure turns an answer into a short work route. The person understands why the answer makes sense and what they should do with it.
When the assistant fails, pending work also appears
During a real pilot, the assistant will not answer everything well. And that can be very useful if it is recorded properly.
Imagine a two-week test with real questions from the team. Some answers will be useful. Others will be incomplete. A few will show that a clear source is missing or that criteria contradict each other.
Those incomplete answers can become a practical map of the knowledge that is missing.
A procedure may appear that only one person knows how to follow. A commercial policy everyone mentions in meetings but nobody has written down. Two versions of a document with different criteria. A CRM that contains the real status but is not connected to the internal documentation. Or a question the team asks every week that nobody had identified as a problem.
That learning makes it possible to prioritize concrete improvements: update a source, assign an owner, remove an old version, write down a missing criterion or define a process more clearly.
At this point, the assistant is no longer just an answering tool. It also helps reveal where the organization has knowledge that is broken, duplicated or too dependent on specific people.
How I would start with a small pilot
To start, I would choose an internal question that repeats often and consumes real time.
The best first case is usually one that can be observed easily: it appears every week, affects several people and has a clear impact on day-to-day work. It does not need to be the biggest or most visible one.
Some good candidates could be:
- sales questions about which service fits each client;
- support questions about internal procedures;
- onboarding for new people;
- criteria for classifying opportunities;
- recurring questions about administrative processes;
- finding internal owners for certain types of cases.
A two- or three-week pilot can already provide a lot of information if the scope is clear. For example: a small team, a short collection of reliable sources, real questions and a simple way to mark each answer as useful, incomplete or incorrect.
Measuring only whether “the AI answers” says very little. I would look at whether the team interrupts the same people less, whether it finds information sooner, whether answers lead to a clearer next step and whether gaps appear that were previously hidden.
A demo can make a good impression in five minutes. The important test comes when the team uses it in the middle of real work, with urgency, doubts and cases that do not fit perfectly.
The best signal is reduced dependency on informal memory
Back to the initial request: a sales person needs to answer a case with nuance. Service, adaptation, budget, deadlines, operational capacity and CRM record.
Without a help layer, the process can be slow: find the sales deck, review past proposals, check the CRM, ask operations and wait for someone to remember which criterion had been applied in similar cases.
With a well-designed assistant, the first answer can already organize the case: applicable offer, relevant history, known criterion, point still to clarify and recommended next step.
If this type of case already appears often in your team, it can fit into a pilots and implementation track before turning it into a larger bet.
The assistant does not decide for the team. It also does not remove the need to talk to people when that is what the case requires. But it reduces the fog.
And that shows up in very concrete situations: a new person who understands sooner what they need to do, a request that does not get blocked because someone is out of the office, or a decision that no longer depends only on informal memory.
Maybe this is the best starting point for deciding whether an internal assistant is worth creating: look at how many times a week someone has to write “can we offer this or not?” and wait for a specific person to have the answer in their head.