Use case

Work instructions without forty screenshots pasted by hand

The step-by-step the key user will run every week — produced from the same recording you would make anyway. On an implementation project, end-user documentation is usually a contractual deliverable: not an end-of-project courtesy, but a line on the go-live checklist.

Record an instruction now free, nothing to install

The pain

It is the same Print Screen → Word → arrow → caption as the evidence, with one aggravation: the instruction is written after the project, by someone already assigned to the next one. It is born late, and it is the task that falls to whoever has the least power to refuse.

A bad instruction is not rejected by anyone — it simply is not used, and the key user goes back to phoning the consultant. The reasons are always the same four: a missing step, a screen that no longer matches reality, language written by someone who already knows, and no indication of which field to look at. The last two are a writing problem — and writing is exactly what spoken narration solves, because someone narrating while doing explains like someone teaching.

What comes out

A procedure document, not a historical record. The difference is in the details:

• No date stamp on each step. In evidence the time is mandatory; in an instruction it makes the document look expired the day it is born. The step number stays, the clock goes
• Your note becomes the step heading, and the speech from that stretch becomes the description
• Procedure header: title, system, author and version
• A prompt ready for the AI to rewrite in the imperative: "so then I go into ME21N and raise the order" becomes "Go to ME21N and raise the order". The AI you already use does the writing; the document and the screens are ours
• Domain vocabulary: ME21N, KI235 and Fiori stop coming out spelled in words in the transcript
• Word to edit, PDF to hand out, HTML for the wiki — and Markdown to paste into Confluence with no separate attachment

How to do it

1. Pick the Step-by-step guide use case in step 1.
2. Record the process once, narrating what you do and why. Say the field names out loud: that is what the key user will be looking for.
3. In the review, discard what does not matter, reorder with the arrows, and fix the acronyms with your system’s term list.
4. Produce the Word file to edit, or the PDF directly. If you are training in a room, the same material becomes the script.

What it does not do — better to know up front

It does not refresh the screenshots on its own when the system changes. That is called replay, it is what ClickLearn sells, and it requires driving the application — impossible in a tab that only receives an image of a shared screen. Pretending we compete there would be this product’s first lie.

It cannot yet reopen a finished document to fix one step. It is the piece this case asks for most, and it is the one being built: reopen the .zip, swap the image on step 7 and generate again, without re-recording the other forty.

It does not host the content or tell you who read it. Your company’s LMS answers that — and the package for it (SCORM) is in the queue. We hand over the package; the tracking is your system’s, not ours.

Record an instruction now See the plans

It is the same consultant who recorded the UAT evidence in June writing the key user’s instruction in August, with the same transactions. That is why this case is a model inside the product, not another tool.