We tell clients that responsible AI adoption starts with a defined business need, a grounded source of truth, and human oversight. Before recommending that approach to anyone else, we applied it to our own website.
The problem with the first version
Our original chat assistant ran on a fixed script: a narrow set of pre-written answers that covered only the questions we had anticipated when we built it. A visitor asking anything outside that script got a generic non-answer, and every new service, course, or page we published meant another round of manual script updates — a maintenance burden that only grows as the business does.
What we rebuilt
We replaced the fixed script with a knowledge base generated directly from the site's own published content: services, industries, the Academy catalog, case studies, and company facts. When we publish a new page, the assistant's knowledge updates with it, with no separate maintenance step.
On top of that grounded base, we added two capabilities that were not there before:
- Voice interaction, alongside the existing text chat.
- In-conversation lead capture, so a visitor who wants to talk to a person can do that without leaving the conversation.
The guardrails that matter more than the features
The part of this work we are most deliberate about is what the assistant is not allowed to do:
- It cannot state a price, rate, or fee for any service, course, or product — FaithForge does not publish pricing, and the assistant does not invent it.
- It cannot claim a course, template, or membership tier is available for purchase today if it is not.
- It cannot invent a team member, a client, a statistic, or a certification. If the knowledge base does not cover a question, it says so and offers to connect the visitor with our team.
That last rule is the one we think matters most for any organization adopting AI for a client-facing role: the system should know the edge of its own knowledge, and say so, rather than filling the gap with something that sounds plausible.
Why this is a FaithForge Academy story, not just an IT story
This project did not start as a software build. It started the way a PMO engagement starts: define the outcome, decide what "done" looks like, assign ownership, and build in a way someone else could maintain after we hand it off. The same governance discipline we install for clients applied here — we just happened to be the client.
If you're evaluating where to start with AI in your own organization, this is usually the honest answer: start with a defined, bounded use case, ground it in information you actually maintain, and decide upfront what it is not allowed to say. The technology is the easy part.