The answer your site shows and the one that will reply to a message are the same row

What a customer asks before buying gets answered today in three different places: the site, the direct message and the phone. And each place has its own version. The site’s is out of date, the message’s depends on who is on shift, and nobody knows which one is right.

The knowledge base goes into the system and comes out through the API. The answer published on the site and the one that will reply to a message are the same row. It gets corrected once and changes in both places — which is the whole argument for having a single layer, applied to the smallest thing there is.

The articles are distilled from real support conversations, not from what somebody assumes gets asked. The difference shows in the phrasing: people do not write “how do I book a table?”, they write “how much do you have to spend to get a table”. Those literal phrases feed the internal search and are never published: they carry personal context from whoever wrote them, and the public type does not have a single field to put them in.

Two more rules, which are design and not good intentions:

• An article with an unresolved variable does not get published. A page showing {{phone}} is worse than a question that is missing.
• What escalates to a person is not content. Refunds, complaints and charges are conversation: publishing them as an automatic answer invites nobody to write, which is the opposite of what you want.

And a variable can deliberately be left with no value, with the reason written into the data itself. Without that state, the next person to look at the table sees a gap, fills it thinking they are fixing an oversight, and undoes a business decision.

It is the first piece of the Inbox, not the Inbox. The rest is missing: the channels, the inbox itself and the agent’s autonomy.