ChatGPT prompt for a workflow diagram

Create a workflow diagram specification for [PROCESS NAME]. The process starts when [TRIGGER] and ends when [END CONDITION]. These are the known steps, systems, roles, policies, timing expectations, and pain points: [PROCESS NOTES]. The people or teams involved are [ROLES AND OWNERS]. The diagram will be used by [DIAGRAM AUDIENCE].

First, identify missing decisions, ownership conflicts, undefined handoffs, and timing gaps. Do not fill gaps with invented procedures. Then produce:
1. A short scope statement defining what is inside and outside this workflow.
2. A diagram-ready flow in Mermaid flowchart syntax. Use swimlane-style subgraphs by owner where it improves readability. Show a single start and end, numbered activity nodes, decision diamonds with explicit yes/no labels, system-of-record steps, approvals, waits or service-level targets, and rework loops.
3. A plain-language step table with step number, owner, action, required input, output or system update, target timing, and escalation path.
4. An exceptions section for at least the failure cases supported by my notes, including who decides and where the process returns.
5. A handoff checklist naming what must be complete before each team passes work onward.

Use verb-first activity labels such as “Validate request” rather than vague labels such as “Review.” Keep each diagram node to one action. If two actions have different owners, split them. Treat an approval as a decision with an accountable approver, not as a generic box.

Before answering, trace the happy path from trigger to end condition and verify that every decision branch reconnects, ends, or escalates. Verify that every step has one accountable owner and that any stated timeline has a clock start. Ask up to 3 clarifying questions only if a required input is missing.

Turn this approved workflow into a standard operating procedure: [WORKFLOW]. The audience is [AUDIENCE], and the systems used are [SYSTEMS]. Produce purpose, scope, roles, prerequisites, numbered operating steps, required evidence at each handoff, exception handling, escalation contacts as role placeholders, and a revision-control block. Keep steps executable and use one owner per action. Do not invent policy rules or access permissions. Before answering, check that every workflow node is represented and every decision includes a next action.

Design a diagram-ready approval workflow for [REQUEST TYPE]. Requests arrive through [INTAKE CHANNEL], must meet [APPROVAL CRITERIA], and involve these roles: [ROLES]. Include intake validation, incomplete-request return loops, conflict-of-interest handling, approval or rejection, decision logging, notification, and archival. Output Mermaid flowchart code plus a decision-rights table with approver, consulted roles, evidence required, and target turnaround. Do not invent approval thresholds. Check that rejected and expired requests reach a documented endpoint before answering.

Map an incident-response workflow for [INCIDENT TYPE] used by [TEAM]. The trigger signals are [TRIGGERS], severity criteria are [SEVERITY RULES], and current tools are [TOOLS]. Return Mermaid code with incident declaration, severity decision, assigned incident lead, communications, mitigation, recovery validation, closure, and post-incident review. Include time-based escalation points and a role-based communication matrix. Do not claim regulatory requirements not provided. Before answering, ensure every severity path has an owner, notification action, and closure condition.