PlaysbyMoat8
Back to the library
The workflow guideOperations

Draft a procedure from a recorded walkthrough

Convert a recorded process demonstration into a written procedure for the team to review and maintain.

6 implementation stepsSimple

How this works

Convert a recorded process demonstration into a written procedure for the team to review and maintain.

Convert demonstrated actions into a procedure that another person can follow. The recording may omit prerequisites, waiting periods or decisions the demonstrator knows implicitly; surface those gaps rather than inventing a smooth sequence.

Before you start

Defined operating scope

People demonstrate recurring procedures on screen but lack written instructions.

Required source material

Obtain Approved process video; Required procedure format. If connectors are unavailable, use authorized files with the same fields.

Decision and exception rules

The video skips a setup step. Add a clearly marked prerequisite question instead of fabricating the setup.

Prepare the inputs

recording
Required

Approved video with timestamps

Confirm readable screen and usable audio.

process_scope
Required

Start and end conditions

Identify which task the demonstration actually covers.

procedure_template
Required

Sections and audience

Specify required prerequisites and completion checks.

owner
Required

Process expert

Provide a route for clarifying omitted steps.

Implementation, step by step

  1. Establish the working record

    • Confirm the selected records, effective versions and responsible owner.
    • Check recording, process_scope, procedure_template, owner before beginning. Record the source version and the selected scope; an unavailable value stays unknown rather than becoming an inferred fact.

    Checkpoint: The input record identifies the selected recording and any missing required fields.

  2. Extract the actions and explanations from the recording

    • Extract actions and spoken explanations with timestamps, distinguishing clicks from the business reason for each action.
    • Trace each operational step to a timestamp or owner-confirmed addition.

    Checkpoint: A saved intermediate result for: Extract the actions and explanations from the recording.

  3. Draft the steps and necessary context

    • Draft prerequisites, steps, decision branches and the visible completion state; mark unseen credentials, permissions or setup as questions.
    • Ask a second practitioner to follow the draft and record where they need undocumented context.

    Checkpoint: A saved intermediate result for: Draft the steps and necessary context.

  4. Have the process owner correct omissions and approve the procedure

    • Have the process owner compare the draft with the recording and perform a small walkthrough to correct omissions before approving it.
    • Trace each operational step to a timestamp or owner-confirmed addition.

    Checkpoint: A saved intermediate result for: Have the process owner correct omissions and approve the procedure.

  5. Reconcile the proposed result

    • Trace each operational step to a timestamp or owner-confirmed addition.
    • Ask a second practitioner to follow the draft and record where they need undocumented context.

    Checkpoint: The listed discrepancies have a named reviewer or an explicit unresolved status.

  6. Package the result and unresolved work

    • The source mentions a live agency use case but gives limited implementation detail. Verify the draft against the video and actual process before use.
    • A demonstration is evidence of one path, not proof that all exceptions are covered.

    Checkpoint: A reviewable standard operating procedure. Unresolved items remain visible in the review record.

Decisions along the way

The video skips a setup step.

Add a clearly marked prerequisite question instead of fabricating the setup.

The screen and narration disagree.

Retain both timestamps and ask the owner which action is correct.

Sensitive values appear on screen.

Replace them with typed placeholders and keep the original recording restricted.

What you will produce

process-video-to-procedure-draft-result.json

JSON

A reviewable standard operating procedure. Label proposed and completed states separately.

Include: procedure_title · prerequisites · steps · decision_points · completion_check · open_owner_questions · status · evidence_reference · review_note

process-video-to-procedure-draft-review.md

Markdown

Keep the evidence and unresolved decisions needed to apply this result, including exceptions involving owner.

Include: source_reference · question · owner · next_action

Check the result

  • Trace each operational step to a timestamp or owner-confirmed addition.
  • Ask a second practitioner to follow the draft and record where they need undocumented context.
  • Inspect recording and process_scope in both the original and output; confirm that record identity and interpretation survived the transformation.
  • The source mentions a live agency use case but gives limited implementation detail. Verify the draft against the video and actual process before use.

When something goes wrong

The video skips a setup step.

Add a clearly marked prerequisite question instead of fabricating the setup. Retain the affected evidence and recovery status.

The screen and narration disagree.

Retain both timestamps and ask the owner which action is correct. Retain the affected evidence and recovery status.

Sensitive values appear on screen.

Replace them with typed placeholders and keep the original recording restricted. Retain the affected evidence and recovery status.

A worked example

SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT

Request

Draft a procedure from a recorded walkthrough for the following bounded example; prepare the result for review.

Inputs

Synthetic example: Recording shows selecting an existing customer, entering an order and saving. It never shows how the customer record was created or what validates the price.

Expected result

Synthetic expected result: Procedure begins with a prerequisite for an existing customer and approved pricing. It documents visible order steps and asks the owner to define the price check.

Run a small pilot

Start small

Trial a representative batch containing the ordinary case and the exception demonstrated above.

Record the baseline

Record current preparation time, review effort and correction types for the same records.

Agree success criteria

Agree acceptable review and error limits; measure owner correction time per procedure; missing steps detected during a trial run.

Stop or revise

Sensitive values appear on screen. Pause affected records and apply this recovery: Replace them with typed placeholders and keep the original recording restricted.

Keep the scope clear

  • A demonstration is evidence of one path, not proof that all exceptions are covered.
  • Do not publish confidential screen contents or assume permission to operate the demonstrated system.

Check before using

The source mentions a live agency use case but gives limited implementation detail. Verify the draft against the video and actual process before use.

Business activities

  • Maintain shared company knowledge

Editorially adapted workflow; not independently tested.

FROM A RECIPE TO YOUR WORKFLOW

Bring the company context together.

This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.

For this recipe: Approved process video · Required procedure format

Start with one recurring task, agree which sources to use, and review the first result with your team.

Discuss this workflow

What does your team do?

Choose the recurring work you would like to improve.

A field guide, made for work.

Plays is a curated library of anonymized business workflows. Each recipe explains the inputs, steps, tools, and checks you can adapt to your team. These are editorial guides, not independently tested implementations.

When you share a company website, the guide may read a limited number of public pages on that website. Messages and retrieved page text are sent to our AI provider, NVIDIA, to recommend relevant workflows. Share a general description rather than confidential information.

Saved workflows and selected activities stay in this browser. Your chat history and selected company website are kept in this tab and cleared when you reload or start a new chat. The server does not store conversations. Live source monitoring is not enabled.

If you allow analytics, PostHog receives page views and actions such as workflow saves, skill downloads and link clicks. Random browser and session identifiers connect these actions without identifying you by name. Your choice and browser identifier expire after 90 days; sessions restart after 30 minutes of inactivity or 24 hours. We use local storage, not analytics cookies. Messages, company URLs, search text, full referrers and IP addresses are not sent. There are no person profiles or session recordings. You can decline or withdraw in Analytics settings; Do Not Track and Global Privacy Control keep analytics off.

Read the Plays Privacy Notice ↗