Company Brain
Editorial guide

Your Support Queue Already Contains the SOP. You Just Have Not Extracted It.

A support queue is not only a place where customer problems arrive. It is also a record of how your team already handles the problems that keep coming back.

Look at one recurring issue: refund exceptions, login loops, onboarding handoff confusion, billing disputes, feature setup questions, bug-report triage, or escalation uncertainty. The same pattern appears again and again. A customer asks. An agent checks the account. Someone remembers an exception. A macro gets adjusted. A manager adds a note. The ticket closes.

Then the next customer asks the same thing.

That repeat is the signal. Your team probably has the operating procedure already, but it is scattered across old tickets, saved replies, internal notes, Slack or Teams threads, CRM context, and one-off exceptions. Nobody trusts it as an SOP because nobody has extracted it, reviewed it, and approved it as the current way to handle the issue.

The blank-page SOP is the wrong starting point

When a support leader says "we need an SOP for this," the team often starts from a blank document.

That sounds disciplined, but it ignores the best source material available: the actual cases your agents handled. A blank-page SOP usually reflects what someone thinks the process should be. Your support queue shows what the team actually did when a customer was waiting.

The queue contains:

  • the customer's exact language for the issue
  • the account state, plan, timing, or product context that changed the answer
  • the checks agents performed before replying
  • the saved macro that worked most of the time
  • the exception that forced a manager decision
  • the internal note that explains why the public article is incomplete
  • the escalation path agents used when the case did not fit policy

That is not noise. It is raw operating knowledge.

The problem is that ticket systems are optimized to resolve cases, not to distill procedures. Once the ticket is closed, the reasoning gets buried. The next agent may search for a similar case, ask a teammate, or improvise. The answer may be correct, but the procedure stays trapped in the queue.

A recurring ticket pattern is usually a missing issue pack

The better workflow is not to clean up every support document or build one giant company knowledge system. That is too broad, too slow, and too easy to turn into a generic search project.

The useful unit is one recurring issue.

Pick a narrow pattern such as:

  • "Customers asking for refunds after onboarding delays"
  • "Account owners locked out after domain changes"
  • "New customers missing implementation context after sales handoff"
  • "Billing dispute tickets involving partial credits"
  • "Bug reports where Support is unsure when to escalate to Product"

For that one issue, the goal is to create a reviewed issue pack. Evidence goes in: tickets, macros, notes, threads, transcripts, and old docs. Draft operating knowledge comes out: an SOP draft, decision rules, escalation rules, gaps, conflicts, support macro drafts, and review notes. Then one human owner decides what is approved, what needs editing, and what should be rejected.

Company Brain is built around that narrower motion. It asks, "What should our team do the next time this exact recurring issue appears?"

This distinction matters. A broad knowledge base asks, "Where should all our documentation live?" A chatbot asks, "What can we ask our content?" An issue-pack workflow asks, "What source-backed procedure should a reviewer approve for this repeat problem?"

That is the question a support operator can actually use.

What to gather from the queue

Start with 10-20 redacted artifacts around one issue. Do not start with a whole helpdesk export. Do not start with a vague category like "billing." The pattern should be tight enough that one reviewer can judge the output.

Useful artifacts include:

  • resolved support tickets
  • support macros and saved replies
  • internal notes on the account or issue
  • CRM notes that change the response
  • Slack or Teams exports where the exception was discussed
  • call transcripts or handoff notes where the process was explained
  • old SOP paragraphs or help-center articles that may be stale

Redaction matters. Public Product Trials should use redacted or sanitized operational artifacts. Remove customer names, private account details, secrets, regulated data, payment details, employee records, and anything your company cannot share under its own obligations. If your examples contain ordinary confidential operational material, use guided scoping instead of treating a public upload form as the right path.

Messy artifacts are fine. Unsupported artifacts should not be pretended into source material. If a file cannot be parsed, the system should say so clearly rather than acting as if it read what it did not read.

What Company Brain extracts

For a recurring support issue, Company Brain is designed to produce a draft operational knowledge pack for human review.

The useful outputs are concrete:

  • SOP draft: the steps an agent should follow before replying or escalating.
  • Decision rules: when to approve, deny, escalate, request more evidence, attach a defect claim, or check custom terms.
  • Escalation rules: who owns the exception and what context must travel with it.
  • Support macro drafts: reusable customer-facing language that matches the approved procedure.
  • Internal FAQ entries: answers agents need but customers may not need to see.
  • Gaps: missing owner, missing policy, missing account field, or missing customer-facing article.
  • Conflicts: places where tickets, macros, policy notes, or recent exceptions disagree.
  • Open questions: decisions the reviewer must make before the pack can be trusted.

The conflict report is not a side feature. It is often the most important part.

If ten tickets say refund exceptions go to Billing Ops, the old macro promises an instant answer, and one internal note says enterprise accounts require account-owner approval, a generic summary can easily flatten that into a confident but wrong paragraph. A useful issue pack should show the contradiction so the support owner can decide what the real rule is.

That is why Company Brain is not trying to be a generic chatbot over support tickets. The point is not to let anyone ask anything. The point is to produce reviewable operating artifacts that can become the next approved procedure.

Human review is the trust layer

Ticket-derived guidance can be powerful, but old tickets are not automatically correct.

Some tickets contain outdated policy. Some contain one-time exceptions. Some contain customer promises that should never become standard. Some contain agent workarounds that were reasonable under pressure but wrong as official process.

That is why the review workflow is central. The reviewer should be a support owner, support operations manager, billing owner, onboarding owner, or founder who can judge whether the extracted guidance is current and safe to reuse.

The reviewer should be able to:

  • approve an item
  • reject an item
  • mark an item as needs edit
  • edit the content
  • save the edited version
  • export only approved or reviewed outputs

"Needs edit" cannot be a dead-end status. If the reviewer sees the right idea but weak wording, missing evidence, or an unsafe exception, they need a way to fix it before the pack becomes reusable.

This is also where Company Brain's validation-stage framing matters. The product should not imply automated correctness. It should help a reviewer get from messy evidence to a usable draft faster, then let the reviewer decide what becomes the operating procedure.

A concrete example: refund exceptions

Suppose the same refund exception keeps hitting the queue.

The public policy says refunds are available within 30 days. The current macro says, "We cannot refund purchases outside the standard window." But recent tickets show exceptions when onboarding was delayed, when a product defect blocked usage, or when a custom contract term applied. One Billing Ops note says custom-contract requests must be routed before any customer promise is made.

The queue already contains the shape of the SOP:

  1. Verify purchase date and plan.
  2. Check whether custom terms apply.
  3. Capture the refund reason and evidence.
  4. Identify whether the case involves product defect, onboarding delay, billing error, or customer preference.
  5. Route custom-contract or defect-linked exceptions to Billing Ops before promising an outcome.
  6. Reply with approved language once the rule is clear.
  7. Record the ruling so future similar cases are not re-litigated from scratch.

It also contains decision rules:

  • If the refund is inside the standard window, follow the normal macro.
  • If the refund is outside the window but tied to a verified defect, route to Billing Ops with defect evidence.
  • If the account has custom commercial terms, do not apply the standard macro until the account terms are checked.
  • If the request is preference-based and outside policy, use the denial macro unless a manager approves an exception.

And it contains conflicts:

  • The macro says "no refund outside the window."
  • Recent tickets show approved exceptions.
  • The internal note requires Billing Ops review for custom contracts.
  • The help-center article does not mention defect-linked exceptions.

That is an issue pack. It is more useful than a loose summary because it gives the reviewer specific items to approve, edit, reject, or turn into a policy decision.

Why this is not enterprise search

Enterprise search helps people find existing information. That can be useful, but it does not solve the support-queue-to-SOP problem by itself.

If the macro is stale, the old ticket is wrong, and the internal note contradicts the help-center article, search can find all three. It cannot decide which one should become the procedure.

A chatbot has the same problem. If the underlying artifacts disagree, a conversational answer may sound confident while hiding the disagreement. For support operations, that is dangerous. A wrong macro can create inconsistent customer promises. A wrong escalation rule can waste manager time or expose a customer to a bad answer.

The better workflow is extraction, review, and export:

  1. Choose one recurring issue.
  2. Gather redacted evidence.
  3. Extract draft SOPs, rules, macros, gaps, and conflicts.
  4. Put each item through human review.
  5. Export the reviewed pack into the places your team actually works.

Company Brain is built for that narrower workflow. It is not a wiki replacement, a full company knowledge graph, a broad automation platform, or a workflow execution engine. It is a focused way to turn one messy operational issue into source-backed, reviewable knowledge.

How to run the first trial

If you want to test this inside your team, do not start with a content calendar or a documentation cleanup project.

Start with one issue that would matter this week.

Use this checklist:

  1. Name the recurring issue in one sentence.
  2. Pull 10-20 redacted tickets, macros, notes, and related artifacts.
  3. Include the current macro or article if one exists.
  4. Include examples where the standard answer failed or required an exception.
  5. Choose one reviewer who can approve, edit, or reject the output.
  6. Decide where the reviewed pack would be used: support macros, internal SOPs, help-center drafts, onboarding docs, or training material.

The strongest first trial is narrow enough to judge quickly. If the output would not be used by support this week, pick a sharper issue.

The next step

Your support queue already contains more operational knowledge than your documentation suggests. The question is whether you can turn one recurring pattern into a reviewed procedure before the next customer asks the same thing.

If you want the product page for this workflow, see support tickets to SOPs. 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.