Editorial guide

What a Reviewed Issue Pack Looks Like

If your team is going to gather files and assign someone to review the output, the deliverable needs to be concrete before the trial starts.

Before you share tickets, macros, SOP fragments, CRM notes, Slack or Teams exports, or transcripts with any AI workflow, you should know exactly what comes back.

That question is practical, not skeptical for its own sake. Gathering redacted artifacts takes work. Assigning a reviewer takes attention. Starting a Product Trial should feel like a concrete workflow, not a leap of faith.

Here is what your team should be able to inspect, edit, approve, export, and use after a reviewed issue-pack trial.

The example issue

Here is a realistic example:

Customers dispute partial charges after a plan change, and Support is not sure when to deny, refund, issue a credit, or escalate to Billing Ops.

That issue is narrow enough to review. It is not "billing." It is not "all refund policy." It is one recurring operational problem with customer-facing consequences.

The source set might include:

8 redacted billing dispute tickets from the last two months
3 saved replies or support macros
2 internal billing notes
2 CRM notes showing custom contract terms
1 Slack or Teams export where Support asked Billing Ops for the exception rule
1 old SOP paragraph about refunds and credits
1 call transcript where a customer explained the disputed charge

That is enough to see the pattern without turning the trial into a full company cleanup project. For a public Product Trial, use redacted or sanitized examples. Leave out secrets, payment data, regulated data, private employee records, and confidential material your company has not agreed to share.

The pack starts with a source inventory

The first useful section is not the SOP. It is the source inventory.

A source inventory tells the reviewer what Company Brain actually considered:

Ticket set: eight redacted disputes involving plan changes and partial charges.
Existing macros: standard denial reply, partial-credit reply, and "escalating to Billing" reply.
Internal notes: one billing policy note and one exception note.
CRM context: two account records with custom commercial terms.
Team discussion: one exported thread about when Support can promise a credit.
Transcript: one customer call explaining the disputed charge.

This matters because the reviewer needs to know what the draft is based on, and what it did not see. If the old policy note was included, the reviewer should see that. If the custom-contract examples were included, the reviewer should see that too. If something important is missing, the gap should be visible instead of silently hidden.

A vague summary says, "We reviewed your billing materials."

A useful issue pack says, "These are the specific artifacts behind this draft, and these are the places where evidence is thin."

The SOP draft is the operating sequence

The SOP draft should tell an agent what to do next time the issue appears.

For the billing dispute example, a draft might say:

Confirm the customer account, plan, invoice date, and date of the plan change.
Identify whether the dispute is about a billing error, customer misunderstanding, product defect, onboarding delay, custom terms, or preference.
Check whether the account has custom commercial terms before using the standard denial macro.
If the dispute is inside the standard adjustment window, follow the approved partial-credit workflow.
If the dispute is outside the standard window but tied to custom terms, product defect, or onboarding delay, escalate to Billing Ops before promising an outcome.
Reply with the approved macro only after the ruling path is clear.
Log the decision reason so future similar disputes do not restart from zero.

That is a draft, not final policy. The reviewer may approve it, edit it, reject parts of it, or mark it as needs edit. The important part is that the draft is concrete enough to review.

If the SOP only says "handle billing disputes carefully," it is useless. A reviewer cannot approve vagueness.

The decision tree separates cases that look similar

Most recurring support issues are hard because similar-looking cases should not get the same answer.

A reviewed issue pack should separate the branches:

Standard eligible adjustment: invoice is within the approved window and no custom terms apply. Use the partial-credit macro.
Outside-window preference dispute: customer changed plan and later disagreed with the charge, but no error, defect, custom term, or onboarding delay is present. Use the denial macro unless a manager approves an exception.
Custom commercial terms: CRM or contract note changes the standard rule. Escalate to Billing Ops before promising a refund or credit.
Product defect or onboarding delay: collect evidence and route to Billing Ops with the defect or delay context.
Unclear account ownership: ask the account owner for context before replying with a ruling.

This is the job a chatbot or search tool usually fails at: separating similar cases into rules a reviewer can trust. Search may find every old dispute ticket. A chatbot may answer with one polished paragraph. Neither is enough if the real work is deciding which branch applies.

The pack should give the reviewer branches they can approve, correct, or reject.

Escalation rules show who owns the gray area

An issue pack should not pretend every case can be solved by the frontline agent.

For the billing dispute example, escalation rules might include:

Escalate custom-contract cases to Billing Ops before sending any customer-facing ruling.
Escalate defect-linked disputes when the ticket contains product evidence, support confirmation, or an engineering reference.
Escalate onboarding-delay disputes when the delay is documented in CRM notes, kickoff notes, or customer emails.
Do not escalate ordinary preference disputes outside the adjustment window unless a manager approves the exception.
Include invoice date, plan-change date, dispute reason, account tier, prior promises, and linked evidence when escalating.

Good escalation rules reduce repeat manager interruptions. They also prevent unsafe customer promises. The point is not to remove human judgment. The point is to make clear when judgment belongs to Support, Billing Ops, the account owner, or a manager.

Macro drafts turn the reviewed rule into usable language

A pack should include support macro drafts only when the source material supports them.

For this issue, Company Brain might draft:

Eligible adjustment macro: confirms the credit or refund path after Support verifies the account and adjustment window.
Billing Ops review macro: tells the customer the dispute is being reviewed because the account terms or defect evidence may affect the outcome.
Outside-window denial macro: explains the standard policy without sounding punitive or inventing exceptions.
Need more evidence macro: asks for the missing invoice, product evidence, or account-owner context before making a ruling.
Post-review resolution macro: communicates the final Billing Ops decision with a clear next step.

The reviewer should be able to edit tone, remove unsupported promises, reject weak drafts, and approve the versions the team can reuse.

This is one reason a reviewed issue pack is not just a documentation artifact. It can produce the actual language agents need when the next customer writes in.

Gaps and conflicts are part of the deliverable

The gap and conflict report is often more valuable than the SOP.

For the billing dispute example, the pack might surface:

The old refund SOP says disputes outside the window are always denied.
Recent tickets show partial credits approved when onboarding delays blocked product use.
One macro promises a response within 24 hours.
The internal billing note says Billing Ops needs up to three business days for custom-contract review.
CRM notes contain custom terms, but the standard support macro does not tell agents to check CRM before replying.
No source clearly says who owns disputes involving both product defects and custom terms.

This is not a failure of the extraction. It is the reason the review matters.

If the source material disagrees, the product should not flatten it into a confident answer. It should show the contradiction so the reviewer can make the business decision.

Open questions tell the reviewer what to decide

Some questions cannot be answered from artifacts alone.

The pack should call them out:

Should Support ever approve a partial credit without Billing Ops review?
Does a documented onboarding delay create an exception outside the standard adjustment window?
Who owns final approval when a custom contract and a product defect both apply?
Should the 24-hour macro be retired or rewritten to match the three-business-day review note?
Should the help-center article mention exception handling, or should that stay internal?

Open questions keep the output honest. They also make the review session more productive because the reviewer can focus on decisions, not blank-page writing.

Approval state keeps draft work separate from trusted guidance

Every item in the pack should have a review state.

Useful states are simple:

Draft
Approved
Rejected
Needs edit

The reviewer should be able to edit the item, save the edited version, and export the reviewed pack. "Needs edit" cannot be a dead end. If the SOP has the right structure but the wrong escalation language, the reviewer needs a path to fix it.

This is the trust layer. Company Brain should not ask a team to believe that extracted knowledge is automatically correct. Old tickets can be wrong. Macros can be stale. Internal notes can conflict. The product should speed up the path from evidence to reviewable draft, then let a responsible human approve what becomes reusable operating knowledge.

Optional skill-file draft prepares agent-ready guidance

Some teams care about agent-ready output. Some do not yet. That is why the skill-file draft should be optional.

For this billing dispute issue, a skill-file draft might define:

when the issue applies
what context an agent must collect
which rules require escalation
which customer-facing promises are forbidden before review
what output should be logged after the ruling

This is not a workflow execution engine. It is not a broad automation platform. It is a structured draft that can help a team later prepare safe instructions for AI agents or internal assistants, after the human-reviewed process is clear.

The sequence matters: reviewed procedure first, agent-ready draft second.

Export is the point

The pack should be useful outside Company Brain.

The team may export it into:

internal SOP docs
support macros
billing playbooks
onboarding or CS training material
help-center drafts
QA review notes
agent-readiness documentation

If the output only lives inside a trial screen, it is harder to prove buyer value. The useful result is a reviewed pack the team can carry into the places work already happens.

Why this is not a chatbot, search tool, or wiki cleanup

This workflow is narrower than those categories.

A chatbot answers questions. Enterprise search finds existing material. A wiki stores documentation. All three can be useful, but they do not automatically turn conflicting source material into approved operating knowledge.

For one recurring issue, the reviewed issue-pack workflow is different:

Choose one issue.
Gather 10-20 redacted artifacts.
Extract source-backed drafts, gaps, conflicts, and open questions.
Put each item through human review.
Export the approved or reviewed pack.

The deliverable is not "ask anything about your company."

The deliverable is a reviewed operating pack for one issue your team already handles too often.

How to judge whether your issue fits

Compare the example pack to one issue inside your own team.

The fit is good if:

the issue has repeated in recent weeks or months
answers are spread across tickets, macros, SOPs, internal notes, CRM records, threads, transcripts, or employee memory
mistakes create customer pain, delays, inconsistent promises, rework, or escalations
you can gather 10-20 redacted artifacts
one reviewer can approve, edit, reject, or mark outputs as needs edit
the team would use the reviewed pack this week if it were good enough

The fit is weak if the issue is broad, has no reviewer, has no artifact trail, requires live integrations to be useful, or depends on restricted material your company should not share.

The next step

Pick one recurring issue. Write it in one sentence. Gather 10-20 redacted artifacts. Name the reviewer. Then ask whether the example pack above would be useful if it existed for that issue.

If the answer is yes, try Company Brain on that one issue. If the issue, reviewer, or artifact set is not clear yet, apply for guided scoping. If you want the broader product context first, start with Company Brain or the support tickets to SOPs page.