Turn a Support Video into a Knowledge Base Article

The ticket is closed, but the answer is still trapped in a three-minute recording. An agent found the permission that blocked an export, showed the customer what to change, and confirmed the file arrived. Two weeks later, another agent gets the same question and starts again from zero.

A good knowledge base article preserves the reusable part of that solution without preserving the customer’s identity, account details, or one-off detours. The recording is source material. It is not the finished article, and an automatically generated draft is not ready to publish until a person checks every instruction, screenshot, permission, and failure branch.

Quick answer: how do you turn a support video into a knowledge base article?

Start with one recording of one issue that was actually solved. Remove customer and account identifiers, then extract the prerequisites, actions, decision points, screenshots, expected result, and unresolved details. Use a documented Smart Actions workflow when it is available for the output you need, or work manually from the transcript and timeline. Rewrite the explanation as task instructions, not a transcript summary.

Add the branches a future reader will need: what to do when a control is missing, when a permission is denied, when the result differs, and when to escalate. Check the article with the current product, add accessible text and meaningful image descriptions, assign an owner and review date, then publish through your normal knowledge base review process. Do not send an unreviewed generated draft straight to customers.

1. Choose a solved, repeatable issue with a confirmed result.
2. Copy the source into an approved working location and remove identifiers.
3. Map useful timestamps to prerequisites, steps, screenshots, results, and unknowns.
4. Generate a draft with a documented Smart Actions workflow or extract it manually.
5. Rewrite spoken narration as concise, testable task instructions.
6. Add troubleshooting, permission, and escalation branches.
7. Verify every step in a clean test account with the intended role.
8. Review for accuracy, access, privacy, and accessibility.
9. Assign an owner, review date, and update trigger before publishing.

Choose one solved issue, not a highlight reel

The easiest source video is not always the best source video. Pick a case with a clear beginning, a confirmed fix, and a result someone else can reproduce. The recording should answer one user question, such as “Why can’t a project member export this report?” It should not combine sign-in trouble, billing questions, a browser workaround, and an unrelated feature tour.

Confirm the resolution in the ticket before writing. A workaround that happened to succeed once may not be the supported process. If the agent changed three settings and nobody knows which one mattered, keep the recording with the ticket and investigate further. Documentation should preserve a known path, not turn uncertainty into policy.

Prefer issues likely to recur and useful beyond one account. A stable permission rule, setup task, or common failure can make a strong article. A temporary outage, customer-specific data repair, or unreleased interface usually belongs in incident notes or an internal escalation record instead.

• The issue has a clear audience and task.
• The support team confirmed the outcome.
• The path follows current product and support guidance.
• The example can be rebuilt with synthetic data.
• A future reader can act without the original customer context.
• The article will have a team responsible for keeping it current.

Separate the reusable answer from the customer record

A support recording may show names, email addresses, workspace titles, filenames, tabs, notifications, internal links, ticket numbers, or spoken identifiers. Do not assume a crop at the beginning removes everything. Watch the complete recording, listen to the audio, inspect transitions, and review any transcript before moving material into documentation.

Build the article in a test workspace with invented names such as “Example Workspace,” “Sample Project,” and “Quarterly Export.csv.” Replace real account IDs, domains, dates, and data values. When an identifier matters to the instruction, describe its form instead of copying its value: “Enter your workspace ID” is reusable; “Enter ws_847291” is not.

The final article should stand on its own. Do not link readers to the original ticket or customer recording unless the knowledge base is strictly internal, access is appropriate, and policy permits that use. Even then, the maintained article should contain enough text that a reader does not need the case evidence to complete the task.

Build a timestamp map before you draft

A timestamp map turns a linear recording into the parts of a useful article. The sample below is synthetic. It describes a fictional export-permission issue and deliberately marks details the recording does not prove.

Pause whenever the recording changes jobs. A prerequisite explains what must be true before the task starts. A step tells the reader to do something. A screenshot proves location or state. An expected result tells the reader whether the action worked. A failure branch explains what to check next. Keeping those categories separate prevents a transcript from becoming one long paragraph.

Mark unknowns in the map rather than smoothing them over. If the recording does not establish which roles can change the permission, write “verify authorized role” in the working draft. If a label is hard to read, check the current interface. If the agent casually names a cause that the ticket never confirmed, leave it out or label it as a diagnostic possibility.

Use Smart Actions as a draft path, not an approval path

If your Zight workspace has a documented Smart Actions workflow for turning a recording into written material, it can provide a useful starting draft. Review the current Zight AI workflow and the output available to your plan and workspace. Product availability and output options can change, so use the workflow your team has tested rather than relying on an old screenshot or an assumed button name.

A generated outline can help surface a title, summary, transcript, action sequence, or guide structure. It cannot know which spoken aside was wrong, which permission is approved by your organization, whether a screenshot contains private information, or whether the current interface still matches the recording. Treat every generated sentence as a claim to verify.

• Give the tool one solved recording, not a folder of loosely related cases.
• Choose the documented output closest to task instructions when that option is available.
• Keep the timestamp map beside the draft so omissions are visible.
• Verify names, labels, roles, prerequisites, and expected results in the current product.
• Remove unsupported certainty. Replace “always” and “everyone” with the actual scope.
• Route the result through the same editorial and product review as a manually written article.

Manual extraction works when automation is unavailable or unsuitable

You do not need an automated workflow to make a strong article. Open the recording and transcript side by side. Read once for the problem and result. On the second pass, collect verbs: open, choose, confirm, retry, download. On the third pass, collect conditions: administrator access, supported file type, project membership, available storage, or any configuration that changes the path.

Then compare the transcript with the screen. Speech is often imprecise. An agent may say “go to settings” while opening a project-level permissions page, or say “click the export option” after using a keyboard shortcut. The instruction should describe the tested action, not merely repeat the narration.

Manual extraction is also the safer choice when the recording contains material that should not enter another processing workflow, when policy requires a particular editor, or when the output needs careful technical interpretation. Follow your organization’s approved handling rules for recordings and transcripts.

Turn conversation into task instructions

Support narration is written for one person in one moment. Knowledge base instructions are written for a stranger arriving later. Remove greetings, reassurance, ticket history, dead ends, and references such as “the button over here.” Keep the reason for the task, the exact action, and the signal that proves it worked.

Start each numbered step with a verb. Keep one main action in each step. Name the location before the control, and put conditions before irreversible actions. If a person needs a particular role, say so before they reach a disabled control. If a setting changes access for other people, state that consequence next to the step.

Choose screenshots that prove location or state

A screenshot earns its place when it answers a question the text cannot answer quickly: Which project is selected? Where is the permission section? What does the successful result look like? Do not capture every click. Repeated full-screen images slow the reader down and create more material to maintain.

Recreate screenshots with synthetic data and the role the article describes. Crop to the relevant region while keeping enough context to orient the reader. Use callouts sparingly. A bright arrow cannot rescue an image whose menu, account, or product version is wrong.

Write alt text around the information the image contributes, such as “Project access settings with export permission enabled for the member role.” Do not write “screenshot of step two.” The step number is already visible, and the reader needs the state shown in the image.

• Use the current interface and a clean test account.
• Exclude names, messages, tokens, private URLs, and unrelated tabs.
• Capture the smallest region that still provides orientation.
• Check text at the size used by the article template.
• Explain the same essential instruction in text, not only in the image.
• Record which product change should trigger a new screenshot.

Add troubleshooting and escalation before the reader needs them

The successful path is rarely enough for a support article. Ask what could make each important step unavailable or produce a different result. Common branches include the wrong account role, a missing workspace setting, an unsupported file type, a browser restriction, a feature not enabled for the workspace, or a product state that differs from the example.

Write branches as checks, not guesses. “If Export is unavailable, confirm your role and ask a workspace administrator to review export access” is actionable. “The app is probably broken” is not. If the source recording does not cover a branch, verify it with the product owner or send the reader to support with a defined evidence request.

Escalation instructions should say what to include: the exact error, timestamp with time zone, role, environment, relevant item type, steps already tried, and a safe screenshot or recording when permitted. Never ask readers to send passwords, authentication codes, secret keys, or an unrestricted full-screen capture.

Before and after: the export-permission example

The “before” version below is plausible support narration, but it is not publishable documentation. The “after” version separates authorization, action, verification, and failure handling. All names and values are synthetic.

Check permissions, accuracy, accessibility, and ownership

Run four reviews before the article leaves draft. The permission review asks whether the reader is allowed to perform the task and whether the instructions could expand access. The accuracy review repeats the steps in a clean test account. The accessibility review checks heading order, readable text, descriptive links, alt text, captions or transcript support, and whether essential information exists outside images and video.

The ownership review prevents the article from becoming an orphan. Name a person or team, not “support” in the abstract. Set a review date and define update triggers: a renamed navigation path, changed role model, new failure code, revised policy, or product release that changes the result.

Keep source evidence under its original retention and access policy. Publishing an article does not automatically justify retaining a customer recording forever, and deleting the recording does not remove the obligation to keep the maintained article accurate.

Knowledge base readiness checklist

For the page structure itself, use Zight’s step-by-step guide workflow. For broader maintenance habits, see how to improve documentation. Store related approved material in organized collections so agents can find the maintained answer instead of copying old ticket notes.

• The article answers one task for a named audience.
• The source issue was solved and the result was reproduced.
• Customer names, account details, ticket IDs, private URLs, and spoken identifiers are absent.
• The example uses synthetic or otherwise approved data.
• Prerequisites appear before the first action.
• Every numbered step contains one clear main action.
• Interface labels were checked in the current product; unknown labels were not guessed.
• Screenshots show only useful context and include accurate alt text.
• The expected result is specific enough to test.
• Missing controls, denied permissions, and different results have useful branches.
• Escalation instructions request safe diagnostic facts, not credentials or unrestricted evidence.
• Plan, role, or configuration limits are stated when they affect the path.
• A product or support owner reviewed technical accuracy.
• An editor checked clarity, links, headings, and accessibility.
• The article has an owner, review date, and update triggers.
• Publication follows the team’s normal approval workflow rather than an unrestricted automatic publish step.

Frequently asked questions