Editorial guide

The Gap Report Is Sometimes More Valuable Than the SOP

When a recurring support or onboarding issue keeps coming back, the obvious request is usually, "Can we get an SOP for this?"

That request makes sense. A missing procedure creates inconsistent replies, slow handoffs, extra escalations, and managers who have to answer the same question again and again.

But sometimes the team does not have an SOP problem yet. It has a gap problem.

The source material may not contain one clean answer. It may contain a stale macro, a newer ticket exception, a Slack or Teams thread where someone made a judgment call, a CRM note that changes the answer for one customer, and an old doc that nobody fully trusts.

If you turn that into a polished SOP too quickly, you can make the team more confident about the wrong process.

For those issues, the first useful output is not the procedure. It is the gap and conflict report that shows what must be decided before the procedure can be trusted.

The SOP request often hides an unresolved decision

Teams ask for SOPs when work feels inconsistent.

That inconsistency may come from a missing document. It may also come from a decision nobody has made clearly enough.

Look at a recurring issue such as:

Support is unsure when a billing dispute should be refunded, credited, denied, or escalated.
Onboarding does not know who owns the customer update when launch context is missing.
Agents are unsure whether a bug report should go to Support, Product, Engineering, or the account owner.
Cancellation requests are handled differently depending on contract terms, timing, usage history, or renewal state.
Implementation blockers keep moving between CS, onboarding, and support because ownership is not documented.

In each case, an SOP can help only after the rule is clear.

If the real issue is unclear ownership, contradictory policy, missing account context, or an exception path that only lives in team memory, the SOP draft should not pretend the rule is settled. It should surface the unresolved decision.

A useful gap report names what the team does not know

A bad gap report says, "More documentation is needed."

That is too vague to act on.

A useful gap report is specific enough for the reviewer to make a decision. It names the missing owner, missing source, missing rule, or missing customer-facing guidance.

For a billing dispute issue, the report might say:

No source says whether Support can approve a partial credit without Billing Ops review.
The standard denial macro does not mention custom commercial terms, but recent tickets show custom terms changed the ruling.
The help-center article explains the standard refund window, but no source explains product-defect exceptions.
The saved reply promises a 24-hour response, while the Billing Ops note says custom-contract review takes up to three business days.
No source says who owns the final ruling when both a product defect and custom contract apply.

Those findings are more valuable than a neat summary because they tell the owner where judgment is required.

The reviewer can now decide:

which source wins
which promise should be removed
which exception should become standard
which case must be escalated
which question needs a policy owner before the SOP can be approved

That is the work that turns messy source material into operating knowledge.

Conflicts are not a bad sign

When tickets, macros, docs, transcripts, CRM notes, and internal threads disagree, it can feel like the source material is too messy to turn into a useful procedure.

Often, the opposite is true.

The contradiction is the point.

Suppose the sources around one recurring cancellation issue show this:

The public help article says customers can cancel any time.
The renewal macro says annual contracts require 30 days' notice.
Recent tickets show managers approving exceptions after implementation delays.
A CRM note says one account has a custom renewal clause.
A Slack thread says Legal must review enterprise cancellation exceptions.

The wrong output is a confident paragraph that smooths all of that into "Customers can cancel according to their contract terms."

That sounds safe, but it does not help the next agent. It hides the decision branches.

A better output says:

the public article and renewal macro are not specific enough for annual-contract cases
implementation-delay exceptions appear in tickets but are not documented as policy
custom clauses require CRM review before using the standard macro
enterprise exceptions may require Legal review, but the source trail does not define the threshold

Now the reviewer can approve a real decision tree instead of editing a vague SOP.

Why search and chat do not solve this by themselves

Search can find the policy, the ticket, the macro, and the thread.

Chat can give a quick answer based on the available material.

Neither is enough when the available material disagrees.

If the current sources conflict, faster retrieval does not decide which rule should become the procedure. A conversational answer can even make the problem worse if it hides the uncertainty behind confident wording.

The better workflow is:

Choose one recurring issue.
Gather the real source material around that issue.
Extract draft SOPs, decision rules, macros, gaps, conflicts, and open questions.
Put the gaps and conflicts in front of the reviewer before approving the SOP.
Export the reviewed pack only after the unresolved decisions are handled.

That workflow does not treat the gap report as a side note. It treats it as the review map.

What to gather for a useful gap report

You do not need a full company knowledge export.

Start with 10-20 relevant files, tickets, notes, transcripts, or exports around one recurring issue. The set should be narrow enough that one reviewer can judge the findings.

Useful source material includes:

resolved support tickets
support macros and saved replies
SOP fragments or old help-center articles
CRM notes that change the customer answer
Slack or Teams exports where the exception was discussed
call transcripts or handoff notes
account notes, escalation notes, or QA notes
examples where the standard answer failed

Include the stale material if the team still sees it. A gap report is more useful when it can show exactly where the old macro, recent tickets, and current owner understanding disagree.

Use ordinary confidential operational material only for one scoped issue. Do not upload secrets, credentials, payment data, regulated health, legal, or financial data, private employee records, highly confidential strategy, or anything your company cannot share.

What the reviewer should do with gaps

The reviewer should not treat every gap as a writing task.

Some gaps need a rewrite. Some need a decision. Some need a source. Some need escalation to another owner.

For each finding, the reviewer should ask:

Is this actually missing, or did we fail to include the right source?
If sources disagree, which one is current?
Is this a one-time exception or a rule agents can reuse?
Who owns the decision?
Does the answer belong in an internal SOP, a macro, a help-center article, or an escalation note?
Can the SOP be approved now, or should it stay in draft until this gap is resolved?

This is why review state matters. The team should be able to approve clean items, reject unsupported items, mark uncertain items as needs edit, and keep unresolved gaps visible until a decision is made.

If "needs edit" is a dead end, the gap report does not create trust. It just creates a list of problems. The reviewer needs a path to edit, save, approve, reject, and export the reviewed result.

A concrete example: bug-report triage

Take a support team that keeps mishandling bug reports.

The recurring issue is:

Support is not sure when a customer-reported issue should stay in Support, become a Product ticket, escalate to Engineering, or go back to the account owner for more context.

The source set includes support tickets, one triage macro, an old escalation SOP, a few Product comments, CRM notes for affected accounts, and an internal thread where Engineering asked for better reproduction steps.

The first SOP draft might be simple:

Confirm the customer, plan, browser or environment, and affected workflow.
Check whether the issue is already known.
Collect reproduction steps, screenshots, timestamps, and account context.
Use the bug-report macro when the customer needs a response.
Escalate only when the required evidence is present.
Record the triage decision.

That is useful, but the gap report may be more important:

The old SOP does not define the difference between Product and Engineering escalation.
Recent Product comments ask for reproduction steps, but the macro does not collect them.
CRM notes show some accounts have launch commitments, but the escalation path does not say when the account owner should be notified.
No source says who owns customer updates after Engineering accepts the issue.
Tickets use three labels for the same issue type, so reporting is noisy.

Those findings tell the reviewer why the issue keeps repeating.

The fix is not only "write an SOP." The fix is to decide the branch logic, update the macro, clarify ownership, and retire ambiguous labels.

How Company Brain fits

Company Brain is built around one focused workflow: turn one recurring support or onboarding issue into a reviewed issue pack.

The trial starts with one issue, 10-20 relevant files or examples where feasible, and one reviewer. Company Brain drafts SOPs, decision rules, escalation rules, macro drafts, gaps, conflicts, open questions, and optional agent-ready skill-file drafts from the source material.

The gap report is part of the deliverable because a clean SOP is not always the first thing the team needs. Sometimes the useful result is:

Now we can see the missing decisions that were making this issue impossible to document.

That is a better outcome than publishing a polished but unsupported procedure.

The reviewer stays in control. Outputs remain draft until a human owner approves, edits, rejects, or marks them as needs edit. The goal is not automated correctness. The goal is a reviewed pack the team can trust enough to export and use.

When the gap report is the strongest signal

Use the gap report as the main lens when:

the issue has repeated several times, but nobody agrees on the correct answer
the current macro, SOP, and recent tickets disagree
escalation depends on unstated judgment
ownership changes by account tier, contract, region, customer history, or product state
agents keep asking managers the same question
the team suspects the docs are not merely missing, but wrong or incomplete

Those are the situations where a draft SOP alone can create false confidence.

If the gaps are specific, the reviewer can turn them into decisions. If the conflicts are visible, the team can choose which source wins. If the missing owners are named, the workflow can stop depending on memory.

That is how a recurring issue becomes reusable operating knowledge.

The next step

Pick one issue where the team keeps asking for an SOP but the real answer still feels unsettled.

Gather 10-20 relevant tickets, macros, notes, transcripts, exports, or SOP fragments. Include the material that may be stale or contradictory. Name one reviewer who can decide what becomes the rule.

If the issue already has source material, start the free one-issue trial. If the issue, reviewer, or source set is not clear yet, apply for guided scoping. If you want to see the broader deliverable first, read what a reviewed issue pack looks like.