What you are going to ask
These questions come up in every project. They just do not come from the same person, and they rarely all reach the table before the decision is made. That is where projects run aground later.
Below they are set out, grouped by who asks them. Do you recognise five of them and have you had an answer to none of the five from your current supplier? That is a good moment to call.
Getting started
“What is besst.ai?”
besst.ai is the practice of Rinaldo Hassell, operating as AppTechWorks B.V. We build knowledge assistants on your own documents, with permissions that stay intact. In your own Azure tenant or fully offline on your own hardware.
“How do we start?”
With a conversation, and then with an exploration. In it we look at your documents, your permission structure and the questions your people actually ask. You get an assessment: where it breaks down for you, and whether a proof of concept is worth doing.
Board
“How does this differ from a general chatbot?”
A general chatbot knows a lot, and nothing about you. The difference is in what surrounds it: guidance through the choices, setup in your own environment, control over which documents go in, testing before it goes into use, management once it runs, and the context of your organisation. And the answer comes from your own documents, with the source attached, and only for those allowed to see it.
“What does this deliver, and when will we notice?”
The first thing you notice is that searching stops. Someone who now loses half an hour retrieving an earlier decision finds it in a minute, with the source attached. That is the first thing the proof of concept has to make visible. What comes after is harder to count and more important: answers become more consistent, because everyone draws on the same documents.
“What if we want something different in two years?”
Then you keep your documents, your permissions and your logs. The parts that age fastest have been kept replaceable in the design.
“Will we be dependent on you afterwards?”
No. It runs in your own environment, on your own documents, and the setup is delivered so that you can manage it yourself or have it managed.
“When will I know whether this works for us?”
At the end of phase 1. Not earlier, and not later either.
“Why do this now instead of waiting until our supplier delivers it?”
Sometimes waiting is the right choice. Weigh this: what a supplier delivers, he delivers to all his clients at once, therefore generically, and it works on his arrangement of permissions and not on yours. For a general knowledge base that is fine. For the moment when departments with different permissions have to draw on the same system, it is usually the problem.
“Why place this with a small firm rather than a large one?”
That is a fair question and the answer is not always in our favour. With a large firm you buy continuity and a contract. With us you buy that the person who designed it is also the person at the table. What you have to arrange in both cases is who maintains it once we are gone, and that is exactly why the setup is delivered transferable to your own team or your existing supplier. Transferable is not the same as transferred: appoint that person before you start.
Privacy and security
“Do we need a DPIA?”
Probably yes, and that is not a problem but work. We are not your legal adviser and we do not carry out the DPIA for you. What we deliver is the technical description your data protection officer needs: which data sits where, which operations are performed on it, and how access is partitioned. Start early. A DPIA that only begins at delivery is the most predictable delay in projects of this kind.
“Can I see who asked what?”
Yes. Questions, answers and consulted sources are logged by default, because without that you can establish nothing after the fact and cannot demonstrate that the permission separation held. How long you retain them and who may inspect them is your choice and belongs in your own policy. Note that the logging itself contains personal data and therefore falls under the same DPIA.
“Does our data have to go to the cloud?”
No. The same assistant also runs fully offline, without internet, on your own hardware.
“Does this also work without Microsoft?”
Yes. The offline variant uses open-weight models on your own hardware and needs no cloud subscription. There the setup uses no cloud services and no Microsoft products.
“Can this run on-premise?”
Yes. The offline variant runs on your own hardware, without internet, with open-weight models. There the setup uses no cloud services and no Microsoft products.
Information management
“What if our documents are a mess?”
Then you are normal; at almost every organisation document management has fallen behind the growth in the number of documents. It is not a reason to wait, because nobody sustains tidying up without visible results. We start on the part that is good enough and make visible which mess is actually obstructing the answer.
“Will this be another island in our landscape?”
It runs in your own environment, on your own identities, on the documents where they already sit. We do not move your document management and we do not ask you to migrate. That is a design rule, not a concession.
“What if it is broken on Monday morning?”
Then the question is who is on call and within how much time it has to be restored. That is a maintenance agreement, not a technical question. We name no standard period for it, because it depends on what the assistant does for you: a knowledge base that is down for an hour is not the same as a system a service desk is waiting on. You decide what it has to be, we say what that costs and whether it is achievable. We make that agreement explicit before you go into production, because otherwise it lands with nobody by accident.
“What happens to a document we withdraw?”
It should disappear from the assistant along with it, and the period within which that happens is an agreement we record with you before anything goes into production. Ask this of every supplier you speak to.
“And what if it simply makes something up?”
Then you will see it, because a source is always attached and it opens with one click. You should not get an answer without a source, and that is one of the six measurement points before anything goes into production. That is not a guarantee that the model never goes wrong, it is the reason you notice before anyone acts on it.
“How do you solve that?”
We show that in your own environment, on your own documents. Not on a website.
Procurement
“What does it cost per year once it is running?”
The costs depend on where it runs. The offline variant has no consumption costs, but it does have hardware and maintenance. In the Azure variant the costs fall into three parts that move differently. Consumption in Azure, which moves with the number of questions and the size of your documents, and which we make measurable during the proof of concept so that production holds no surprise. Licences, which you probably already hold. And maintenance, which is a choice and not a given. We do not quote an annual figure before we know your scale, because any figure you get from anyone right now is a shot in the dark.
“And if it turns out not to work after the proof of concept?”
Then you stop, and the proof of concept has done exactly what it is for. You keep the outcome: which documents hold up, where your permissions are shaky, and what a next step would cost. That is value, even if nothing gets built.
“How does a public body actually procure this?”
Exploration, proof of concept and production are three separate assignments, each with its own result. You are free to stop after every phase. That usually fits within your own thresholds, and it is also the only honest moment to decide whether it works.
The shop floor
“Can a user see where an answer comes from?”
Yes. Every answer shows its source: the document and the page. One click opens the passage the answer rests on, so the user can read for themselves what it says.
“What happens if the answer is not known?”
Then the system says so, instead of inventing something. The user can then open the closest documents, forward the question to the responsible department, or report that knowledge is missing.
“Will my people have to work differently?”
As little as possible, and that is a design choice. The documents stay where they are. What is added is a place to ask a question. What disappears is the searching.
“Will this cost jobs?”
We do not determine that, you do. What changes is that time is freed up in retrieval and in answering the same question repeatedly. What you do with that time is an administrative choice and not a technical consequence, and it is wise to state that choice before your people fill it in themselves. Left unstated, it does not go unnoticed.
“What if my people simply do not use it?”
This is the question that is most often right and least often asked. A system that works technically and goes unused is the biggest risk of projects of this kind. What helps: start with a group that has a concrete problem, not with the group that finds it most convenient. Choose a type of question that recurs often and genuinely costs time now. Always show the source, because trust comes from the document and not from the answer. And measure usage from day one, so that you know whether it is fading before it has already faded. What does not help: a broad rollout with an instruction afternoon.
“What happens if I call?”
No proposal and no presentation. We ask which of these points pinches hardest for you and whether it can be solved within what you already have. Sometimes the answer is that you do not need us. We would rather hear that now than in three months.
Is your question not here? Then that is the question we want to hear.
Come and talk, and we will see where we get to.
Get in touch
“Can someone from social services reach HR documents through this thing?”+
No, and that is the first thing set up, not the last. Nor the source reference: no pointer to a document they may not open. An authorisation test is part of the delivery.