Editorial guide

The Best First Knowledge Project Is One Painful Issue, Not the Whole Company

Most company knowledge projects start too big.

Someone notices that support answers are inconsistent, onboarding handoffs depend on memory, macros are stale, and internal docs no longer match how the team actually works. The diagnosis is usually right. The next step is usually too vague: clean up all our docs, rebuild the knowledge base, organize the company wiki, or create a company brain.

That is how a real operating problem turns into a giant project nobody can finish.

The better first step is smaller: choose one recurring issue that keeps hurting the team, gather the artifacts around that issue, and turn them into one reviewed issue pack.

Not the whole company. One painful issue.

Why broad knowledge cleanup stalls

Broad cleanup projects sound responsible because the mess is real. The problem is that "all company knowledge" is not a workable first unit.

It has no obvious owner. It has no clear finish line. It includes stale docs, old tickets, half-true macros, Slack or Teams explanations, CRM notes, call transcripts, onboarding notes, and employee memory from every corner of the business. Every team can point to a problem. Nobody can review all of it quickly.

That creates the usual failure pattern:

leadership agrees the knowledge base is messy
someone opens a documentation project
the scope expands from one workflow to every workflow
reviewers are asked to validate too much at once
stale content gets moved instead of resolved
contradictions are hidden inside cleaner folders
the project slows down before the team gets one reusable operating output

This is not a discipline problem. It is a scoping problem.

If the first project is "organize everything," the team spends most of its energy defining the system. If the first project is one recurring issue, the team can judge whether the output is useful.

The first useful test is operational, not philosophical

The first question should not be, "Can we organize all company knowledge?"

The first question should be:

Can we turn one painful recurring issue into a reviewed pack the team would use this week?

That question is concrete enough to test.

Pick an issue like:

refund exceptions after onboarding delays
onboarding handoff confusion after sales closes a deal
account access loops after a domain or owner change
billing disputes involving partial credits
implementation blockers that keep escalating to the wrong owner
bug-report triage where Support is unsure when to involve Product
cancellation or renewal questions where the macro and policy disagree

Each of these is narrow enough for one support, customer success, onboarding, billing, or operations owner to review. Each has source material: tickets, macros, SOP fragments, internal notes, CRM fields, Slack or Teams exports, transcripts, and customer replies. Each can produce a usable output if the pattern is real.

That is the right first unit for an operational knowledge project.

A painful issue has evidence

The best first issue is not just annoying. It leaves a trail.

You should be able to find 10-20 redacted artifacts around it. Some can be clean and some can be messy. The point is not to prepare perfect documentation. The point is to collect enough evidence for a reviewer to see the real pattern.

Useful artifacts include:

resolved support tickets
support macros or saved replies
current SOPs, old SOP drafts, or help-center paragraphs
internal notes explaining exceptions
CRM notes that change the customer answer
Slack or Teams exports where the issue was discussed
call transcripts or onboarding notes
examples where the standard answer failed

Do not start with the entire helpdesk export. Do not start with every onboarding document. Do not start with a folder called "billing" or "support knowledge."

Start with a sentence specific enough that a reviewer can say yes or no:

Customers ask for refunds outside the normal window when onboarding was delayed, and Support is not sure when to escalate to Billing Ops.

That is a testable issue.

Why one reviewer matters

A broad knowledge project often fails because review responsibility is diffuse. Everyone agrees the docs should be better. Nobody owns the final answer.

For a first issue pack, choose one reviewer before the work starts.

The reviewer might be a Head of Support, Support Operations Manager, Customer Success Operations lead, onboarding owner, billing owner, COO, or founder. The title matters less than the authority to decide what becomes reusable guidance.

That reviewer should be able to approve, edit, reject, or mark outputs as needs edit. They should also be able to answer uncomfortable questions:

Is this SOP current?
Is this decision rule safe to reuse?
Does this macro create a customer promise we should not make?
Is this exception standard policy or a one-time judgment call?
Which source should win when the macro, ticket, and internal note disagree?
What gap needs a business decision before documentation can be trusted?

Human review is not a bureaucratic extra step. It is the trust layer.

Old tickets can contain outdated answers. Macros can drift. Internal notes can contradict policy. A polished summary is not enough if nobody can approve the rule behind it.

What a reviewed issue pack should produce

The output should be more useful than a cleaned folder or a chatbot answer.

For one recurring issue, a reviewed issue pack should include some or all of:

SOP draft: the step-by-step procedure for handling the issue.
Decision rules: when to approve, deny, escalate, request more context, or apply an exception.
Escalation rules: who owns the edge case and what evidence must travel with it.
Support macro drafts: reusable customer-facing language for the common branches.
Internal FAQ entries: answers the team needs but customers may not need to see.
Gaps: missing owners, missing account fields, unclear policies, or absent customer-facing articles.
Conflicts: places where tickets, macros, notes, or docs disagree.
Open questions: decisions the reviewer must make before the pack can be trusted.
Review state: what is approved, rejected, needs edit, or still draft.

The gap and conflict report is not a nice-to-have. It is often the reason the project is valuable.

If recent tickets show approved refund exceptions, the public policy says no exceptions, and an internal billing note requires account-owner review, the team does not need a generic summary. It needs the contradiction surfaced so the reviewer can decide the real rule.

Why this is not a chatbot, wiki, or enterprise search project

Search helps people find existing information. A wiki gives information a place to live. A chatbot can answer questions over available content.

Those tools can be useful, but they do not solve the first scoping problem by themselves.

If the source material is stale, incomplete, or contradictory, finding it faster does not create a trusted procedure. Asking a chatbot about it can make the problem worse if the answer sounds confident while hiding the disagreement.

The issue-pack workflow is different:

Choose one recurring issue.
Gather 10-20 redacted artifacts.
Extract draft SOPs, decision rules, macros, gaps, and conflicts.
Put each item through human review.
Export the reviewed pack into the places the team already works.

The goal is not to let anyone ask anything. The goal is to produce source-backed operating knowledge that one responsible reviewer can approve, edit, reject, and reuse.

That is why Company Brain starts narrow.

How Company Brain fits

Company Brain is built for this smaller first project.

The current product trial is designed around one recurring support or onboarding issue, 10-20 redacted artifacts, one reviewer, and one reviewed issue pack. It works from real source material such as tickets, macros, notes, transcripts, SOP drafts, CRM notes, and exported team discussions where technically supported.

Company Brain then drafts structured operating outputs for review: SOPs, decision rules, escalation rules, gaps, conflicts, support macros, internal FAQ entries, open questions, and optional agent-ready skill-file drafts.

The important part is the review workflow. Outputs stay draft until a human owner approves, edits, rejects, or marks them as needs edit. The useful result is not "AI organized our company." The useful result is narrower:

This recurring issue now has a reviewed pack our team can use, export, and improve.

That is the kind of result a buyer can judge.

A concrete example: onboarding handoff confusion

Suppose new customers keep repeating setup context after sales hands them to onboarding.

The team knows the handoff is messy, but "fix onboarding documentation" is too broad. A better first issue is:

New customers arrive in onboarding without the account owner, launch stage, open commitments, and implementation blockers clearly handed over.

The source artifacts might include:

five CRM notes from closed-won accounts
three kickoff call transcripts
four Slack or Teams threads about missing context
three customer emails where the customer repeated information
the current handoff checklist
one escalation note from a delayed launch

From that narrow evidence set, the issue pack could produce:

an onboarding handoff SOP
a decision rule for when missing account-owner data blocks handoff
a gap report showing no owner for post-handoff customer updates
conflict notes where CRM fields and kickoff notes disagree
macro drafts for customer follow-up
open questions for the onboarding owner to resolve

That is useful because it creates a reviewed operating output for a repeat failure. It does not require a company-wide knowledge map.

How to choose your first issue

Use a hard filter. A good first issue should pass most of these tests:

The issue has happened more than once in the last few weeks or months.
The current answer depends on tickets, notes, docs, macros, or team memory.
Mistakes create customer pain, rework, delays, inconsistent promises, or avoidable escalations.
You can gather 10-20 redacted artifacts around the issue.
One reviewer has authority to approve or reject the output.
The team would use the reviewed pack this week if it were good enough.
The issue is narrow enough to finish without cleaning up the whole company.

If the issue fails these tests, narrow it.

"Billing" is too broad. "Customers disputing partial credits after plan changes" is better.

"Onboarding" is too broad. "Sales-to-onboarding handoffs missing launch-stage context" is better.

"Support knowledge" is too broad. "Account owners locked out after domain changes" is better.

The narrower version is not less ambitious. It is more testable.

What to avoid

Avoid starting with:

a full company-wide documentation audit
an open-ended wiki cleanup
a broad knowledge-base migration
a chatbot over all documents
a generic AI knowledge project
a folder of unredacted confidential artifacts
a sensitive dataset containing secrets, payment data, regulated data, private employee records, or material your company cannot share
an issue with no reviewer
an issue where nobody would use the output soon

Public Product Trials should use redacted or sanitized operational artifacts. Ordinary confidential operational material is not for public trials and requires explicitly agreed handling terms plus the security-hardening gates before a controlled trial can accept it. Restricted artifacts should stay out of scope.

This boundary is not legal theater. It keeps the first trial honest and useful. The point is to test whether one reviewed issue pack is valuable, not to smuggle an enterprise data program into the first step.

The next step

Pick the issue your team would be relieved to stop re-litigating.

Write it in one sentence. Pull 10-20 redacted artifacts around it. Name the reviewer. Decide where the reviewed pack would be used: support macros, internal SOPs, onboarding docs, help-center drafts, training material, or escalation playbooks.

If you want the product page for this workflow, start with Company Brain or the support tickets to SOPs page. If you already have one recurring issue and redacted source artifacts, start the Product Trial. If the issue, reviewer, or artifact set is not clear yet, apply for guided scoping.