“Chatbot” has become a catch-all term for almost anything with an input field. It covers everything from a script with three canned answers to a language model that writes away with no connection to the organisation at all.
What we build for our clients is something else. Three decisions make the difference – the third is the unusual one.
1. A team of specialists instead of one brain for everything
The obvious design is a single AI that does everything at once: listen, understand the request, look things up, ask follow-up questions, document the outcome. That works in a demo. In production it gets brittle, because every additional job makes the instructions longer and the answers vaguer. Anyone who has tried to teach a language model to do everything right across two pages of prompt knows the effect.
Instead we use several specialised agents, each responsible for one area of work and coordinated by a layer above them. Every agent has a narrow brief, manageable instructions and clearly bounded access.
The gain is not only quality but maintainability: when the advice on one topic needs sharpening, one agent changes – not the behaviour of the whole system. It is the same reason software gets cut into modules.
2. Your organisation’s knowledge instead of general knowledge
A language model knows a remarkable amount, and knows nothing about precisely the things that matter: your funding conditions, your advisory handbook, the rule that changed last year.
So we build a dedicated knowledge base – from FAQs, guidelines, advisory material and whatever else sits in folders and in people’s heads. The agents draw on it and answer from the organisation’s own documents rather than from general language knowledge.
This has a side effect that is often underrated: what is not in the knowledge base is something the assistant cannot claim either. A well-kept knowledge base is therefore also the most effective defence against invented answers – and it belongs to the organisation, not to the model provider.
3. The form emerges from the conversation
The usual sequence: you talk to the bot, and at the end a rigid form appears that is the same for everyone. Which means fields nobody cares about in this particular case, and no space for the one detail that actually mattered.
We turn that around. The assistant builds the form during the conversation, to fit what was discussed, including field logic and validation. Someone asking about funding advice gets different fields from someone with a question about membership administration.
This is the technically hardest part, and not because of the fields but because of the validation. A form that can be invented freely produces data nobody can evaluate afterwards. The craft lies in giving the assistant room in choosing fields while keeping it on a short leash on formats, required values and plausibility. What comes out at the end has to fit the systems already in place.
What this means for non-profits
Three things that show up in daily work:
- Fewer drop-offs. People are more likely to complete a form when it is short and obviously related to their request.
- Better data. Details already clarified in the conversation do not need typing again – and so cannot be mistyped again.
- Relief in the right place. The assistant answers the same opening question every time. The cases that genuinely need advice reach people already prepared.
When you do not need any of this
The honest counter-reckoning: this setup does not always pay off.
If you have twenty recurring questions and little else, a well-maintained FAQ page is quicker to build, cheaper to run and often nicer for visitors. If there are no documents a knowledge base could draw on, tidying up is the first step – not the assistant. And if nobody processes the collected data afterwards, even the best form solves no problem.
We would rather say so beforehand than afterwards. The question is never “AI or not”, but whether the effort gives back more than it costs at this particular point.