Company Brain
Editorial guide

How to Detect Gaps and Contradictions in Your Support Documentation

Your help-center article says the customer should expect a reply within 24 hours. The support macro says “as soon as possible.” An internal note gives Billing Ops three business days. Recent tickets show agents promising all three.

This is how support documentation fails in practice. No single document looks obviously broken. The contradiction appears only when you compare the sources agents use while handling the same situation.

Agents notice the inconsistency first. They stop trusting the macro, ask a manager, copy an old ticket, or improvise. The knowledge base still looks complete from a distance.

You do not need a company-wide documentation audit to find the problem. Start with one bounded support area and run a contradiction audit against the material that actually shapes decisions.

Choose one reviewable support area

“Audit all support documentation” is too broad. Pick a team, queue, or related operating slice with a clear owner.

Good first scopes include:

  • billing adjustments and refund exceptions
  • account-access recovery
  • bug-report triage and escalation
  • onboarding handoffs
  • cancellation and renewal questions

Gather representative evidence from that area:

  • current help-center articles
  • internal SOPs and old drafts
  • macros and saved replies
  • recent routine tickets and exception tickets
  • escalation notes
  • selected CRM context that legitimately changes the answer
  • exported Slack or Teams discussions
  • call or handoff transcripts

Include material you suspect is stale if agents still encounter it. A hidden old macro can keep causing mistakes long after someone has replaced the official article.

Turn each repeated situation into a claim list

Do not compare documents as whole documents. Compare the claims they make about the same situation.

For a billing-adjustment case, list claims such as:

  • which customers are eligible
  • which dates or account states matter
  • what evidence the agent must collect
  • who may approve an exception
  • when Billing Ops must be involved
  • what response time can be promised
  • which customer-facing language is allowed

Then record what each source says about each claim. You are looking for missing cells, conflicting cells, and rules that appear only in behavior but nowhere in approved guidance.

This simple move exposes contradictions that a document-by-document review misses.

Look for six common failure patterns

1. The public article and internal procedure disagree

Customers read one rule while agents are trained on another. Sometimes the internal procedure is newer. Sometimes the public article reflects the intended policy and the internal workaround has drifted. Do not assume which source wins.

2. The macro makes a promise the process cannot keep

Response times, refunds, credits, escalation outcomes, and follow-up commitments are common failure points. Separate the wording problem from the operating-rule problem behind it.

3. Recent cases contain an undocumented exception

Several tickets may show the same exception even though no SOP names it. That is evidence of a possible rule, not proof that the behavior should become policy.

4. The SOP names steps but not decision branches

“Review the request and escalate if needed” hides the actual work. What conditions trigger escalation? What evidence is required? Who owns the decision?

5. Ownership disappears at the handoff

The document explains how to send the case to another team but not who updates the customer, how long the review may take, or what happens if the receiving team rejects it.

6. Account context changes the answer silently

Contract terms, launch commitments, plan tier, region, or account status may change the path. If the standard macro ignores those conditions, agents will apply a general answer to a specific exception.

Classify the finding before fixing it

Not every mismatch is the same kind of problem.

  • Gap: a required rule, owner, field, source, or customer instruction is missing.
  • Conflict: two relevant sources make incompatible claims.
  • Outdated guidance: evidence suggests one source describes an older process.
  • Unsupported behavior: tickets show a practice that no accountable owner has approved.
  • Open question: the sources cannot settle a decision that the team must make.

This classification matters. A copywriter can fix unclear wording. Only the right process owner can decide whether Support may approve a partial credit or whether Security must review a domain change.

Give every finding an owner and an action

A contradiction list without an owner becomes another stale document.

For each finding, record:

  1. the exact claim under review
  2. the sources that support or contradict it
  3. the team or person who can decide
  4. the proposed action: approve, rewrite, retire, escalate, or leave unresolved
  5. the downstream surfaces that must change after the decision

Keep unresolved items visible. Do not mark an SOP approved while a material decision branch remains hidden in a comment.

Rebuild the guidance from approved decisions

After the owner resolves the important findings, update the operating set together:

  • the SOP steps
  • the decision and escalation rules
  • the public article when appropriate
  • the internal macro
  • the evidence requirements
  • the ownership and response-time language

If you update only the help article, the macro may keep teaching the old rule. If you update only the macro, the underlying procedure remains unclear.

The audit is complete when the sources that people rely on tell a coherent story, not when the findings spreadsheet looks tidy.

How Company Brain fits

Company Brain turns one bounded support or operations source set into reviewable SOP drafts, decision rules, macro drafts, gaps, conflicts, outdated-content flags, and open questions.

It does not decide which policy is correct. It keeps the evidence and disagreement visible so one accountable reviewer can approve, edit, reject, or hold the proposed guidance before exporting the reviewed operational knowledge pack.

Supported uploads, pasted text, exports, and ZIPs can provide the source material. A connected source should preserve the same narrow boundary and review gate rather than treating a whole workspace as approved knowledge.

For more on why the findings can matter more than the draft, read the gap report is sometimes more valuable than the SOP. For the helpdesk publishing loop, read how to build a helpdesk knowledge base from support tickets.

The next step

Pick one support area where agents regularly ask which answer is current. Gather the articles, macros, procedures, recent cases, and internal notes that shape that work. Name the person who can settle the rules and identify one place the corrected guidance will be used this week.

If the corpus and reviewer are ready, start the free trial. If the boundary is still unclear, apply for guided scoping.