A release goes out on Tuesday. On Wednesday a customer emails support to say the video tells them to click "Save changes", but the button now says "Update record". The walkthrough script still says the old name, so the video, the live guide and the help article all point to a button that no longer exists.
This happens to almost every product that ships regularly. The fix is rarely hard. The difficulty is noticing the problem before a customer does, and then getting the correction into all three outputs without rebuilding the lot.
A common scenario: the button label changes after a release
Suppose your script has twelve steps. Step seven says: click the button labelled "Save changes" in the top right. After a release, that button is labelled "Update record" and sits in the footer of the form. The step still makes sense to a person who knows the product, but the instruction no longer matches the screen.
HandHoldly runs a scheduled re-check every night. It walks through each step of your script against the live product and looks for the element the step describes. When a step no longer works, the re-check flags it, fires any webhooks you have set up, and emails the owners of the walkthrough with the step named. That last part matters. The email tells you which step broke, so you are not searching twelve steps for the one that changed.
A re-check flags a broken step. It does not fix the step on its own. The script stays as it was until someone reviews the flag and decides what to do.
With AI switched on, the button is found again
AI is optional. If you leave it off, the re-check still tells you which step failed, and you edit the step yourself. If you switch it on, the re-check goes a stage further. When a button has moved or been renamed, the AI looks at the page again, works out which control the step was describing, and proposes a replacement for the instruction. In the example above, it might suggest that step seven now refers to "Update record" in the footer.
Think of this as a drafted suggestion, not a verdict. It is a starting point for a person to check. It can be wrong, particularly where a page has several similar buttons or where the layout has changed a lot. Treat it the way you would treat a colleague's first pass: useful, worth reading, and not something to publish without looking.
Reviewing the suggested fix yourself
When the suggested fix arrives, open the step and compare it with the live product. Check three things.
First, does the new label match what is on screen? Look at the actual button, not just the text in the suggestion. Second, is the location right? If you say "in the top right" and the button is now in the footer, the instruction will still send people to the wrong place even if the name is correct. Third, does the step still do what the customer needs? A renamed button sometimes means a changed workflow, and the step may need an extra sentence to explain the new order.
A quick way to check is to run the step yourself in the product on a test account. Click through it once. If the result matches the words in the suggestion, you are ready to save. If not, edit the text until it does.
Saving the fix into the script with one click
Once you are happy with the wording, save it into the script with one click. That single change updates the step in the script, so the narrated video, the live guide and the step-by-step help article all draw from the same corrected text. You do not need to re-record three separate versions or hunt through the help centre for the old label.
If your script has been translated, check the translated version of that line too. Changing one sentence re-voices only that line, which keeps the update small. Still, read the new line in each language you publish in. Do not assume the translation has picked up the new button name correctly.
When to leave AI off and edit by hand
Some teams prefer to keep AI off for everything, and that is a reasonable choice. You may want every change written by a person who knows the product well, or your walkthroughs may cover a small number of stable screens where edits are rare.
AI is also a poor fit when the change is not really a rename. If a whole section of the product has been redesigned, a single suggested fix will not capture the new flow. In that case, rewrite the affected steps by hand, using the script as a checklist for what each screen now needs to show. Keep the re-check on, because it will still tell you which steps need attention while you work through the rewrite.
HandHoldly does not replace the people who know your product. The suggestion is a time saver for the common case, and your team remains responsible for what goes out to customers.
Keeping a short change note for your team
Whatever route you take, write a short note each time a step changes. It does not need to be long. A line or two is enough: the step number, the old wording, the new wording, and the reason. For example: "Step 7: "Save changes" renamed to "Update record" in the release on Tuesday. Button moved to footer. Re-checked against the live page."
These notes pay off later. When a customer asks why the video shows something different from an older help article, you have an answer. When a new team member takes over the walkthrough, they can see the history of the script. And when the next release arrives, you can see which steps have changed before, which are most likely to change again.
If you want to see how the re-check and the fix flow work together, See how it works in the how-it-works section. It shows a broken step being flagged, the suggested fix being reviewed, and the change being saved into the script.