Every support operation already owns the material its knowledge base is missing. It sits in resolved conversations: the same questions asked daily, answered by agents, closed, and then mined again tomorrow when a new customer asks the same thing. The gap between "we know customers keep asking this" and "there is an article that answers it" is almost never a discovery problem — the discovery ran hours ago. It is an authoring problem: somebody has to open a blank editor, find the real phrasing customers use, and write the piece.
Devotel Orbit's KB auto-draft closes that loop. The Insights dashboards already rank every resolved conversation into recurring contact reasons and flag which ones are best answered by a help article. Auto-draft takes the next step the ranking never took: for each flagged reason, it assembles a draft article from the real customer excerpts — the actual question in the customer's own words, up to five recent examples — and files it into a pending-review knowledge base. Nothing goes live on its own. A human rewrites the draft into a finished article and approves it; approval is the moment the article's chunks embed and your AI agents can answer from it.
This post maps the shipped surface: what qualifies for a draft, where drafts live, how the two-tenant settings behave, and the guardrails that keep an unreviewed AI-assembled article from ever grounding an agent.
The loop before auto-draft: ranked, not written
The mining half of the loop predates auto-draft. The automation-opportunities analysis scans resolved conversations over a rolling 30-day window, clusters them into recurring contact reasons, and ranks each reason by volume with the evidence attached — conversation counts, the dominant channel, the current self-service deflection rate, and the representative customer excerpts. Each ranked reason is shaped by the remedy that fits it: some are best handled by a workflow, some belong in a dialer script, and some are best deflected by a help article.
That last class is where the loop used to stall. The mining pass said, in effect, "customers keep asking about open enrollment dates and a help article would absorb it" — and then stopped. An operator had to notice the opportunity on the Insights dashboard, open the mined examples, and author the article by hand. The signal was shipped; the writing was not. Auto-draft is the writing leg, and it reuses the same ranking and the same mined material rather than running a parallel analysis.
What a draft is — and what it deliberately is not
Each mining run that qualifies a reason files one draft into a dedicated knowledge base, Auto-Mined Drafts (Pending Review), found-or-created on your first run. The draft carries three parts, all derived from the mining evidence:
- Why customers are asking — the reason's conversation volume over the window, the dominant channel it arrives on, and the deflection rate today, so a reviewer can see how exposed agents are before deciding the article is worth finishing.
- What customers are saying — up to five verbatim customer excerpts, the exact phrasing the article has to answer. Reviewers write toward real questions rather than an imagined FAQ.
- A reviewer checklist — the honest framing of the handoff: replace the excerpts with a real explanation, add the actual resolution steps (the draft contains none, on purpose), then approve to publish.
The construction is extractive, not generative: no model invents an answer. The draft assembles what customers actually asked and leaves the resolution to the person who knows it. That choice is deliberate — the reviewer's job is to write two good paragraphs, not to fact-check a confident fabrication. It also makes the queue reproducible: the same window produces the same drafts.
Qualification: volume alone never files a draft
A contact reason becomes a draft only when it clears one tunable posture and three fixed bars. The posture is opt-in: the scheduled sweep skips your workspace entirely until you turn the module on under Insights → Auto-drafted knowledge, and the per-run cap (max_drafts_per_run, 1–10, default 3) bounds how many new drafts one run may file so a review queue is never flooded. The fixed bars are not operator-tunable:
- Article-shaped only. The reason must rank as "best deflected by a help article" in the mining analysis. Workflow-shaped and dialer-script-shaped opportunities never become articles — they belong to the automation and outbound surfaces the ranking sends them to.
- Enough signal. The reason needs at least two distinct real excerpts inside the window. Below that there is not enough material to draft anything useful, and the reason is skipped until more conversations resolve.
- Per-topic dedup. Once a reason has a draft in the review queue — pending, approved, or rejected — every later run skips it. A daily sweep cannot pile up duplicate drafts for one recurring reason; a rejection is sticky too, so noise does not keep re-drafting. If a rejected topic later deserves a second look, delete the rejected document from the pool base and the next run treats it as new.
Runs file the highest-ranked candidates first and return both counts — drafts filed and qualifying topics considered — on a manual run, so an integration can tell "nothing qualified" apart from "drafts filed."
The hard line between draft and published
The review queue is separated from your live knowledge bases by construction, and the separation is enforcement, not convention. The Auto-Mined Drafts knowledge base requires publish approval on every document regardless of your workspace's default upload posture: a pending draft's chunks are never embedded, never indexed, and never retrievable by any AI agent attached to any knowledge base. The moderation queue — the same approve/reject surface every other knowledge base uses, in the dashboard and over POST /knowledge-bases/:id/documents/:docId/approve — is the only path to live.
That design keeps the risk profile of an always-on sweep at zero for agent quality: the sweep can misfile, over-draft, or surface a topic a human judges wrong, and none of it touches an answer until a human approves it. Auto-draft writes; people decide.
A worked cycle — resolved conversation to grounded answer
A workplace-benefits operator turns the module on with the defaults (enabled: true, max_drafts_per_run: 3) on a Monday.
Tuesday's sweep mines the prior 30 days of resolved conversations. The ranking has been flagging open_enrollment_dates — 61 resolved conversations, mostly over chat, with a 12% self-service deflection rate — as the reason best deflected by a help article. The run pulls five recent excerpts ("when does open enrollment close?", "can I change my plan after enrollment ends?") and files a draft titled Open enrollment dates — draft help article (auto-mined) into the pending queue. Two lower-ranked reasons also draft; the per-run cap stops the queue at three.
The reviewer opens Agents → Knowledge base → Auto-Mined Drafts before the weekly content meeting. For the open-enrollment draft she replaces the excerpts with two paragraphs — "Open enrollment runs Nov 3–21. Plan changes are locked after Nov 21 except for qualifying life events." — links the HR portal, and approves. The article's chunks embed within the minute, and attached agents now answer enrollment-date questions from it instead of escalating.
The next sweep skips open_enrollment_dates — a draft exists — and moves to the next-ranked undrafted reason. Over the following month, the deflection-rate column on the Insights dashboards shows the published article absorbing exactly the traffic it was drafted from. That read-back is what makes the loop closed: the same mining surface that flagged the gap now measures the article against it.
Where the loop runs
The whole cycle is tenant-owned. The opt-in toggle and per-run cap live under Insights → Auto-drafted knowledge and mirror over PUT /insights/kb-auto-draft/config; a manual pass runs from the same page, or headlessly via POST /insights/kb-auto-draft/run — the manual run works even while the scheduled sweep is off, because an explicit "run now" is itself the consent the opt-in gates. Approved drafts can live in the pool base, or be copied into your main knowledge base and attached to agents from there; the pool is a staging area, not a permanent home. The auto-draft guide walks the dashboard controls and every endpoint, and the knowledge-base lifecycle guide covers where approved articles go next — retrieval tuning, gap and staleness reports, and rollout to agents.
Your resolved conversations already voted on which articles to write. Auto-draft files those votes into a queue. What your agents answer is still your call — that is the one step the loop leaves to you.
FAQ
Does auto-draft publish anything on its own? No. Every draft lands pending in the Auto-Mined Drafts knowledge base, which enforces publish approval on every document. A pending draft is invisible to AI agents until a human approves it — approval is the same moderation action every other knowledge base uses.
What does a draft contain if it contains no answer? The reason's volume, dominant channel, and deflection rate; up to five verbatim customer excerpts; and a reviewer checklist. The draft is assembled extractively from real conversations, with no generated answer to fact-check — the reviewer rewrites it into the finished article.
Can a daily sweep flood the review queue or re-draft the same topic? No. The per-run cap (default 3, maximum 10) bounds new drafts per run, and per-topic dedup skips any reason that already has a draft in the queue at any status — including rejected. Deleting a rejected document from the pool base is how you re-open a topic.