Skip to content
bonalogic
Back to projects
Live

Internal product

Support platform

What I went looking for did not exist, so I built it

A self-hosted support platform whose AI assistant answers only from its own knowledge base, and whose knowledge base grows from the questions it could not answer.

Open to Nolorem customers only, so there is no public tour. The screens on this page show it with demo data.

The support inbox: a list of tickets with status, priority and category on the left, and the open conversation on the right.

What it does

  • Answers with the source attached

    The assistant answers only from the knowledge base and points at the article it used. When nothing covers the question, it says so instead of guessing.

  • It knows the account

    It can see the customer's plan and their open tickets, and it drafts a ticket when one is needed. Nothing reaches the queue until the customer confirms.

  • Tickets arrive with context

    A ticket carries the context of the articles the customer already read, so nobody gets asked whether they checked the manual.

  • Every conversation on record

    Each assistant conversation is kept with its outcome and the customer's rating. I can see where it helps and where it hands over.

  • Gaps surface on their own

    Questions the assistant could not answer are grouped and counted, and each group becomes a draft article with one click.

  • On my own servers

    Screenshots, account details, descriptions of what broke: all of it stays on infrastructure I run, not with a helpdesk vendor.

Why it exists

Anyone paying for Nolorem deserves proper help the moment something breaks. Neither of the usual options appealed. A hosted helpdesk charges per agent per month and keeps your customer conversations on someone else's servers, which is an odd message from a platform that treats confidentiality as a starting point. A static documentation site answers yesterday's questions and cannot take a ticket.

What I actually wanted did not exist in a shape I liked: a knowledge base that catches the question before it becomes a ticket, with an assistant that answers only from my own documentation. So I built it, on the same infrastructure and the same principles as Nolorem.

An assistant that says it does not know is more use than one that always has an answer.

How a question travels

A customer with a problem starts in the assistant, not in a form. It searches the knowledge base, answers from the article it finds and links to it, so the customer can read the whole thing rather than trust a summary. When the knowledge base has nothing on the subject, the assistant says exactly that and offers to open a ticket. It never files one on its own: the customer confirms first, which keeps accidental escalations out of the queue.

The list of assistant conversations with their outcome, model and rating, and on the right a conversation where the assistant finds no article and offers to open a ticket.
Every assistant conversation, with its outcome. On the right, the assistant finds nothing and offers a ticket instead of making something up.

The ticket that does get filed carries the context of the articles the customer already worked through. On my side it lands in an inbox with filters by status, priority and category, and on a board that shows where each ticket stands, from triage to waiting on the customer. I start from what the customer already tried, which saves a round of questions on both sides.

The ticket board with columns from Unstaged and Triage through Investigating and In Progress to Waiting on User, each ticket showing its number, priority and customer.
The board. Each ticket moves from triage to done, and a glance shows what is stuck where.

How the knowledge base grows

Tickets are not only work, they are signals. A question the assistant had to escalate is a question the knowledge base did not answer, and when the same one keeps arriving, that should stand out rather than disappear into an archive. The platform groups those questions and counts them, so the gap that costs the most tickets sits at the top of the list.

The knowledge gaps screen, listing recurring questions the assistant escalated, each with a count and a button to draft an article.
The gaps the assistant ran into, counted. The question that came back five times gets written up first.

From a gap, one click opens a new article with the question already in the title. I write the answer, publish it, and the next customer with the same question gets it from the assistant straight away, without a ticket. That loop is what makes the system better over time, and it is also why the help improves exactly where it fell short rather than where someone guessed it might.

A new knowledge base article opened from a gap, with the question as its title and fields for summary, platform, category and language.
A gap becomes a draft article, with the customer's question as the starting point.
The list of knowledge base articles with their category, status, language and last update.
The knowledge base the assistant answers from, with the articles that are due for another pass marked as such.

Support conversations contain the most sensitive material a customer ever sends: screenshots, account details, descriptions of exactly what broke. All of it stays on infrastructure I control. That is not a feature I charge for, it is the default.

What I ran into

Search quality decides everything. A knowledge base nobody can search is a knowledge base nobody uses, and they file a ticket instead. Precisely the outcome the system exists to avoid. Getting search to match on intent rather than exact wording was the difference between working and decorative.

An assistant with tools needs boundaries. Once a model can look up and create tickets, prompt injection becomes a real risk rather than a theoretical one. Data arriving from outside is passed in delimited, the system prompt stays short, and actions with consequences require confirmation from the user.

Writing good articles is harder than building the platform. The software was the smaller half. An article that genuinely answers a question, instead of restating the interface, takes real effort, and no amount of engineering substitutes for it.

Why it is here

This is a small platform solving an unglamorous problem, and a fair illustration of the kind of work businesses most often actually need. Not a moonshot, but the thing that quietly removes a recurring cost. It also shows I take my own customers seriously: the cheap route was a subscription, with the conversations living somewhere else.