An assistant that shows its working
A chat assistant that answers business questions is only useful if you can check it. It should answer from your own systems and say where every number came from.

Photo from Unsplash.
Ask a manager what they want from an assistant and the answer is rarely clever. They want yesterday's sales without filing a request. They want to know who approves a refund. They want to know how to restart the card reader, and they want the answer in the chat app they already have open.
When we built the team assistant for a hospitality operator, those were the questions. Simple ones that went to a person, then waited in their inbox. The assistants live inside the team's messaging apps, read live sales straight from the point-of-sale systems, and answer from a knowledge base the office looks after.
Getting an answer was the easy part. Getting an answer people would act on was the work.
A number with no source is a rumor
Say an assistant tells a manager the downtown store did a certain number yesterday. The manager has two choices: believe it or check it. If there's no way to check it, a careful manager won't use it, and a careless one will repeat it in a meeting.
So every answer that involves data should show its working. Which system it read. Which stores, which dates, which definition of sales. For a number, the query itself, written so someone who knows the data can read it. It sits under the answer, out of the way, one tap to open.
Most people never open it. That's fine. The point is that they could, and that whoever looks after the numbers can check any answer in seconds. Trust comes from answers being checkable, not from them sounding sure of themselves.
Answer from your data, not from memory
General chat assistants learn from a huge pile of public text. They're good at sounding right. They don't know your stores, your prices or your refund policy, and when asked about them, some will produce something plausible anyway.
A business assistant should do the opposite. Read the number from the system that holds it. Answer policy questions from the documents you've written, and name the document. If the data isn't there, say so. “I can't see sales for that store after Tuesday” is a useful answer. A guess is not.
In practice that comes down to a few rules:
- Numbers come from a query against a live system, never from the model's own knowledge.
- Every answer names its source: the system or document, and the date range it covers.
- If the question is ambiguous, ask. “Yesterday” at 1 a.m. could mean two different days.
- If the source is stale or missing, the answer says so before it says anything else.
- Anything the assistant can't answer goes to a named person, not a dead end.
Give the office one place to run it
An assistant is only as good as what it's been taught. The team assistant has one portal where the office edits the knowledge base, handles approvals and sends broadcasts to staff. When a policy changes, someone updates one document, and the next answer reflects it.
Keep a log of questions and answers too. It shows you which answers are wrong, and which questions keep coming up that nobody has written down. The second list is often the more useful one, because it's a list of things your team needed and didn't have.
Some answers are better pushed than asked for. The team assistant sends a morning email digest of yesterday's sales, so the most common question is answered before anyone types it.
Where assistants don't belong
Not every question should go to an assistant. These are the places we'd keep one out:
- Anything where a wrong answer hurts someone: allergens, medical questions, safety procedures. Link to the source document instead of paraphrasing it.
- Decisions about a person: hiring, discipline, pay. An assistant can find the policy. It shouldn't apply it.
- Approving money. It can route a request to the right approver. A person should press the button.
- Talking to customers on your behalf about anything you'd be uncomfortable seeing quoted back to you.
- Questions your data can't answer. If no system records it, the assistant shouldn't pretend one does.
The pattern is the same in each case. Assistants are good at finding things and bad at being accountable for them. Use them for the first and keep a person on the second.
Before you set one up
Pick the ten questions your team asks most. For each one, write down where the right answer lives. If you can't, that's the first thing to fix, and no assistant will fix it for you.
If you can, build the assistant to answer those ten from those sources, and show the source every time. Add the eleventh question only when the first ten are right.