Recorded product demos, sales calls, and user interviews pile up fast â and nobody has time to rewatch forty hours of video to find every time a customer mentioned the same pain point. Convert them to text once, and searching for a pattern across all of them takes minutes instead of days.
Where this fits
This works for any video content hosted on YouTube, including unlisted videos your team uploads for internal review: product demo recordings, user interview sessions, competitor demo walkthroughs, or customer call recaps. Submit them as a batch the same way you would any other set of videos.
Worked example
Say your team has ten user interview recordings uploaded as unlisted YouTube videos (a placeholder scenario â any set of video URLs works the same way). Instead of submitting each one separately, submit all ten URLs in a single mixed batch â see mixing videos, playlists, and channels in one request for the exact format for combining different input types in one submission.
What to do with the text once you have it
- Search across every interview at once. Export the whole batch as one JSONL file and search for a keyword â a feature name, a complaint, a competitor's name â across every session in one pass. See searching inside transcripts for the approaches that work without a built-in search feature.
- Pull exact quotes with timestamps. The JSONL export itself is plain text, one line per recording, but every transcript also stores timed segments â once you've found a quote worth including in a research summary, fetch that recording's segments with
include_segments=true(or its SRT) to get the exact moment to jump back to. - Tag by project. Use
external_idon the batch request to label which research project or demo round a set of recordings belongs to, so you can pull them back up later without re-submitting anything.
How to do it in Scriptube
Dashboard: paste all your recording URLs into one batch submission and tag it with a project name if the dashboard offers a label field.
API: submit the full set of recordings in one request, tagged for the project:
curl -X POST https://scriptube.me/api/v1/transcripts \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"urls": [
"https://www.youtube.com/watch?v=VIDEO_ID_1",
"https://www.youtube.com/watch?v=VIDEO_ID_2",
"https://www.youtube.com/watch?v=VIDEO_ID_3"
],
"external_id": "interview-round-3"
}'
For the full pattern of tagging and retrieving batches by project, see tagging batches with external_id and metadata. Once processed, export everything as JSONL (one line of plain text per recording) for keyword search:
curl "https://scriptube.me/api/v1/transcripts/BATCH_ID/export?format=jsonl" \
-H "X-API-Key: YOUR_API_KEY" -o interview-round-3.jsonl
A concrete example: tracking one feature request
Say three separate customer calls mention the same missing feature, but nobody remembers which calls or in what words. With all three recordings processed and exported as JSONL, searching the combined file for the feature's name (and likely synonyms customers might use for it) surfaces every mention at once, each tied to its source recording. Pull the matching recording's segments with include_segments=true to get the exact timestamp of each mention. That turns a vague "a few customers have asked about this" into a specific, citable list of exactly who said what and when â useful for prioritization conversations where specifics carry more weight than impressions.
Keeping speaker context straight
A transcript on its own doesn't label who's speaking â interviewer versus interviewee, or presenter versus customer on a demo call. Use the video's title or the external_id tag to record which session a transcript came from, and keep a simple key (a spreadsheet mapping video ID to participant name or role) alongside your exports if attribution matters for how you'll use the quotes later.
Respecting consent before you process recordings
If the recordings are user interviews or customer calls, make sure whatever consent was given for the recording also covers running it through a third-party transcription tool and storing the resulting text. This is a process question for your team to handle, not something Scriptube enforces on your behalf â treat transcript processing as an extension of however you already handle the recording itself.
Turning findings into a shareable summary
Raw transcripts are a research tool, not a deliverable. Once you've found the patterns you're looking for, pull the specific quotes and timestamps that support each finding into a short summary document for the rest of the team â a handful of well-chosen, timestamped quotes make a stronger case in a product review meeting than a link to forty transcripts nobody has time to read.
What this isn't a substitute for
Searching transcripts surfaces what people said; it doesn't replace the judgment of someone who was in the room for tone, hesitation, or things left unsaid. Treat a keyword search across transcripts as a way to find candidates worth a closer listen, not as a finished analysis on its own â especially for anything nuanced enough that the exact wording matters less than how it was said.
Combining research across teams
Sales, support, and product teams often record separate but related conversations with the same customers. If recordings from more than one team end up in the same Scriptube account, a shared library and a consistent external_id naming convention make it possible to search across all of them together instead of each team working from its own isolated set of transcripts.
Scaling it up
If your research library grows past a handful of sessions, everything you've processed stays browsable in your transcript library rather than scattered across individual exports â useful when a new team member needs to search past interviews without re-running anything. Because old batches stay searchable, checking whether a new feature idea was already mentioned in past research takes a search, not a request to dig through an old recordings folder.
Sign up free and turn your next batch of recordings into searchable text.