Knowledge base videos: where they help and how to add them

A help article with a short video at the top can answer questions text alone keeps failing to. A help center stuffed with videos nobody can search is a step backwards. The difference is mostly which articles you pick and what text stays on the page.

By the VeoRec team · Oct 3, 2026 · 12 min read

Most help centers start adding knowledge base videos for the same reason: a handful of articles keep generating tickets even though the written steps are correct. Customers read "open the Integrations tab and click Connect next to your calendar provider" and still cannot find it, because the tab is collapsed on their screen or the button only appears on hover. A 90 second recording of the same steps fixes that.

The risk is overcorrecting. A help center where every article is a video is slow to skim, hard to search and painful for anyone who cannot or will not play sound. Video earns its place on a minority of articles, and only when it sits in the right spot on the page, carries accurate captions and has the same steps written out beside it. The rest of the work is keeping the two in step after every release, which is where most help centers quietly fail.

Which articles need a video, and which do not

Look at the article types in your help center rather than at individual articles. Some types almost always benefit from a short recording; others never do.

To find the specific articles to start with, combine two signals: articles with a lot of traffic and low "was this helpful?" scores, and articles customers link to when they open a ticket anyway ("I read your article but I still can't find it"). Those are the pages where text is not doing the job on its own.

Keep the text complete; the video sits beside it

The single most important rule: the written article must answer the question with the video switched off. In a usability study of instructional content, the Nielsen Norman Group saw three distinct behaviors: some people avoided video entirely and read, some skimmed the text and watched the video to confirm, and some went straight to the video. Their guideline is to provide video as a supplement and never as the only source of the information (Videos as Instructional Content).

There are practical reasons too. Customers read help articles on phones in places where they cannot play sound. Screen reader users get nothing from a video without a text equivalent. People copy values from articles: an API endpoint, a date format, a DNS record. And your support agents paste article links into tickets expecting the customer to find the answer in seconds.

Reading and watching also take different amounts of time for the same content. Try it with the length of a typical help article: the widget below compares reading time with speaking time for the same number of words.

For a reference answer, reading wins easily. For a procedure where the reader would otherwise reread steps three times while hunting for buttons, the video's extra minute is a good trade. That is the whole case for video in a help center in one comparison.

Put the video at the top of what it covers

Placement decides whether anyone watches. The same Nielsen Norman Group study found that videos at the top of a page were watched most, that videos at the bottom were often missed because people stop scrolling once they find their answer, and that videos in a right-hand column were consistently overlooked.

• One video for the whole article: place it directly under the title and the one-line summary, above the steps.
• One video per section: place each at the top of its section, under the section heading, so it is clear which steps it covers.
• Never at the very bottom ("Prefer video? Watch here") or in a sidebar.
• Show the length in the caption or next to the player: "Video, 1 min 30 s". People decide whether to watch based on it.
• Say what it covers in one line: "Watch the steps below on a demo account."

How many videos per article? For most procedures, one. Split into section videos only when the article covers genuinely separate stages (connect the account, then configure it, then test it) that readers often do on different days. Three short videos with clear headings are easier to come back to than one long one where the reader has to scrub to find where they left off.

Avoid autoplay. A help article that starts talking when it loads is jarring, especially for people using a screen reader whose speech it talks over. Let the reader choose.

Embed it properly, or link when an embed will not work

Most help center editors accept either an iframe embed code or a video URL that they turn into a player; check your tool's documentation for which it supports. Use the embed so the video plays inside the article; sending readers off to a separate video page breaks their flow and their place in the steps.

Check a few details when you embed:

• Responsive width. The player should shrink with the article on a phone. Most embed codes do this; some fixed-width ones overflow.
• A meaningful thumbnail. The first frame is often a blank loading screen. Pick a frame that shows the screen where the task happens.
• Captions on by default where possible, or at least easy to switch on.
• Lazy loading. Several embedded players on one page can slow it down. If you are not sure how your help center handles it, keep it to one or two videos per article.
• Access. Knowledge base videos must play for anyone who can read the article. A link that asks viewers to sign in, enter a password or give an email defeats the purpose on a public help center.

With VeoRec, each recording has embed code and a plain share link, and viewers need no account. Pro adds password protection and an email gate, which are useful for client work and sales follow-ups but are the wrong choice for public help articles. Keep knowledge base videos on open links.

If your help center is public and you care about search traffic, Google's video guidance is worth reading. It asks for the video to be embedded with a standard HTML element (video, embed, iframe or object), for a valid thumbnail, for a page title and description unique to that video, and for structured data that matches the video and the rest of its metadata (Google Search Central, video best practices). An article with one video, a specific title and written steps is already most of the way there.

Captions are part of the article, not an extra

Under WCAG, prerecorded video with audio needs captions at Level A, the most basic level (Understanding SC 1.2.2, Captions (Prerecorded)). If your organization has an accessibility commitment, help center videos are almost certainly in scope. Even without one, captions help a lot of people: anyone in an open office without headphones, anyone more comfortable reading English than listening to it, anyone who is deaf or hard of hearing.

Automatic captions are a good start but not a finish. W3C's guidance on captions is blunt: automatically generated captions do not meet user needs or accessibility requirements unless they are confirmed to be fully accurate (W3C WAI, Captions/Subtitles). In product videos the usual errors are product names, feature names and numbers, which are exactly the words that matter. Watch with captions on once before publishing.

Every VeoRec recording gets automatic captions and a transcript on the Free plan, and Pro adds caption and transcript translation, which helps if your help center serves several languages. Whatever tool you use, the habit is the same: read them before the article goes live. Screen recording accessibility covers captions, transcripts and contrast in more depth.

Transcripts and written steps make the video searchable

Help center search indexes text. So do search engines. Neither listens to your video. If the only place the phrase "export to CSV" appears is in the narration, nobody searching for it will find the article.

This is the strongest practical argument for the written steps, but a transcript adds something steps do not: the exact phrases a person uses when explaining the task out loud, which are often closer to how customers search than your interface labels are. Two ways to use it:

• Steps on the page, transcript linked. The article shows clean numbered steps; a "Read the transcript" toggle or link below the video holds the full text. Good for most procedures.
• Transcript as the article. For concept explainers, a lightly edited transcript with headings can be the article itself. Remove filler words, add headings at topic changes, and add any visual information the narration did not say out loud.

That last point has a name. W3C distinguishes a basic transcript (the speech and important sounds) from a descriptive transcript, which also includes the visual information needed to understand the content (W3C WAI, Transcripts). If your narration says "click Connect" but never mentions that Connect is under the More menu, the transcript should. The simplest fix is upstream: narrate the location as you record, so the words are already there.

Transcripts also help internally. When support agents need to find the right video mid-ticket, searching what was said is faster than guessing titles. In VeoRec you can search the transcripts across your whole library; whichever tool you use, make sure the people sending links can search inside videos, not only their names.

Write the article so the video and text match

The easiest way to keep video and text consistent is to write them from the same outline. Draft the steps first, record the video following them, then adjust the steps if you changed something while recording. These templates give you a skeleton for a procedure article, a "where is it?" article, and the short caption that sits under every embed.

One article, rebuilt around a video

Take an article called "Connect your Google Calendar" that gets plenty of traffic, a poor helpfulness score and a steady trickle of tickets saying "there is no Connect button". The steps are correct. The problem, when someone finally watches a customer try it, is that the Integrations page lists calendars under a collapsed More integrations group on smaller screens, and the article never mentions it.

The fix has three parts, in this order. First the text: step 2 becomes "Open Integrations and expand More integrations if you do not see Calendars". Then the recording, 70 seconds on a demo account at a laptop-sized window, narrating the collapsed group out loud so the captions and transcript carry it too. Then the page: the video goes under the one-line summary with "Video, 1 min 10 s" beside it, the steps stay below, and the article gets a Last checked date.

Notice that the most valuable change was a sentence of text, found because someone made a video. That happens often. Recording forces you to walk the path on a real screen, and the gaps in the written steps show up on the way.

Note the "Last checked" line in the procedure template. It tells readers how fresh the article is, and it tells your team when it was last compared against the product.

Keep video and text in sync after every release

A text article with an outdated label is a one-minute fix. An outdated video means re-recording. That asymmetry is why help centers with lots of video tend to rot faster than text-only ones, and why you need a process before you need it.

Record so that updates are cheap

Some choices at recording time decide how painful the next update will be. Make them deliberately.

• One clip per section for long articles. If step 4 of a nine-step setup changes, you re-record a 30 second clip, not a four minute video.
• The same demo account and browser setup every time. Same zoom level, same window size, same sample data. A re-recorded clip then looks like it belongs next to the old ones.
• No dates, version numbers or "new" in the narration. "The new Reports page" is wrong within a year. Describe what is on screen instead.
• No faces in reference videos. A help article video that shows a colleague who has since left the company has to be redone for no product reason.
• Keep the outline. Save the bullet outline you recorded from next to the article draft. Whoever re-records next year will thank you.

The inventory in the last item is a simple list: article, video link, product area, date recorded, owner. When release notes touch a product area, the owner checks the videos for that area before the release goes out. Re-record when the starting screen or the path changes; for small label changes, update the text and add a note under the player ("The button is now called Export, the video shows its old name") until you re-record. That note is honest and buys time.

Measure whether the videos help

You added video to reduce confusion. Check whether it did, per article, a month after publishing.

• Helpfulness votes on the article before and after the video was added.
• Tickets that link the article. If customers still open tickets after reading it, the video is not answering their question, or they are not finding it.
• Search terms with no results in your help center. They tell you which phrases to add to the text and, sometimes, which videos you still need.
• Viewing depth. Some tools show how far people watched. VeoRec Pro has viewer analytics: how many viewers and how far each one got. If most stop before the step that matters, shorten the opening or split the video.

Be careful with raw view counts. A video with many plays on an article that still generates tickets is not a success; it may mean people watch, fail, and write in anyway. The ticket and helpfulness numbers are the ones that tell you whether the customer got unstuck.

Expect mixed results, and treat them as information. A video that does not move the numbers on a reference article is a sign that article never needed one; take it down and keep the help center lighter.

A plan for your first ten knowledge base videos

1. Pick ten articles Procedures and "where is it?" articles with high traffic and low helpfulness, or that customers mention in tickets.
2. Tighten the text first Fix the written steps so they are complete on their own. You will record from them.
3. Record each one in a demo account One task per video, under two minutes, naming every control by its label as you click it. How to make tutorial videos covers the recording process.
4. Check captions and add the text Fix wrong product names and numbers, then put the steps or a cleaned transcript on the page.
5. Embed at the top With the length and a one-line description, on an open link, with a thumbnail that shows the right screen.
6. Add them to the inventory and set owners Product area, date, owner. Review on every release that touches the area.
7. Check the numbers after a month Keep the videos that helped, remove the ones that did not, and pick the next ten. Your support team's reusable support videos are often the best candidates.

Record help center videos with captions built in VeoRec adds captions and a transcript to every recording, gives you embed code and an open share link, and lets your team search what was said across the library. See VeoRec for support teams