Release notes are written for scanning. They list what changed, link to tickets, and preserve a record of a shipped version. Tutorial audio has a different job: it helps someone complete a task without translating engineering shorthand in their head.
That difference matters. Reading a changelog aloud creates a dense list of feature names. A useful product tutorial says who the change affects, when to use it, where to start, what to do, and how to know it worked. In Vois, that human-approved script can become a consistent, versioned tutorial recording without detaching the audio from its source release notes.
Select changes that alter a user task
Do not make audio for every item in a release. Start with the changes that require a customer, administrator, or teammate to do something differently. A good candidate usually affects a goal, a sequence of clicks, a permission, a default, a migration, or a common support question.
Use a small triage table during release planning:
| Release note item | User impact | Tutorial decision | Why |
|---|---|---|---|
| New saved-filter control | Users can repeat a search | Create a short walkthrough | A new action and confirmation state exist |
| Renamed settings area | Existing instructions may no longer match | Update affected tutorial | The navigation path changed |
| Internal query optimization | No visible behavior | Keep in release notes only | No learner task changed |
| New role permission | Administrators must configure access | Create an admin tutorial | The audience has a new setup responsibility |
Ask one practical question: "What would a person do differently after this release?" If the answer is concrete, there is a tutorial-shaped story. If the answer is "nothing visible," keep it in the changelog and move on.
This focus also keeps the audio library useful. A customer looking for help should find a clearly named tutorial for a task, not a long recording that mixes unrelated fixes, internal performance changes, and new controls.
Build a release-to-tutorial brief before writing prose
A short brief protects the script from guesswork. It also gives a reviewer enough context to approve the audio without reconstructing the release from scratch.
For each tutorial, capture:
- the exact release version and release date
- the canonical release-notes URL and heading anchor
- the affected audience and their prerequisite access
- the task the listener should complete
- the product area and starting state
- the expected result or confirmation
- the source screenshots, help article, or shipped build used for review
- the planned destination, such as a help center article, in-app learning area, or customer email
Treat the release note as a source link, not the only source. A terse note such as "Added saved filters" may be accurate but insufficient for a tutorial. The writer still needs to inspect the shipped UI or approved product documentation to know the exact labels, order, and result.
Transform a changelog entry into spoken instruction
A concise tutorial usually follows a simple sequence: context, action, confirmation, and next step. Keep one user outcome per recording whenever possible.
| Changelog wording | Tutorial wording |
|---|---|
| "Added saved filters" | "To reuse a filter, open the filters panel, choose the criteria you need, then select Save filter. Give it a name you will recognize later. Your saved filter appears in the Saved list." |
| "Renamed Team settings to Workspace settings" | "If you are looking for Team settings, open Settings and choose Workspace. The controls are the same, but the section now uses the Workspace name." |
| "Added a role permission" | "Administrators can now decide who may export reports. Open Workspace, choose Roles, select the role, then enable Export reports." |
The second column is not a longer release note. It removes internal shorthand, turns an event into an action, and tells the listener what to expect. Avoid claims that are not in the approved source. If you cannot verify a label, requirement, or outcome in the product, leave it out until a product owner confirms it.
Read the draft aloud before generation. Written sentences often stack clauses that work on a page but become hard to follow in audio. Use short, direct sentences. Name the current screen before instructing a click. Put a pause between actions that need a visual check.
For broader scripting techniques, the AI voiceover SaaS product demos guide is a useful companion. The important boundary is intent: this workflow begins with release notes and creates a version-specific tutorial, not a general product demo.
Let an agent prepare the draft, then require human approval
An agent can be helpful at the mechanical parts of the job. With access to the approved release notes and product documentation, it can identify candidate items, create a draft brief, group related changes, prepare a first spoken script, and collect links for review. The Vois CLI and AI agent integration guide explains how an agent can work with the running desktop app.
It should not be the final authority on product behavior. Release notes can omit a prerequisite, simplify an edge case, or assume internal vocabulary. Before any audio is published, a human who knows the shipped product should verify the script against the release notes and the actual interface.
Use an explicit approval gate:
- A product owner or release manager confirms the changes selected for narration.
- A technical writer, support lead, or educator checks the sequence, labels, and audience framing.
- A product reviewer verifies the script against the shipped version.
- The narrator or producer generates the approved text and checks the resulting audio.
- The distribution owner confirms the final page, transcript, version label, and release-notes link.
The Vois CLI and AI agent integration guide explains how agents can load the hosted CLI skill. Keep the agent's draft and the human-approved version distinct in your workflow so nobody mistakes a proposed instruction for a product fact.
Carry the version label through every surface
A tutorial with no version context ages badly. Say the version near the beginning when it helps the listener, and show it in the title, filename, embed description, transcript, and release-notes link. For example: "Saved filters in version 4.2" is much easier to evaluate than "Saved filters tutorial."
Semantic Versioning offers a familiar MAJOR.MINOR.PATCH convention for software that uses it, but use the version system your product actually publishes. Do not invent a semantic version just because it looks tidy.
Add an end note in the companion page or description that names the covered version and links directly to that release's canonical notes. If the release record does not have a stable link, create one before publishing a version-specific tutorial. When behavior changes, update the tutorial's status and link to the newer one rather than quietly overwriting the older context.
The changelog link does two things: it gives a listener the full technical record, and it gives support or documentation teams a starting point when the audio needs revision.
Set pronunciation before you generate
New releases often introduce names that narration mishandles: product areas, acronyms, API names, partner names, or technical terms. Collect them during the brief, agree on a spoken form with the product team, and add them to the Vois pronunciation dictionary before recording the final audio.
Prompt your agent
From the approved release brief, list every product name, acronym, partner name, and technical term that may need pronunciation guidance. Propose a written-to-spoken rule for each term, including "nginx" as "engine-x" only if the product team approves it. Show the proposed dictionary changes in a reviewable table. Do not apply a rule or import a shared dictionary until a named reviewer approves the terms and scope.
Use this review flow:
- The agent presents the proposed terms, spoken forms, scope, and source link for each rule.
- A product owner or terminology owner approves, changes, or rejects every proposed form.
- The producer adds only approved rules to the relevant Vois dictionary and records the dictionary revision with the tutorial.
- The reviewer listens to each affected term in the generated context, not in isolation.
- The distribution owner confirms that the approved script, dictionary revision, and final audio stay together in the release package.
Treat a global dictionary carefully. A pronunciation that is right for one product line may be wrong in another context. Keep the approved source alongside the dictionary revision. The pronunciation dictionary guide covers the operational workflow in more detail.
Generate with the running desktop app
Vois can generate the approved narration through the running desktop app, with the saved voice and production settings for the tutorial series. The agent should prepare the work, but it must not decide which source is authoritative or publish an unreviewed result.
Prompt your agent
Using the human-approved script for the named release version, prepare a Vois narration job with the saved tutorial voice profile, approved pronunciation dictionary revision, and the series export settings. Name the draft audio with the release version and tutorial topic. Before generating, show the source script, voice profile, dictionary revision, target format, and destination for human approval. Do not publish, overwrite an earlier tutorial, or change the approved wording.
Use this review and publish flow:
- The agent presents the proposed job details and a link to the approved script.
- The producer confirms the running Vois app, the selected voice profile, and the release-specific output name.
- The product reviewer approves the exact script and the producer generates a draft.
- A reviewer listens while following the shipped interface, then compares the audio and transcript to the approved script.
- The distribution owner publishes the approved audio with its version label, transcript, release-notes link, and replacement status.
Keep a simple voice reference for the tutorial series: voice profile, language, engine choice, speed, pronunciation dictionary revision, mastering settings, and export format. That reference makes a later patch tutorial sound like it belongs beside its earlier release.
Review the result against the shipped interface
Listen while following the script in the product. Check every menu name, button, field, prerequisite, and success state. Watch for a stale label, a missing permission, a sentence that implies a default, or a pronunciation that sounds acceptable in isolation but wrong in the product vocabulary.
Then compare the audio and transcript to the approved script. If a screen recording or screenshot accompanies the tutorial, verify that it shows the same release version. A version label cannot rescue contradictory instructions.
Hand off a small distribution package
Do not send a single audio file to the publishing team and assume the context will survive. Hand off a package with the audio file, approved transcript, title, version label, release date, release-notes URL, destination, voice-profile reference, and reviewer sign-off. Include a replacement or retirement instruction if this tutorial supersedes an older one.
The distribution owner can then attach the audio to the appropriate help article, documentation update, release announcement, or in-product learning surface. Keep the link to the changelog close to the tutorial so a listener can see the broader release and any related changes.
Sources
- Google developer documentation style guide, What's new
- Semantic Versioning 2.0.0
- GitHub Docs, About releases
- Vois CLI skill reference
A good release tutorial gives users a clear next action and a reliable trail back to the version that introduced it. Explore Vois CLI automation, then get started when your team is ready to turn approved release changes into reviewable tutorial audio.
The Vois Team