Build the SOP from how the task is actually done, not how the org chart says it should be

Most SOPs that never get followed have the same origin story: someone wrote them from the process diagram, or from how the task was designed to work three reorganisations ago, rather than from how the person doing it today actually gets it done - including the workaround for the system that's slow on Mondays and the shortcut nobody wrote down because it felt too obvious to mention.

Ask the model to interview the process out of the person doing it, rather than writing the SOP from a description of the role. Give it the task name and ask it to draft the specific questions you'd need answered to write an accurate SOP - what triggers the task, what they check first, what they do when the normal path doesn't work, what they'd tell a replacement on their first day that isn't written down anywhere. Then feed the answers back in and ask for the SOP itself.

The workaround is usually the most valuable line in the whole document. It's also the one a description-first approach never surfaces, because nobody puts "and if the system's being slow, I just do it this other way instead" into an official process description unless someone specifically asks them to.