Video knowledge base: how to build one customers actually use

A typical video help center has a hundred videos, a grid of thumbnails and a search box that only matches titles. Customers scroll the grid, pick the one with the friendliest thumbnail, watch two minutes of a product tour and open a support ticket anyway. The videos aren’t bad. The library was organized around the product’s features, while customers bring questions to support, and nothing in the library connects one to the other.

A video knowledge base works when it’s built the other way round. This is a playbook for doing that, from the first twenty videos to the review routine that keeps them accurate.

Video knowledge base: organize by the question, not the feature

Customers search with a problem in their own words. They type “why can’t my teammate see the project,” not “permissions matrix.” If your library is organized by the features in your settings menu, the customer has to translate their problem into your vocabulary before they can find an answer, and most won’t bother.

Start from your support data. Pull the last ninety days of tickets, group them by topic, and count. Support tickets are the most honest list of what customers actually need, and in most products a small set of topics accounts for a large share of the volume. Those topics become your first videos.

The titles should copy the customer’s phrasing, not your internal naming.

The left column is accurate and useless to a customer. The right column is what they’d type, and when the title matches the query, the video is far more likely to be found and clicked. It also sets an expectation: the viewer knows the video answers exactly one question.

Mine the search terms customers already use

Titles work best when they match the words people type, and the best source for those words is data you already have. Start with three places. Your help center search log, if you have one, shows the exact queries customers enter, including the ones that returned nothing. Your support ticket subject lines show how customers describe a problem before an agent has translated it. Chat transcripts and sales call notes show the objections and confusion that come up before anyone opens a ticket.

Read those sources for phrasing, not just topics. “Invite” and “add a user” can describe the same task, but customers search with whichever word they learned from your marketing, or from a competitor’s, and sometimes both. A description that uses the second phrasing alongside the first can catch searches the title alone would miss, without the title turning into a keyword list.

Keep a running list of the phrasings that show up most often, grouped by topic. When you write the next video, start from that list rather than from the feature name in your settings menu. Over a few months, the list becomes the most accurate map of your library you’ll ever have.

One answer per video

The biggest structural mistake in video help is the multi-topic video. A single video that covers roles, invitations and the audit log may be searchable, but a customer only needs one of those things. They’ll watch the first part, miss the one they came for, and assume the video doesn’t help.

Keep each video to one answer. Two questions, two videos. Aim for sixty to a hundred and twenty seconds, which is long enough to show a complete task and short enough that a customer under pressure will finish it. If a single answer needs more than three minutes, it’s probably two answers in a row. Split them, or add chapters so the viewer can jump to the step they need. The reasoning behind that length is in how long a tutorial should run.

At the end of each video, link to one or two related questions, not a whole menu. A menu at the end of a video asks the viewer to make another decision, and most customers have already decided to leave.

Make it findable, which means writing it down

Video search is weak. Most help centers match the title and little else, so the words around the video do most of the work. Four pieces of text make a video findable.

The title is the question the customer types. The first sentence of the description should restate the answer in plain language, so a search result shows the answer before the click. The chapter titles should name the steps as the customer would look for them, such as “Add a card to an invoice” rather than “Step 3.” The transcript gives the page words that describe what’s on screen, which helps readers who prefer text and gives search engines something to read.

Captions are the transcript’s partner. A customer who is listening to the video in a noisy office, or watching with the sound off, needs the captions to follow the steps. If you’re unsure what good captioning looks like in practice, video captions and how to do them well covers the basics.

Here’s a practical test. Read the title, the first sentence, the chapter list and the transcript without the video. If a customer could complete the task from that text alone, you’ve made a findable page. If the text is vague, the video is carrying more than it should.

The naming convention that survives a year

Libraries decay through inconsistent names. After a year, you have “Invoice card change,” “Change card (old),” and “Billing - update payment,” and nobody can tell which one to point a customer to. A convention prevents that.

Use the same pattern for every title: the area first, then the question. “Billing: change the card on an invoice.” “Team: invite a member and set access.” The area prefix makes the library browsable by section, and the consistent question format keeps the search results uniform.

Keep dates and version numbers out of titles. A title that says “(v3.2)” becomes wrong the moment the product ships v3.3, and you have to rename it. Record the interface version in the description or the metadata instead. Titles stay stable while the content inside can change.

Keep it current: the stale-video problem

A video knowledge base fails in one specific, avoidable way: the product changes and the video doesn’t. A button moves, a menu gets renamed, and the video shows the old path. The customer follows it, can’t find the button, and now distrusts the whole library, including the videos that are still correct.

The fix is to tie each video to the screens it shows. Keep a short list next to each video of the product areas it covers, such as “invoice settings,” “payment methods,” and “team members.” When a release touches one of those areas, the videos that depend on it go into a re-record queue before the release ships, or as soon as possible after.

Review the top twenty videos every quarter, even without a release. Check the ticket volume for each topic, and check whether the video still matches the current interface. Retire the videos nobody watches, rather than letting them sit in the library as noise that makes the good ones harder to find.

Privacy: record the demo account, not your customers

Support videos are the place where real customer data most often ends up on screen. A walkthrough recorded in a live account can show an invoice with a customer’s name, an email address in the sidebar, a company logo, or a notification with a private message in it. Once the video is public, it’s public.

Record in a demo workspace with fake but realistic data. Use names and figures that look like a real business, so the video reads as credible, but that belong to nobody. Before you record, close the notification panel, hide the bookmark bar, and check the browser’s tab strip, which can reveal the account you’re signed into. A quick scan of the first and last frame catches most of the leaks.

Measure whether it works

Ticket deflection is hard to prove. A customer who watched a video and didn’t open a ticket is invisible, and a customer who opened a ticket anyway may still have benefited. So measure proxies, and compare like with like.

Track the ticket count for each topic before and after you publish its video, and compare the same month in the previous year if you have one. Seasonal spikes will distort a short comparison, so look for a sustained change rather than a single good week. Track views and completion on each video too, so you can tell a topic that’s still in demand from one that’s been answered. A video with high views and a steep drop in the first minute is usually a title that promises more than the video delivers.

Building the first twenty

Here’s the sequence that gets a library started without a month of planning.

1. Pull the last ninety days of tickets and group them by topic.
2. Choose the twenty topics with the most volume, and write each one as a customer’s question.
3. Set up a demo workspace with realistic data, and check it for leaks before you record anything.
4. Record each answer as one task, aiming for sixty to a hundred and twenty seconds.
5. Add captions, chapters and a transcript to each video, and write the first sentence of each description as the answer.
6. Map each video to the screens it shows, and add it to the release review list.

The loop then runs on its own. Tickets reveal new topics, new topics become questions, questions become videos, and releases send some of those videos back for re-recording. The diagram below shows the loop.

The loop is the part most libraries skip. They build the first twenty videos and then stop, and the library slowly drifts from the product it describes. A simple rule keeps it alive: no release ships without someone checking which videos touch the changed screens.

Who owns the library

A video library with no owner decays, and the owner doesn’t need to be a full-time producer. Give the role to someone who already sits close to support and the product, such as a support lead, a customer success manager, or a product marketer, and make it part of their job rather than a side project. The owner keeps the topic list current, approves new titles against the naming convention, and is the person a release manager tells when a screen changes.

Two things make the role workable. The first is a written list of which videos depend on which product areas, so the owner can answer “does this release affect anything we’ve published?” in minutes rather than days. The second is a rule that the owner can retire a video without a meeting when it has no traffic and no matching ticket topic. Without that permission, the library only grows.

Where the recording happens

Recording the demo workspace is quick once the setup is right. RecordlyPro records in your browser with nothing to install, zooms in on each click so the button label stays readable, and adds captions and chapters automatically, which removes two of the steps above. You still own the review. The tool can’t tell you that a menu was renamed in last month’s release, and it can’t tell you whether the account on screen is safe to show. For how the single-answer structure applies to a wider set of walkthroughs, how to record a software tutorial people actually finish covers the scripting side in more detail.

Keep reading

Playbook

Async video: stop scheduling the meeting you could record

A hundred random links can do less than five relevant ones. Here's what makes a backlink pass real ranking value in 2026 — and what makes it worthless or worse.

Sofia Meyer October 6, 20262 min read

Playbook

Auto-zoom in screen recordings: what it is and why your demos need it

A hundred random links can do less than five relevant ones. Here's what makes a backlink pass real ranking value in 2026 — and what makes it worthless or worse.

Sofia Meyer October 13, 20262 min read

Playbook

How to choose a screen recorder for product demos in 2026

A hundred random links can do less than five relevant ones. Here's what makes a backlink pass real ranking value in 2026 — and what makes it worthless or worse.

Sofia Meyer October 16, 20262 min read

Explainer

Dofollow vs nofollow in 2026: what still passes value

The link attributes changed, Google's treatment changed, and a lot of advice is out of date. Here's what dofollow, nofollow, sponsored and ugc actually do now.

The Recordly Team October 10, 20262 min read