SOP reader feedback: turn reports into verified corrections

A reader saying “this step does not work” gives an SOP owner a useful starting point, but not yet a verified correction. The report may concern a changed interface, a missing prerequisite or wording that permits more than one interpretation. Turn feedback into a specific question you can investigate before rewriting the guide. That keeps a helpful comment from becoming an untested instruction for the next reader.

Identify the exact guide and step

Start with the version the reader actually used. Ask for the page or file, the relevant step and the point where their result differed from the instructions. A shared link may lead to a current page while the reader is following an older downloaded copy. Establish that distinction before treating the feedback as evidence about your latest revision.

Keep the report focused on observable differences. “The button is missing” is more useful when you know which panel was open and what the reader expected to see. Avoid collecting unrelated account details or asking someone to send a full private desktop recording when a short description would answer the question.

Separate a documentation gap from a different starting state

Compare the reader's situation with the guide's stated prerequisites. Check the application, interface language, selected workspace and relevant access level. A procedure written for one configuration may not cover another. If the guide omitted a condition that changes the path, record that as a possible documentation gap rather than assuming the reader made a mistake.

Do not immediately expand the guide to cover every reported variation. Decide whether the variation belongs within its intended scope. You might need a clearer prerequisite, a separate procedure or a tested branch. State unresolved questions plainly, and involve the appropriate workflow owner when the required behavior is not something you can establish yourself.

Reproduce the issue before proposing a correction

Use a suitable demonstration environment to follow the reported path. Compare what the application shows with the text and screenshot in the guide. Note the smallest concrete mismatch: an outdated control name, a missing transition, an unreadable value or an expected result that no longer appears. Keep evidence of the state that supports your proposed change.

If you cannot reproduce the issue, preserve the report as an open question. Do not invent a workaround because it sounds likely to help. A useful response can identify which detail is still needed and who will check it. The published procedure should distinguish tested actions from author speculation.

Update the instruction and its supporting evidence together

Once the correction is established, revise all the affected parts. A new button name in the text may need a new screenshot. An added prerequisite may change where the numbered sequence begins. A corrected outcome may require a different checkpoint image. Review adjacent steps so the change does not leave an unexplained jump in the workflow.

Keep a short record of what changed and why, without copying sensitive screen contents into the note. Identify the issue the revision resolves and any audience or configuration it still does not cover. Give a reviewer enough context to assess the correction instead of presenting a polished paragraph with no explanation of its basis.

Verify the delivered revision

Follow the corrected guide from its stated starting point, then open the exact artifact readers will receive. Confirm that its text, images and links agree. Check separately stored quick references or related guides if the same change affects them. Editing the source project alone does not establish that a previously distributed copy has been replaced.

StepShot for macOS 14 and later lets authors edit step titles and descriptions, reorder steps and add notes or headings. Use the capture guide when gathering fresh workflow evidence and the editor guide when preparing the revision. These authoring controls support a correction; they do not provide a reader-feedback tracking system. Keep responsibility for the investigation explicit, and close the loop only after the delivered guide reflects a verified change.