Skip to main content

​
The no-match miner → KB auto-draft loop

No-match mining tells you which contact reasons your AI agents had no answer for. That discovery is useful, but the default outcome used to be stalled work: someone had to notice the opportunity, read the mined examples, and author an article by hand. The auto-draft loop closes that gap — for every high-volume reason flagged as “best deflected by a help article”, the platform drafts one from the real customer excerpts and files it into a review queue. A human approves, and only then does the article become retrievable ground truth. This page explains how the loop works end to end, and which knobs you control. The task-level walkthrough (which button, which endpoint) lives in the knowledge-base lifecycle guide.

​
1. The loop at a glance

  1. Mine. The no-match miner reads your resolved inbound conversations over the last 30 days and ranks contact reasons by volume, flagging the ones self-serve content would best deflect.
  2. Gate. A per-tenant opt-in switch decides whether the scheduled sweep touches your workspace at all. Off by default; nothing drafts without it.
  3. Draft. For each flagged reason with no existing draft, the loop assembles a draft article from the real customer excerpts and files it into a dedicated draft pool knowledge base, always pending review.
  4. Review. A reviewer with knowledge:write scope approves or rejects. Approval is the exact moment the article’s chunks get embedded and your agents can answer from it.
The drafts are deliberately extractive — real mined customer excerpts plus a reviewer checklist, assembled deterministically without a generation call. The reviewer’s job is to turn real questions into a finished article, not to fact-check a guessed-at resolution; because the output is deterministic, a second run over the same inputs produces the same draft.

​
2. No-match mining: what counts as “unanswered”

The mining leg is the same topic-intelligence engine that powers the conversation intelligence signals and the no-match surface in the insights rollup. It buckets your resolved inbound conversations into ranked contact-reason topics and measures, per topic: how many conversations arrived (volume), which channel they came in on, and what share resolved without reaching a useful answer (the deflection rate). Topics with meaningful volume and poor deflection become candidates — the platform only ever drafts for reasons the miner already ranks as “best deflected by a knowledge article”, and a candidate needs at least two distinct real customer excerpts for a draft to be written at all. Drafts are deduplicated by topic. A topic that already has a draft sitting anywhere in the review lifecycle — pending, approved, or rejected — is skipped on every subsequent run, so a daily sweep cannot pile up duplicate drafts for the same recurring reason.

​
3. The opt-in gate: nothing mines without it

The loop writes customer-conversation excerpts into a new knowledge base, so it is strictly opt-in per organization. Two endpoints carry the setting:
  • GET /insights/kb-auto-draft/config — the current enabled flag and max_drafts_per_run cap.
  • PUT /insights/kb-auto-draft/config — update either field; a partial body is merged into the existing config.
Two fields, two roles, one rule:
  • enabled (default false) — the scheduled sweep skips your organization unless this is set to true. Turning it off later stops new drafts; it does not remove drafts already in the pool.
  • max_drafts_per_run (default 3, hard ceiling 10) — how many new drafts a single mining run may create for your organization. Kept small on purpose so a reviewer’s queue never gets flooded in one pass.
One deliberate bypass: POST /insights/kb-auto-draft/run mines your organization immediately even when the config is disabled, and requires an admin-class role. An explicit “run now” ask is the consent the gate exists to require — the gate shields you from the unattended scheduled sweep, not from yourself.

​
4. The scheduled sweep: one bounded batch per cycle

A platform scheduler ticks once a day and, for every opted-in organization, runs one mining pass: the 30-day rolling window, the capped draft count, the topic dedup. Mined contact reasons move slowly day to day, and every draft is deduplicated by topic before anything is written, so a faster tick would add redundant scans, not fresher drafts. Per-organization failures are isolated — one tenant’s failure logs and the sweep continues with the rest, so a single broken workspace cannot starve everyone else’s drafts. The work itself is bounded the same way the self-serve run is bounded: at most max_drafts_per_run new drafts per organization per day, and only for reasons with enough real excerpts to be useful.

​
5. The draft pool: where drafts live (and how to recognize them)

Drafts are ordinary knowledge documents — no special storage. What makes them a pool is where they land: on the first run that produces a draft, the loop finds-or-creates a dedicated knowledge base in your workspace named “Auto-Mined Drafts (Pending Review)”. This separation is deliberate: auto-mined content never mixes into your production knowledge bases, so an unfinished draft can never leak into retrieval through a base your agents already attach. The base is found by a configuration marker, not by its name — renaming it does not break dedup or pool detection. Each draft document also carries metadata tracing it back to the mined source — the topic, the window, and how many conversations fed it — so reviewers can see provenance, not just content. The pool base forces one rule unconditionally: every document requires publish approval, regardless of your workspace’s default upload posture. An unreviewed AI-authored article must never go live on its own, and that rule holds even if your other knowledge bases auto-index on upload.

​
6. Approve or reject: the human decision that publishes

The pool reuses the standard knowledge moderation lifecycle — no separate review machinery:
  • Approve — POST /knowledge-bases/:id/documents/:docId/approve (or the moderation queue in the dashboard). Approval flips the document from pending to retrievable: its chunks are embedded and your AI agents may answer from its content. Optional reviewer notes (up to 2000 characters) are recorded on the document’s moderation block.
  • Reject — POST /knowledge-bases/:id/documents/:docId/reject. The document stays dark and is never admitted to retrieval.
Both endpoints require the knowledge:write scope (owner, admin, or developer), and both decisions are written to the audit ledger with the reviewer and any notes. The prompt a reviewer sees is the draft body itself: real customer excerpts at the top, a checklist at the bottom — replace the raw excerpts with a real explanation, add the resolution steps, then approve. Rejecting a draft does not invite a replacement: the same reason is considered drafted and stays skipped until you delete the rejected document from the pool, which frees the topic to be drafted again on a later run.

​
7. Worked example: one reason, one draft, one published answer

Your organization opts in with max_drafts_per_run: 3. Over the last 30 days the miner ranks order_status at 41 resolved conversations, mostly by SMS, with a 12% deflection rate — one of three flagged article reasons. On the next sweep, the loop drafts one document into Auto-Mined Drafts (Pending Review):
  • titled Order status — draft help article (auto-mined),
  • body: 5 real customer excerpts (“where is my order”, “tracking says nothing for a week”, …), with the volume, window, and primary channel stated up front,
  • status: pending — invisible to retrieval.
A reviewer opens the draft, replaces the excerpts with an explanation of how tracking works, adds the resolution steps (“check the carrier link”, “the fallback contact path”), and approves. From that approval forward, agents attached to your knowledge bases answer order-status questions from the reviewed article — and the next sweep skips order_status, moving on to whatever reason ranks next.

​
Cross-references