Policies & SOPs
Find the current process without asking around.
Enterprise Knowledge
Your knowledge. Within reach.
Make policies, SOPs, contracts and past work easier to use. Answers come with their sources, respect access permissions and say when the evidence is missing.
Signs this fits your business
You will recognise
at least two of these.
If none of them sound like your week, this is probably not the system you need — and we will say so.
New joiners take months to become useful, mostly because they do not know who to ask.
The same questions reach the same two experienced people, and the business quietly depends on them being available.
Policies and SOPs exist in three places, and nobody is sure which version is current.
Your team rewrites proposals from scratch because finding the approved wording takes longer than retyping it.
Some information is genuinely restricted, so a shared folder open to everyone is not an acceptable answer.
What this system does
Useful answers from the information you already own.
Your business already knows the answer to most questions your team asks each day. It is in a policy, a signed contract, an SOP written two years ago, or a proposal someone wrote for a similar client. The problem is finding it. This system answers questions from those sources, shows where each answer came from, and respects who may see what.
It takes on the searching. A question is checked against the sources the person asking is permitted to see, the relevant passages are found, and an answer is written with the citation attached, so the reader can open the original and judge it. Where the evidence is thin or contradictory, the system says so instead of filling the gap with something plausible.
What stays with people is authorship and ownership. Source owners still write the policy and approve the SOP; the system only makes their work reachable. When a question has no good answer, that gap is routed to the owner rather than left unanswered, so the knowledge base improves through use rather than through an annual clean-up nobody has time for.
A worked example
Two questions.
One honest refusal.
What a good answer looks like — and what the system does when the evidence is not there.
Asked by your team
Asked
What notice do we have to give Shakti before changing an order?
Answered
Seven working days for a quantity change, fourteen for a specification change.
Supplier Terms v4 · clause 6.2 · updated March 2026Asked
And the penalty if they deliver late?
No answer given
Nothing current covers this.
Every answer carries the clause it came from. Click the citation and you are looking at the source document, not a summary of it.
What the system did
Checked what this person is allowed to see before retrieving anything
Found the clause in Supplier Terms v4 · updated March 2026
Answered with the citation attached
Refused the second question.
Asked about the penalty for late delivery, it found nothing current — the only mention sits in a 2019 draft that was never signed. Rather than answer from it, the question goes to the owner of that document.
Waiting on a person
Meera, ProcurementOwner of Supplier Terms · asked to fill the gap
Add the clauseMark as N/AThe permission check
Runs before retrieval, not after. Someone without access never sees that the document exists.
The gap becomes work
Unanswered questions build a list of what your knowledge base is actually missing.
When a document changes
Answers that cited it are flagged, so nothing keeps quoting last year’s terms.
Illustrative example built to show the shape of the work. Not a client record.
Where it is used
Four shapes of
the same problem.
Most businesses start with one and add the second once the queue, the logging and the connections already exist.
Project knowledge
Reuse lessons, decisions and previous work.
Sales & proposals
Find approved product and commercial information.
Internal support
Help teams answer everyday questions from trusted sources.
How the work runs
Five steps.
One of them is yours.
Every stage is recorded, so nothing is silently dropped or done twice.
- 01
Ask
Someone asks a question where they already work: a chat tool, an internal page, a search box. We agree the channels first, because a system nobody passes on the way to work goes unused.
- 02
Check access
The question is answered only from sources that person is permitted to see. Permissions come from your existing access rules, and we test that restricted material stays restricted before launch.
- 03
Retrieve
The relevant passages are found across the permitted collections, with the current version preferred over the superseded one wherever versioning exists.
- 04
Answer
An answer is written with citations to the passages behind it. If the evidence is missing, weak or contradictory, that is stated plainly rather than smoothed over.
- 05
Improve
Unanswered questions and flagged contradictions go to the source owner. Their fixes update the sources, and the evaluation set grows with the questions that caught a problem.
Where a person decides
Source owners review gaps and changes. Unsupported answers are withheld.
The line is yours to draw, and we write it down before anything runs.
Source owners review gaps and changes, and unsupported answers are withheld. That is the rule the design rests on: an answer without evidence is not offered, because a confident wrong answer about a policy is worse than no answer at all. Owners decide what enters the sources, what is retired and how a contradiction is resolved. Readers can flag an answer, and a flagged answer becomes a case in the review queue rather than a complaint that disappears. Nothing is published to a wider audience on the strength of a system answer alone. Our guide on a named owner for AI systems explains why this role matters more than the technology.
What you receive
5 things, and
they are all yours.
Not a demo and a slide deck. A running system, the evidence it works, and the documentation to run it without us.
An answering system over your own sources
A place your team asks questions in plain language and gets answers drawn only from the material you approved, with the source named on every answer.
A source map with owners and permissions
A written record of which collections are included, who owns each one and who may see it. It is the document that makes access arguments short.
An evaluation set of real questions
Questions your team actually asks, with the answers your experts agree are correct. We test against it before launch and re-run it after every change to the sources.
A gap and review queue
Unanswered questions, stale documents and contradictions collected in one place and routed to the owner who can resolve them.
Logs, usage view and documentation
A record of questions asked and sources used, a simple view of adoption and unanswered rates, and notes for whoever maintains the system.
What we need from you
5 things, and none
of them technical.
You do not need a developer. You need someone who knows how the work really happens, including the exceptions nobody wrote down.
- 01
The collections you want included, and an honest note on which are current and which are stale.
- 02
Your access rules: who may see what, and which material must never appear in a general answer.
- 03
A named owner for each collection, able to resolve a gap or approve a correction.
- 04
A list of the questions your team really asks, including the ones that currently need an expert.
- 05
A baseline: how long finding an answer takes today, and how often it is simply asked of a colleague.
What it connects to
Built around what
you already run.
Every source is added deliberately, with its owner named and its access rules carried through, and restrictions are tested before anyone is given the system.
- Document storage and shared drives, where policies, SOPs and past work usually live
- Your intranet or wiki, when the current process is written there
- Contract and agreement stores, where the commercial detail sits
- Your CRM or project system, for past proposals, decisions and client history
- Email or chat archives, where they are in scope and the access rules allow it
- The chat or search tool your team already uses, so the answer arrives where the question was asked
How it is judged
5 numbers, taken
before we build.
We agree a baseline for how answers are found today, then compare the same measures after launch and at each review point.
01
Time to find an answer
against the time the same question takes now
02
Share of answers supported by a citation a reader can open
03
Unanswered question rate
and how quickly gaps are closed
04
Active adoption across the teams it was built for
05
Correct-answer rate on the evaluation set
re-run after changes
What drives the cost
No price here,
and here is why.
The honest answer depends on your work and your systems. Scope and fee are agreed in writing before paid work begins, and the first conversation costs nothing.
BYBO publishes no prices. What this costs depends on how many sources you include, what state they are in and how strict your access rules are, so scope and fee are agreed in writing before paid work begins. The first conversation costs nothing. Most engagements start with the Blueprint, a paid diagnostic ending in a recommendation and a 90-day roadmap.
The build is one cost; running it is another. Sources change, questions arrive, the evaluation set is re-run and someone reviews the gap queue. We set out both before you commit, and the cost guide explains the arithmetic in more detail.
Once
Design and build of the system
Every month
Running it, the review time it still needs, and monitoring
Before you enquire
6 questions we
are asked every time.
Answered plainly, including the ones with an uncomfortable answer.
Discuss this systemCan it make something up?
The design is intended to prevent it: answers are drawn from retrieved passages, citations are shown, and where evidence is missing the system says so and routes the gap to an owner. No system is perfect, which is why every answer carries the source. If a reader cannot check the answer, the answer has not done its job.
What happens when two documents contradict each other?
It should show both and say they disagree, rather than quietly choosing one. Where versioning exists, the current document is preferred and the superseded one marked. Persistent contradictions are logged for the source owner, because the real fix is in your documents rather than in the retrieval.
Do we need to organise everything first?
No, and we would rather you did not spend six months tidying before starting. We begin with the collections that answer the most common questions and note what is unusable. Documents that exist only as scans may need document handling before they can be searched properly, and the Blueprint identifies that early.
How do we know the answers are good enough?
By testing on questions your own experts have answered. We agree an evaluation set before launch, measure against it, and re-run it whenever sources or configuration change. That gives you a number you can argue with, rather than an impression formed from a few demonstrations.
What if our knowledge is mostly in people, not documents?
Then this is the wrong first step, and we will say so. A retrieval system can only reach what is written down. Where the useful knowledge sits with two or three experienced people, the honest recommendation is often to capture a small amount of it well before building anything.
What is the first step?
A conversation about the questions your team keeps asking and where the answers currently live. If it looks suitable, a Blueprint examines your sources, sets a baseline and ends with a recommendation and a 90-day roadmap. You can also start an enquiry describing your sources.
Read more on this
Before you commit
to anything.
How to Build an Internal Knowledge System Employees Can Trust
An internal knowledge system earns trust by showing its evidence, respecting the permissions people already have, keeping each source owned and current, and saying plainly when it does not know.
Read the article
AI for SOPs, Policies and Institutional Knowledge
Most institutional knowledge lives in a few people’s heads. AI can help turn it into procedures worth following, provided a person owns each document and approves every version.
Read the article
How to Evaluate AI Quality Using Real Business Cases
A demonstration proves a system can work once. An evaluation set built from your own cases, including the awkward ones and those where stopping is the right answer, tells you whether it works often enough to release.
Read the articleBring us the question
everyone asks one person.
We will tell you whether it is worth building — including when it is not.