Company Brain
Editorial guide

Do Not Build a Chatbot for a Process Problem

When support or onboarding work keeps going wrong, it is tempting to add a chat layer over the documents you already have.

The logic is understandable. The team has tickets, SOPs, saved replies, help-center drafts, CRM notes, Slack or Teams explanations, and call transcripts. If people could ask a question and get an answer, perhaps they would stop interrupting managers or handling the same case three different ways.

But many operating problems do not persist because the answer is hard to retrieve. They persist because the source material is stale, incomplete, contradictory, or never approved by the person who owns the process.

Chat can make that mess easier to query. Search can make it easier to find. Neither turns it into a trusted way of working.

Retrieval works only when the answer already exists

Search is useful when the right answer exists and people cannot find it. Chat is useful when the underlying material is current, coherent, and safe to use.

Operational work often fails that test.

Take a support team handling refund requests after onboarding delays. The answer may be spread across:

  • a public refund policy
  • an old internal SOP
  • recent tickets where managers approved exceptions
  • a billing note about custom contracts
  • a saved reply promising a 24-hour response
  • an internal thread where Billing Ops asked for three business days
  • CRM notes showing that some customers had launch commitments

Ask a chatbot, “Should we refund this customer?” and it may produce a fluent answer. Search may find every relevant document. The hard part remains: which source is current, which exception is reusable, which account context changes the rule, what promise is safe, and who owns the decision?

That is a process problem.

A confident answer can hide the real risk

The dangerous output is not always an obviously bad answer. Sometimes it is a polished answer that smooths over disagreement.

If policy says no exceptions, recent tickets show partial credits, and the macro promises a response faster than Billing Ops can deliver, the team does not need one neat paragraph. It needs the conflict surfaced.

A useful workflow should make clear that:

  • policy and recent ticket behavior disagree
  • the macro and the billing review note make different timing promises
  • account-specific terms change some decisions
  • the sources do not name an owner for mixed cases
  • a reviewer must decide which rule becomes reusable guidance

This is why reviewing the evidence matters. It gives the process owner drafts and findings to inspect instead of asking everyone to trust a generated answer.

Start with a bounded operating corpus

Do not make the team pre-sort every file into one recurring issue before the work can begin. That pushes the hardest diagnostic work back onto the customer.

Choose one bounded team or function corpus instead. A support operations corpus might contain tickets, macros, policy notes, escalation guidance, selected CRM context, transcripts, and internal discussions from a related slice of work. An onboarding corpus might contain handoff checklists, kickoff transcripts, CRM notes, customer emails, and escalation threads.

The boundary should be narrow enough for one process owner to review, but it can contain several related workflows. The evidence may reveal that refund exceptions are one coherent sub-problem, that bug escalation is another, and that an old access-recovery macro needs to be retired.

That is a feature of the workflow. The team starts with the material it actually uses and learns where the real process boundaries are.

Give the reviewer something concrete to judge

The first valuable output is not a chat response. It is a set of reviewable drafts and findings.

For the refund example, one part of an operational knowledge pack might include:

  • SOP draft: confirm the account, plan, invoice date, onboarding-delay evidence, and previous promises before replying.
  • Decision rules: distinguish ordinary preference disputes from custom-term, defect-linked, or onboarding-delay cases.
  • Escalation rules: identify the owner and the evidence required before a customer promise is made.
  • Support macro drafts: provide separate language for an eligible adjustment, billing review, denial, and missing evidence.
  • Gap report: note that no source clearly says whether Support can approve a partial credit without Billing Ops.
  • Conflict report: flag that the macro promises 24 hours while the billing note allows three business days.
  • Open questions: ask whether exception handling belongs in public guidance or should remain internal.
  • Review state: show which items are draft, approved, rejected, or need edits.

The reviewer can approve what is right, edit weak language, reject unsupported rules, and decide which conflicts require a policy change.

That is a different job from answering one question in chat.

Human review is the trust layer

Operational knowledge is not trustworthy merely because it sounds finished.

Old tickets contain outdated judgment. Macros drift from policy. CRM context may change the answer for one account but not another. A transcript may describe the real workflow while omitting the final approval rule.

Name one reviewer or process owner for the bounded corpus. The title matters less than the authority to approve, edit, reject, and resolve the findings. It might be a Head of Support, Support Operations Manager, Customer Success Operations lead, onboarding owner, billing owner, COO, or founder.

If nobody can judge the output, the team is not ready to turn generated drafts into operating guidance.

What belongs in the corpus

You do not need to wait for every system to be connected or for the documentation set to become perfect. Use the material the team already relies on:

  • resolved tickets and customer conversations
  • support macros or saved replies
  • current SOPs and old drafts
  • internal policy and escalation notes
  • relevant CRM notes
  • exported Slack or Teams discussions
  • call transcripts and handoff notes
  • examples where the standard process failed

Some material can be messy or contradictory. That is the point.

Whether the evidence arrives through an upload, an export, or a bounded read-only connection, the rule is the same: preserve the source, surface failures and staleness, and keep the result in draft until an accountable owner approves it. Faster collection is useful. It is not a substitute for governance.

Ordinary confidential operational material is allowed for a bounded team or function corpus, and users should not have to manually sanitize normal business documents before upload. Restricted material stays out: secrets, 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.

What a reviewed operational knowledge pack contains

The pack should be concrete enough to inspect, correct, export, and reuse. Depending on the evidence, it can contain:

  • a source inventory
  • workflow areas
  • SOP drafts
  • decision and escalation rules
  • internal FAQ entries
  • support macro drafts
  • knowledge gaps
  • conflicts and outdated-content flags
  • source-backed open questions
  • optional agent-ready skill-file notes
  • approval, rejection, needs-edit, or draft state
  • a reviewed export

The exact mix should follow the corpus. A billing-heavy corpus may produce a detailed adjustment decision tree. An onboarding corpus may produce a handoff SOP, ownership gaps, and customer-update language. A recurring issue pack may emerge as a useful narrow section, but it is not the only valid output.

When chat and search still help

This is not an argument against search or chat.

Search can help find source material. Chat can help people explore approved guidance or ask follow-up questions after the underlying process is coherent.

The mistake is making the chat box the first solution to contradictory operations.

If the sources disagree, faster retrieval does not settle the rule. A fluent answer does not name the owner. Someone still has to turn the evidence into reviewed operating knowledge.

How Company Brain fits

Company Brain is designed for that evidence-to-review workflow. It turns one bounded team or function artifact corpus into a draft operational knowledge pack: procedures, decision rules, escalation rules, gaps, conflicts, macros, FAQs, workflow areas, and optional agent-ready notes.

The process owner stays in control. Each item can be approved, edited, rejected, or marked as needing work before the reviewed pack is exported.

The useful outcome is not “we added chat to our documents.” It is:

We can see how this team operates, where the evidence disagrees, and which guidance a responsible owner has approved.

That is a better first test than putting a conversational interface over uncertain source material.

The next step

Choose the support, onboarding, customer success, RevOps, or operations slice where people keep reconstructing the process from memory. Gather the real files that shape the work and name one reviewer who can decide what becomes reusable guidance.

If that bounded corpus is ready, start the free trial. If the team boundary, intended use, or reviewer is still unclear, apply for guided scoping.