Editorial guide

Start With One Bounded Team Corpus, Not the Whole Company

Most company knowledge projects start too big.

Support answers are inconsistent. Onboarding handoffs depend on memory. Macros are stale. Internal docs no longer match the way people work. The diagnosis is usually right. The proposed fix is usually vague: clean up every document, rebuild the knowledge base, reorganize the wiki, or create a company brain.

That is how a real operating problem becomes a project nobody can finish.

The better first step is a bounded team or function corpus: one related set of tickets, notes, procedures, transcripts, macros, and internal discussions that one process owner can review.

Not the whole company. One reviewable slice of real work.

Why broad knowledge cleanup stalls

“All company knowledge” is not a workable first unit.

It has no obvious owner or finish line. It mixes 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.

The failure pattern is familiar:

leadership agrees the knowledge base is messy
someone opens a documentation project
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 disappear inside cleaner folders
the project slows down before the team gets one reusable operating output

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

If the first project is “organize everything,” most of the work goes into defining the system. If the first project is a bounded corpus owned by one team, you can ask a sharper question:

Can this process owner turn the evidence the team already uses into a reviewed pack that improves work this week?

Bound the source material without pre-solving the problem

A useful first corpus is narrow enough to review but does not require the team to diagnose every workflow in advance.

For example:

Support operations: tickets, macros, policy notes, escalation guidance, selected CRM context, and internal discussions for the support work one owner manages.
Customer onboarding: handoff checklists, CRM notes, kickoff transcripts, customer emails, playbooks, and escalation threads for one onboarding motion.
Customer success operations: renewal notes, risk-review templates, account handoffs, meeting transcripts, and escalation guidance for one segment or lifecycle stage.
RevOps: lead-routing rules, CRM notes, exception logs, handoff docs, and team discussions for one revenue workflow.

The boundary is a team, function, or related operating slice—not a random folder and not the entire company.

You also do not need to force every file into one preselected recurring issue. A team may know that support exceptions are painful without knowing whether the first useful output will be a refund procedure, a bug-escalation rule, an access-recovery workflow, or a conflict report spanning all three.

Let the evidence reveal the useful sub-problems. A narrow issue pack can emerge from the corpus; it should not be a prerequisite for starting.

A good corpus leaves a trail

The best first scope has real evidence, not only opinions about what the process should be.

Useful source material can include:

resolved tickets and customer conversations
support macros or saved replies
current SOPs, old drafts, and help-center articles
internal notes explaining exceptions
CRM notes that legitimately affect decisions
Slack or Teams exports where ownership was discussed
call transcripts and handoff notes
examples where the standard answer failed

Some files can be clean and some can be messy. Include sources the team still sees even if you suspect they are stale. The point is to show the reviewer how the work is actually being reconstructed.

Avoid a full helpdesk dump or an unlabeled drive export. More files do not automatically create a better result. Choose enough representative material to cover the bounded work, its common cases, and its important exceptions. The reviewer should be able to recognize the corpus and judge whether something critical is missing.

One reviewer matters more than a perfect folder

Broad knowledge projects often fail because review responsibility is diffuse. Everyone wants better documentation; nobody owns the final answer.

Choose one reviewer or process owner before extraction begins. The title matters less than the authority to decide what becomes reusable guidance.

That reviewer should be able to answer questions such as:

Is this procedure current?
Is this decision rule safe to reuse?
Does this macro make a promise we should not make?
Is this exception standard policy or a one-time judgment call?
Which source wins when a ticket, macro, and internal note disagree?
What business decision must happen before this item can be approved?

Human review is not bureaucracy added after the “real” work. It is the trust layer.

What the reviewed pack should produce

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

A reviewed operational knowledge pack can include:

Workflow areas: the processes and repeated patterns found in the source set.
SOP drafts: concrete steps for work the evidence supports.
Decision rules: when to approve, deny, escalate, request context, or apply an exception.
Escalation rules: who owns an edge case and what evidence must travel with it.
Support macro drafts: reusable customer language for common branches.
Internal FAQ entries: answers the team needs but customers may not.
Gaps: missing owners, fields, policies, or customer-facing guidance.
Conflicts: places where tickets, macros, notes, or docs disagree.
Outdated-content flags: sources that appear to describe a superseded process.
Open questions: decisions the reviewer must make before guidance can be trusted.
Review state: what is approved, rejected, needs editing, or remains draft.

The gaps and conflicts are often the most valuable part. If recent tickets show approved exceptions, the public policy rules them out, and an internal note requires another owner’s approval, the team does not need a generic summary. It needs the contradiction exposed so the reviewer can decide the real rule.

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

Search finds existing information. A wiki gives information a home. A chatbot answers questions over the material it can access.

Those tools can be useful, but they do not settle disagreements in the source material.

The reviewed-pack workflow is different:

Define one bounded team or function corpus.
Gather representative source material from the work.
Extract workflow drafts, rules, gaps, conflicts, and open questions.
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 about the company. It is to give one responsible owner source-backed operating knowledge they can inspect, correct, approve, and reuse.

A concrete example: onboarding handoff operations

Suppose new customers keep repeating setup context after Sales hands them to Onboarding.

“Fix onboarding documentation” is too broad. “Find one recurring issue and pre-sort every source around it” may be too narrow too early. A better first scope is the material used for one sales-to-onboarding motion:

CRM notes from recent closed-won accounts
kickoff call transcripts
exported discussions about missing context
customer emails where information had to be repeated
the current handoff checklist
escalation notes from delayed launches

From that corpus, the pack might produce:

an onboarding handoff SOP
a decision rule for when missing account-owner data blocks handoff
a checklist for launch stage, open commitments, and implementation blockers
a gap showing no owner for post-handoff customer updates
conflict notes where CRM fields and kickoff notes disagree
customer follow-up language
an open question about who may accept incomplete handoffs

One narrow sub-output might address repeated launch-stage omissions. Another might expose a broader ownership gap. Both are legitimate findings from the same bounded corpus.

How Company Brain fits

Company Brain turns one bounded team or function artifact corpus into a draft operational knowledge pack for human review.

It works from supported materials such as tickets, macros, notes, transcripts, SOP drafts, CRM notes, and exported team discussions. It does not require customers to pre-parse those materials into one named issue. The product identifies candidate workflow areas and creates source-backed drafts, gaps, conflicts, and open questions for a process owner to review.

Outputs remain drafts until a human approves, edits, rejects, or marks them as needing work. The useful result is not “AI organized our company.” It is:

This owner now has a reviewed pack for a bounded part of the operation, including the decisions that still need to be made.

That is specific enough for a buyer to judge.

How to choose the first corpus

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

It belongs to one support-heavy team or function.
The work currently depends on tickets, notes, docs, macros, transcripts, or team memory.
Inconsistency creates customer pain, rework, delays, risky promises, or avoidable escalation.
The source material contains real cases as well as written policy.
One reviewer has authority to approve or reject the result.
The team has a clear intended use for the reviewed output.
The boundary is small enough to review without cleaning up the whole company.

“All support knowledge” is too broad. “The operational material used by the support operations owner for billing adjustments, access recovery, and bug escalation” is reviewable.

“Every onboarding document” is too broad. “The source material used for the mid-market sales-to-onboarding handoff” is better.

The narrower scope is not less ambitious. It is testable.

What to keep out

Do not begin with:

a company-wide documentation audit
an open-ended wiki cleanup
a broad knowledge-base migration
a chatbot over every document
a folder of unrelated files with no process owner
a corpus nobody intends to use soon
restricted material the organization should not share

Ordinary confidential operational material is allowed for a bounded corpus, and users should not have to manually sanitize normal business documents. Restricted material remains out of scope: secrets and credentials, payment data, regulated health, legal, or financial information, private employee records, highly confidential strategy, and anything the organization cannot share under its own obligations.

This boundary keeps the first run honest. The point is to test whether a reviewed operational knowledge pack is useful, not to smuggle a company-wide data program into the first step.

The next step

Choose the team or function where people keep reconstructing work from scattered evidence. Define the operating slice, gather the material the team actually uses, name the reviewer, and decide where a good pack would be applied.

If the bounded corpus and reviewer are ready, start the free trial. If the team boundary, intended use, or source set is unclear, apply for guided scoping. For the support-specific view, see support tickets to SOPs.