20 AI Prompts for Documenting Workflows and Processes

TL;DR: The best AI prompts for workflow documentation map to a stage, not a single template: find undocumented processes (discovery), pull the real steps out of the person who does the work (extraction), turn notes into ordered text (drafting), generate flowcharts as plain text (diagramming), check for gaps before publishing, and catch staleness after. Below are 20 copy-paste prompts across all six stages.

What Are the Best AI Prompts for Documenting Workflows and Processes?

The best prompts for workflow documentation aren't a single "write me an SOP" template. They match the stage the process is actually in. A process nobody has mapped yet needs a discovery prompt. A process that lives entirely in one person's head needs an extraction prompt built to surface exceptions, not just the tidy version. A finished draft needs a gap-check prompt before it ships, and a published doc needs a maintenance prompt on a schedule tied to change, not the calendar.

Most teams reach for one prompt style ("write a process document for X") and wonder why the result reads well but misses the actual edge cases that make the process hard. The fix isn't a better single prompt. It's using the right prompt for where the process actually is in its life cycle.

If you already know exactly which process you're documenting and want the deepest version of a single generator, including a full interview-the-expert sequence, our free SOP generator prompt covers that in depth. This post is the wider pack around it: what to do before a document exists, and how to keep it from rotting once it does.

The Six Stages, at a Glance

How Do You Find Out What Processes Even Need Documenting?

Most teams jump straight to writing a process document without first figuring out which processes are worth the effort. Discovery prompts fix that: they take a rough description of a role, team, or tool stack and turn it into a ranked list of candidates, before anyone drafts a word.

This stage matters most for a founder or small team wearing every hat at once. If that's you, our founder AI workflow post covers the broader pattern of running investor updates, hiring, and product work off one shared library, of which process discovery is one piece.

1. Process Inventory Prompt

Act as an operations consultant. I'm going to describe my role/team below.
Based on this description, list every distinct process or recurring task
that could reasonably be turned into a written procedure. For each one,
note: (a) how often it happens, (b) who currently does it, (c) how risky
it is if done wrong, and (d) whether it currently exists only in someone's
head or is partially written down somewhere.

Role/team description: [PASTE A FEW SENTENCES ABOUT WHAT THIS TEAM/ROLE DOES]

What it's for: turning a vague sense of "we should document more stuff" into a concrete, scannable list. What to change: the role/team description. The more specific you are about tools and responsibilities, the less generic the list.

2. Process Prioritization Prompt

Here is a list of undocumented processes for [TEAM/ROLE]: [PASTE LIST FROM
PROMPT 1 OR YOUR OWN LIST]. Rank them by priority to document first, using
this formula: priority = (frequency × risk if done wrong) ÷ (how many
people currently know how to do it). Show your ranking as a table with a
one-line reason for each ranking, and flag any process where "how many
people know how to do it" is 1.

What it's for: stopping you from documenting the easy, low-stakes process first just because it's easy. What to change: the list; swap the formula's weighting if your team cares more about onboarding speed than risk.

3. Owner and Stakeholder Mapping Prompt

For the process "[PROCESS NAME]," help me map who touches it. Ask me
questions one at a time until you can produce: the primary owner, anyone
who has to approve a step, anyone who receives an output from this
process, and anyone who could unknowingly break it by changing something
upstream (a tool, a template, a policy). Stop and list assumptions you're
making if I don't have an answer.

What it's for: catching the hidden dependency, the process that looks like it belongs to one person but actually needs sign-off from someone in another department. What to change: the process name. Run this before extraction so you know who else to interview.

4. Systems and Tools Audit Prompt

I'm about to document the process "[PROCESS NAME]." Before I write
anything, help me build a tools audit: ask me what software, spreadsheets,
templates, logins, or physical tools are involved at each rough stage of
this process (I'll describe the stages loosely). Then list which of those
are likely to change in the next 12 months and should be referenced by
role/category rather than by exact tool name, so the doc doesn't go stale
the moment we switch vendors.

What it's for: writing "use your CRM's contact export" instead of a specific tool name that changes in eighteen months. What to change: the process name and your rough stage description.

How Do You Get a Process Out of an Expert's Head and Into Text?

The person who does a process well rarely explains it completely on the first try. They skip the step they no longer think about, the workaround they use without noticing, and the thing they check "by feel." Extraction prompts are built to interrupt that and pull the missing 20% out on purpose.

If someone with irreplaceable process knowledge is leaving a role, or you've been burned by that before, the deeper pattern for capturing it is in how agencies stop losing AI work when staff leave.

5. Quick-Capture Voice Dump Prompt

Below is a raw transcript of me (or a colleague) explaining how we do
"[PROCESS NAME]" out loud, unedited. Read it and produce a first-pass,
loosely ordered list of steps in the order they were mentioned, keeping
any hedges, caveats, or "usually" statements exactly as said rather than
smoothing them into confident instructions. Mark anything unclear with
[CLARIFY: ...] instead of guessing.

Transcript: [PASTE RAW TRANSCRIPT OR VOICE MEMO TEXT]

What it's for: a fast first pass on a messy explanation, before you clean anything up, so you don't lose the hedges that mark real uncertainty. What to change: the process name and the transcript. Resist the urge to edit the transcript before pasting it in.

6. Edge Case Elicitation Prompt

I'm documenting "[PROCESS NAME]" and have the standard happy-path steps
below. Act as someone deliberately trying to break this process. Ask me,
one at a time, what happens if: a required input is missing, a system is
down, the requester is unusually senior or unusually urgent, two steps
need to happen in parallel instead of in order, or the person doing this
is new and doesn't know the shortcuts. Stop after each answer and ask a
follow-up if my answer implies another edge case.

Happy-path steps: [PASTE STEPS]

What it's for: the exceptions that never come up until they do, and that a tidy step list never mentions. What to change: the steps and, if relevant, swap the listed scenarios for ones specific to your process (a refund process has different edge cases than a deploy process).

7. Tacit Knowledge Prompt

I do "[PROCESS NAME]" regularly and I'm trying to write down things I do
automatically that I might forget to mention. Ask me questions to surface
tacit knowledge specifically: things I check without being asked to, things
I've learned to avoid the hard way, judgment calls I make that aren't
written down anywhere, and anything I'd tell a new hire in person that
isn't in any existing document.

What it's for: the rule-of-thumb an expert applies without noticing, which is often the actual reason their version of the process works and someone else's doesn't. What to change: the process name. This works best as a live back-and-forth, not a one-shot answer.

8. Handoff Debrief Prompt

I have [NUMBER] weeks before I hand off "[PROCESS NAME]" to someone else.
Interview me to produce a handoff brief covering: the steps as I actually
do them today (not the outdated written version, if one exists), the three
things most likely to go wrong in the first month for my replacement, who
to ask when something doesn't match the doc, and any workaround I use that
isn't officially sanctioned but is necessary.

What it's for: the specific, time-boxed situation of someone leaving and taking undocumented knowledge with them. What to change: the timeframe and process name. Run this even for a "someone is just going on leave" handoff, not only permanent departures.

How Do You Turn Raw Notes Into a Structured Process Draft?

Once you have the raw material from discovery and extraction, drafting prompts turn it into something a reader can follow without having sat in on the interview. This is the stage where structure and audience matter more than new information.

9. Step Sequencing Prompt

Below are unordered notes about how to do "[PROCESS NAME]." Turn them into
a numbered sequence of steps. Combine notes that describe the same step,
split any note that actually contains two actions, and flag with
[SEQUENCE UNCLEAR] any pair of steps where the order might not matter or
where you're inferring the order rather than being told it directly.

Notes: [PASTE RAW NOTES]

What it's for: the mechanical but easy-to-get-wrong job of ordering steps correctly instead of in the order they happened to be mentioned. What to change: the notes. Keep the [SEQUENCE UNCLEAR] flags in your working draft until a human confirms the order.

10. Role-Based Rewrite Prompt

Here is a process document written for someone who already knows our
tools: [PASTE DRAFT]. Rewrite it twice: once for a brand-new hire in their
first week (spell out every click, define any internal jargon in a
parenthetical), and once as a condensed quick-reference version for
someone who's done this before and just needs the checklist.

What it's for: one process, two audiences, without maintaining two documents from scratch. What to change: the draft. Decide up front whether you actually need both versions or if this is scope creep.

11. Screenshots-to-Steps Prompt

I have a sequence of screen descriptions from a process (below), taken in
order, without a written explanation. Turn these into written steps,
inferring the action taken between each screen (a click, a field entered,
a menu chosen). Mark any inference with [INFERRED] and ask me to confirm
or correct it.

Screen descriptions in order: [PASTE ALT TEXT OR DESCRIPTIONS, ONE PER LINE]

What it's for: software that doesn't export text steps, only screens, which is most internal tools. What to change: the descriptions. This works from screenshot alt text, a screen recording's auto-captions, or your own shorthand notes per screen.

12. Decision-Branch Prompt

The process "[PROCESS NAME]" isn't linear; it branches depending on a
condition. Help me write it as conditional logic: "If [CONDITION], do
[STEPS]. Otherwise, do [STEPS]." Ask me what the actual decision points
are before writing anything, and warn me if more than three branches deep,
since that usually means the process should be split into two documents.

Rough description: [DESCRIBE THE PROCESS AND WHERE IT SPLITS]

What it's for: processes that aren't a straight line, an approval that goes one way above a dollar threshold and another way below it, for example. What to change: the rough description. Let the model push back on over-branching; a document with six nested conditions is usually a sign the process itself needs simplifying, not just documenting.

How Do You Turn Steps Into a Diagram Without Drawing Software?

A written list of steps and a visual flow of the same process serve different readers. Text-based diagram formats like Mermaid render natively in most modern wikis, Notion, and GitHub/GitLab markdown, so you can generate the diagram directly from the prompt instead of drawing it separately and keeping two things in sync.

13. Flowchart-as-Text Prompt

Convert the following numbered steps into a Mermaid flowchart. Use
diamond shapes for any decision point, and label the branches with the
condition (e.g., "Yes"/"No" or the actual condition text). Output only
the Mermaid code block, nothing else.

Steps: [PASTE NUMBERED STEPS]

What it's for: a flowchart you can paste directly into a tool that renders Mermaid, with zero separate diagramming step. What to change: the steps. If your wiki doesn't render Mermaid, ask for ASCII art instead in the same prompt.

14. Swimlane Prompt

Here is a process that involves multiple roles: [PASTE STEPS WITH WHO DOES
EACH ONE]. Organize this as a swimlane table with one column per role and
each row representing a point in time, so I can see at a glance where a
handoff between roles happens and where two roles might be waiting on each
other.

What it's for: multi-person processes where the confusing part is the handoff, not any individual step. What to change: the steps and role assignments. This is most useful for approval chains and anything crossing a team boundary.

15. Decision Tree Prompt

Build a text-based decision tree for troubleshooting "[PROBLEM/PROCESS]."
Start from the symptom, branch based on the first diagnostic question,
and keep branching until each leaf ends in a specific fix or an escalation
step. Format it as nested bullets, indenting one level per branch.

Problem to troubleshoot: [DESCRIBE THE PROBLEM AND WHAT YOU'D CHECK FIRST]

What it's for: troubleshooting guides and support runbooks, where the reader needs "if X, check Y" logic more than a linear procedure. What to change: the problem description. Feed it your actual first three diagnostic questions rather than letting the model guess them.

How Do You Check a Process Doc for Gaps Before You Publish It?

A confident-sounding draft is not the same as an accurate one. AI will fill a gap in a description with something plausible instead of flagging that a gap exists, which is the failure mode to design against before anything ships.

16. Assumption-Check Prompt

Read this process document: [PASTE FULL DRAFT]. List every assumption it
makes that isn't stated explicitly: prior knowledge it expects the reader
to already have, a tool it assumes is already set up, or a term it uses
without defining. For each one, suggest either a one-line addition to fix
it or a note that it should link to another document instead.

What it's for: catching the exact gaps a drafting prompt tends to paper over. What to change: the draft. Run this after every major revision, not just once at the end.

17. New-Hire Failure-Mode Prompt

Imagine you are a new hire following this process document for the first
time, with no prior context beyond what's written: [PASTE DRAFT]. Walk
through it step by step and flag exactly where you would get stuck, what
question you'd have to go ask someone, and which step, if you got it
wrong, would be hardest to notice you'd gotten wrong.

What it's for: simulating the reader who has the least context, which is the one most process docs are actually written for. What to change: the draft. This works best on a document you think is already finished.

18. Cross-Document Consistency Prompt

Here are two related process documents: [PASTE DOCUMENT A] and [PASTE
DOCUMENT B]. Check whether they contradict each other on any shared step,
terminology, tool, or owner. List every inconsistency you find, and note
which document looks more current based on internal clues (dates
mentioned, tool names, etc.), without assuming either one is correct.

What it's for: the moment two documents about adjacent processes quietly disagree because one was updated and the other wasn't. What to change: the two documents. Useful any time you're documenting a process that hands off to or from another documented process.

How Do You Keep Process Docs From Going Stale?

A process document is a snapshot. The tool gets swapped, the approval threshold changes, someone new takes over a step, and the document doesn't know any of that happened unless someone tells it. Treat maintenance as its own stage with its own prompts, run on a trigger rather than a fixed calendar date. The same logic that keeps a codebase from rotting, changing things deliberately and recording why, applies to a process doc; see prompt versioning: treat your prompts like code for the version-control version of this same idea.

19. Staleness Audit Prompt

Here is a process document last confirmed accurate on [DATE]: [PASTE
DOCUMENT]. Here is a list of things that have changed since then: [LIST
TOOL SWAPS, ROLE CHANGES, POLICY UPDATES, ETC.]. Go through the document
and flag every section that is likely affected by one of these changes,
even indirectly, and suggest what needs to be re-verified with the process
owner before this document can be trusted again.

What it's for: a targeted re-check instead of re-reading an entire document from scratch every quarter. What to change: the date, the document, and the change list. Run this the moment you know of a relevant change, not on a fixed schedule.

20. Change-Log Prompt

I changed the following in our process "[PROCESS NAME]": [DESCRIBE WHAT
CHANGED AND WHY]. Write a changelog entry in this format: date, one-line
summary of the change, the specific section affected, and who approved
it. Keep it to two sentences maximum so it stays skimmable at the top of
the document over time.

What it's for: a lightweight audit trail so the next person to touch the process can see what changed and why, without digging through version history. What to change: the process name and change description. Keeping this at the top of the doc, most recent first, is more useful than a separate changelog file nobody opens.

Storing this many prompts as plain text in a notes app works until you need the fourth or fifth variable filled in correctly every time, at which point a persistent context library that holds your tool names, role names, and process-specific terms saves you from retyping the same bracketed placeholders every single time you reach for one of these.