Why ChatGPT or Claude can't turn a video recording into help docs

A 60-minute Product call recording on new releases uploaded to Pageloop = 3 new help docs and suggested updates to 7 existing ones.

That feature had the fastest adoption of any we've shipped so far, and I think I know why. New features get explained in long recorded calls: product demos, enablement sessions, release walkthroughs. Turning one of those recordings into help articles means rewatching it, screenshotting by hand and working out what to write, one feature at a time.

The short answer is to treat a recording as a list of features and never as one big article. For each feature on the call, decide whether it needs a new article, an update to an existing one, or both. Pull only the screenshots that matter, give your drafting tool the transcript and those screens, and review every article and update together before anything goes live.

Why you can't just paste a long recording into Claude

The feature started with a request in a shared Slack channel. A user asked for video-to-docs, and we asked them to send a sample meeting recording.

When the video link came, it was 72 minutes long. We quickly understood why they couldn't 'just use Claude' for this.

One of our engineers watched the full video and said it would only be possible with a pretty big change to our agent architecture. The recording covered 4 new features plus enhancements to existing ones. To turn that into good docs, a tool has to use the transcript, the clicks AND the video to understand each feature. It has to grab screenshots of the most appropriate screens, because we don't want 87 screenshots in the article. It has to figure out which features need a new article, an update, or both. And then it has to output all the new articles and updates for review, together.

A general chat assistant can summarize a transcript. Making those four calls across your existing help center is a different job, because it has to know what your help center already says.

Before we started building, we wrote to some existing customers about it. I kid you not, they were over the moon. After I was done being mad at myself for not thinking of this feature sooner, we got to building.

It was also the first feature we couldn't test internally, because we didn't have a 70+ minute product walkthrough of our own. We ran it on multiple demo recordings instead.

What the manual process looks like

A customer is spending 3 hours doing something that takes 3 minutes.

That's what I learned 2 full months after we released video-to-docs. One of our customers had an hour-long enablement call to turn into documentation, and this was their process:

1. Decide if an article should be created or updated.

2. Open the recording and take screenshots for that first feature.

3. Feed the PRD and screenshots to Pageloop.

4. Repeat this for as many features as the hour-long enablement call covered, one after another, until the whole recording was done.

They were doing it the long way because they didn't know the feature existed. We'd announced it the way we announce everything: a Canvas in each customer's Slack channel and a new item on our website changelog. Now, who reads Canvas updates and website changelogs? Clearly not enough people.

I was SO disappointed to hear this. Pouring ourselves into building each feature and our own customers don't know.

That one's on us, and we started building a release announcement agent that tags the right people when a feature is relevant to them. But their four steps are a pretty accurate picture of the manual way, so they're the right place to start.

How to turn a recording into help docs, step by step

You can do this with or without a dedicated tool. Here's the version I'd follow, built on what that customer was already doing and what we learned building the feature:

1. List every feature the recording covers. Skim the transcript and write down each feature or enhancement discussed, with rough timestamps. A 72-minute call can easily hold four or more.

2. Make the new-or-update call per feature. Search your help center for each one. Some need a new article, some need an update to an existing one, and some need both.

3. Screenshot only the screens that matter. One per key step is usually plenty.

4. Draft with the full context. Give your drafting tool the transcript, the PRD if you have one and your screenshots, one feature at a time.

5. Review everything together. Read the new articles and the updates side by side, so the help center reads as one cohesive update and not as four separate ones. Fewer screenshots also means less to maintain the next time the UI changes, so this is a good moment to cut any you added out of habit.

If you're drafting with Claude or ChatGPT, step 2 is where it gets slow, because the model has never seen your help center. We wrote up that setup, and where it stops keeping up, in can Claude or ChatGPT keep your product documentation up to date?

Where Pageloop fits

Okay, here comes the plug, but I'll keep it short.

Pageloop's video upload does those five steps in one pass. You upload the recording (MP4, MOV, WebM or AVI, up to 2GB), add a title and optional notes about what the call focuses on, and Pageloop works out which features need new articles and which existing articles need updates. Screenshots come from the recording itself, picked for the screens that matter. New articles land in your Articles tab and updates in your Updates tab, and nothing goes live until a person reviews it.

We keep widening what Pageloop can take in: support tickets, Slack threads, Jira and Linear tickets, GitHub PRs, and now very long meeting recordings. Whatever you throw at it, Pageloop will turn it into a cohesive documentation update. Cohesive being the keyword.

Photo by National Gallery of Art on Unsplash
Cliffs at Pourville 1882 Claude Monet