Editorial guide

Do Not Build a Chatbot for a Process Problem

When the same support or onboarding issue keeps coming back, it is tempting to add a chat layer over the documents you already have.

That feels practical. The team is not starting from zero. There are tickets, SOPs, saved replies, help-center drafts, CRM notes, Slack or Teams explanations, and call transcripts somewhere. If people could just ask a question and get the answer, maybe the repeated issue would stop.

But recurring operational issues usually do not repeat because the answer is impossible to find. They repeat because the answer is scattered, stale, contradictory, or not approved by anyone who owns the process.

Chat over docs can make that mess easier to query. Enterprise search can make the same mess easier to find. Neither automatically turns the mess into a trusted operating procedure.

For a recurring support or onboarding issue, the more useful first step is to turn the source material into a reviewed issue pack: source-backed SOP drafts, decision rules, gaps, conflicts, open questions, macro drafts, and review state.

The problem is not always retrieval

Search is useful when the right answer already exists and people cannot find it.

Chat is useful when someone wants a quick answer from material that is already current, complete, and coherent.

Many operating problems fail that test.

Take a recurring support issue:

Customers ask for refunds after onboarding delays, and Support is not sure when to deny, refund, issue a partial credit, or escalate to Billing Ops.

The answer may be spread across:

a public refund policy
an old internal SOP paragraph
recent tickets where agents made exceptions
a billing note about custom contracts
a saved reply that promises a 24-hour response
a Slack or Teams thread where Billing Ops asked for three business days
CRM notes showing that some customers had launch commitments

If you ask a chat interface, "Should we refund this customer?", it may give a fluent answer. If you search, you may find the policy, the macro, and the old ticket. But the real work is not retrieval.

The real work is deciding which source is current, which exception is allowed, which branch applies, which promise is safe to make, and who should approve the rule.

That is a process problem.

Confident answers can hide the disagreement

The most dangerous output is not always a bad answer. Sometimes it is a polished answer that hides uncertainty.

If the refund policy says no exceptions, recent tickets show approved partial credits after onboarding delays, and the macro promises a faster response than Billing Ops can support, the team does not need one neat paragraph.

The team needs the contradiction surfaced.

A useful workflow should say:

the policy and recent ticket behavior disagree
the response-time promise conflicts with the billing review note
CRM context changes the ruling for some accounts
the current source material does not say who owns mixed onboarding-delay and custom-contract cases
a reviewer needs to decide which rule becomes reusable guidance

That is why source-backed extraction matters. It gives the reviewer something to inspect instead of asking everyone to trust a generated summary.

Source-backed extraction gives the reviewer a draft to judge

For one recurring issue, the first valuable output is not a chatbot answer. It is a set of reviewable drafts and findings.

A useful issue-pack workflow should work from the source material a support or onboarding owner can actually gather for one issue: tickets, macros, SOP fragments, internal notes, CRM notes, exported team discussions, transcripts, and pasted text when the files are readable.

For the refund-after-onboarding-delay issue, a reviewed issue pack might include:

SOP draft: confirm account, plan, invoice date, onboarding delay evidence, and previous promises before replying.
Decision rules: deny ordinary outside-window preference disputes, escalate custom-contract cases, and route onboarding-delay exceptions to Billing Ops before promising a credit.
Escalation rules: include invoice date, launch date, onboarding blocker, account tier, prior customer promise, and linked evidence.
Support macro drafts: one reply for eligible credits, one for Billing Ops review, one for outside-window denial, and one for missing evidence.
Gap report: no source clearly says whether Support can approve a partial credit without Billing Ops.
Conflict report: the macro promises 24 hours, while the billing note says three business days.
Open questions: should onboarding-delay exceptions be documented publicly, kept internal, or handled only through escalation?
Review state: draft, approved, rejected, or needs edit for each item.

The reviewer can now do the work that matters: approve the parts that are right, edit weak language, reject unsupported claims, and decide which conflicts become policy.

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

Human review is the trust layer

Operational knowledge is not trustworthy just because it sounds finished.

Old tickets can contain outdated judgment. Macros can drift from policy. CRM notes can change the answer for one account but not another. A transcript can explain the real process while missing the final approval rule.

For recurring issues, a human reviewer is not a bottleneck. The reviewer is the person who turns extracted drafts into usable guidance.

Before starting, name the reviewer:

Head of Support
Support Operations Manager
Customer Success Operations lead
onboarding owner
billing owner
COO or founder for a small team

The title matters less than authority. The reviewer should be able to approve, edit, reject, or mark outputs as needs edit. They should also be able to answer the uncomfortable questions the sources expose.

If nobody can review the output, the team is probably not ready for an operating pack yet.

Why one issue is the right first unit

The obvious alternative is to process everything: all support docs, all tickets, all onboarding notes, all internal policies.

That is too broad for a first test.

One recurring issue is small enough to judge. It has a named owner, a source set, a review path, and a clear use case. The team can ask whether the pack would be used this week.

Start with 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

These are not broad knowledge-management projects. They are recurring operating problems with evidence.

Why 10-20 redacted examples is enough to start

You do not need a full system integration to test whether this workflow is useful.

For a first issue pack, gather 10-20 relevant examples where feasible:

resolved tickets
support macros or saved replies
current SOPs or old SOP drafts
internal policy notes
CRM notes that affect the answer
exported Slack or Teams threads
call transcripts or onboarding notes
examples where the standard answer failed

Some files can be messy. That is the point. A useful issue-pack workflow should turn messy source material into draft operating knowledge, not ask the team to write perfect documentation first.

Use redacted source material for one scoped issue. Ordinary confidential operational material is acceptable for the trial. Do not include secrets, credentials, payment data, regulated health, legal, or financial data, private employee records, highly confidential strategy, or anything your company cannot share.

What a reviewed issue pack contains

A reviewed issue pack should be concrete enough to export and reuse.

It should contain some or all of:

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

The exact mix depends on the issue. A billing-dispute pack may need a decision tree and macros. An onboarding handoff pack may need workflow steps, owner rules, missing-context gaps, and customer-update language.

The important part is that the output is reviewable. The reviewer should be able to see what the draft is based on, what is uncertain, what conflicts, and what is safe to approve.

When chat and search still help

This is not an argument that search or chat are useless.

Search can help the team find source material. Chat can help someone explore documents or ask follow-up questions once the underlying guidance is reliable.

The mistake is using them as the first solution for a recurring process problem.

If the sources are stale, incomplete, or contradictory, faster retrieval does not create a procedure. A fluent answer does not decide the rule. Someone still has to turn evidence into approved operating knowledge.

That is the work a reviewed issue pack is meant to make faster and more visible.

How Company Brain fits

Company Brain is an early product for one focused workflow: turn one recurring support or onboarding issue into a reviewed issue pack.

The trial starts with one issue, 10-20 redacted files or examples where feasible, and one reviewer. Company Brain extracts source-backed drafts, gaps, conflicts, and open questions from the source material. The reviewer approves, edits, rejects, or marks items as needs edit before the pack is exported.

The useful result is not a broad question-answering layer.

The useful result is narrower:

This recurring issue now has reviewed operating guidance the team can use, export, and improve.

That is a better first test than adding a chat box over uncertain source material.

The next step

Pick the recurring support or onboarding issue your team keeps re-litigating.

Write it in one sentence. Gather 10-20 relevant redacted tickets, macros, SOP fragments, notes, transcripts, or exports. Name the reviewer who can approve the result. Decide where the reviewed pack would be used: support macros, internal SOPs, onboarding docs, help-center drafts, training material, or escalation playbooks.

If you already have the issue and source material, start the free one-issue trial. If the issue, reviewer, or source set is still unclear, apply for guided scoping.