Design an operational workflow for [PROCESS NAME]. The workflow starts when [START TRIGGER] and is complete when [DEFINITION OF DONE]. The people or roles involved are [ROLES AND RESPONSIBILITIES]. Use these current steps, tools, rules, and known problems: [CURRENT PROCESS AND CONSTRAINTS]. The required cadence or service level is [TIMELINE OR SLA]. Do not invent system capabilities, staffing, approvals, policies, integrations, legal requirements, or deadlines. Where an owner, decision rule, or system action is unknown, label it as an open decision rather than filling the gap. Produce a workflow document with: 1. Purpose, scope, trigger, definition of done, and out-of-scope work. 2. A numbered end-to-end procedure. For every step, state the owner, action, input, tool or location, output, expected timing, and next handoff. 3. Decision points written as “if/then” rules, including approval, rejection, rework, and escalation paths. 4. A RACI table for the named roles, keeping one accountable owner per deliverable. 5. A timeline showing normal path, bottlenecks, and the maximum time a task may wait before escalation. 6. A quality-control checklist at the point where errors are cheapest to catch. 7. Three operational metrics with definitions, calculation method, review cadence, and owner. Make steps atomic enough that a new team member can follow them. Avoid vague verbs such as “coordinate” or “handle” unless you define the required action and evidence of completion. Before answering, check that every handoff has a receiving owner and every decision has a rule or escalation. Also flag any step whose timeline conflicts with the stated SLA. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROCESS NAME] | Enter the recurring process you want documented. | Customer refund processing |
| [START TRIGGER] | Describe the event that begins the workflow. | A customer submits a refund request through the support portal |
| [DEFINITION OF DONE] | Describe the observable outcome that means the workflow is complete. | The customer receives a final decision and, if approved, the refund is recorded and issued |
| [ROLES AND RESPONSIBILITIES] | List each role involved and its current responsibilities or authority. | Support agent gathers evidence; support lead approves exceptions; finance specialist issues refunds; operations manager owns policy |
| [CURRENT PROCESS AND CONSTRAINTS] | Provide existing steps, tools, policies, dependencies, and known failure points. | Zendesk stores requests; Stripe issues card refunds; orders older than 30 days need lead review; duplicate requests are common; finance works weekdays only |
| [TIMELINE OR SLA] | Enter the required turnaround time, schedule, or service-level target. | Initial response within 1 business day and final decision within 5 business days |
How to use
- Replace each placeholder with the real trigger, roles, rules, tools, and timing for one process.
- Give the draft to the people who perform each handoff and correct steps that do not match actual practice.
- Decide the open ownership and escalation questions before publishing the workflow.
- Send this follow-up: “Create a one-page checklist version for the [ROLE] who performs steps [NUMBERS].”
Variations
SOP draft
Use this when one role needs an executable standard operating procedure.
Write an SOP for [ROLE] to complete [TASK] using [SYSTEMS AND INPUTS]. The task begins at [TRIGGER] and is complete at [DONE CRITERIA]. Provide prerequisites, numbered click-level or action-level steps where supported by my notes, required records, quality checks, exception handling, and escalation contacts. Include expected time per step and a final completion record. Do not invent buttons, permissions, policies, or system fields. Mark uncertain instructions as “confirm locally.” Check that every required input appears before the step that uses it.
Handoff map
Use this when work gets lost between teams or roles.
Map the handoffs in [PROCESS] among [ROLES] using [CURRENT STEPS AND TOOLS]. Return a table with sending role, receiving role, trigger, required information, system of record, acceptance criteria, due time, and escalation if rejected or overdue. Then identify the three highest-risk handoffs and propose a concrete control for each, such as a required field, acknowledgment, queue, or reconciliation. Do not assume access or integration between systems. Flag any handoff without a named sender, receiver, or acceptance criterion.
Workflow rollout
Use this after a workflow is designed and needs adoption.
Create a rollout plan for the new [WORKFLOW] affecting [AUDIENCE]. Use [IMPLEMENTATION CONSTRAINTS] and [GO-LIVE DATE]. Include training materials needed, pilot scope, owner assignments, communications sequence, cutover steps, support path, feedback collection, and rollback criteria. Define success measures for the first 30 days and specify their data source. Do not claim people are trained, systems are configured, or approvals are complete unless stated. Flag dependencies that must be resolved before go-live.
Tips
- Write the start trigger and definition of done before listing steps; these boundaries prevent adjacent work from quietly entering the process.
- Give each handoff an acceptance criterion, such as required fields or a completed approval, rather than calling a message or ticket a finished transfer.
- Put quality checks near the source of an error, not only at the final approval stage.
- Measure elapsed time by stage as well as total cycle time so bottlenecks are visible instead of averaged away.
FAQ
What is the difference between a workflow and an SOP?
A workflow shows the end-to-end movement of work across roles and decisions. An SOP gives detailed instructions for completing a particular role’s task within that workflow.
Can AI map a process it has never seen?
It can structure the information you provide, but the people doing the work must validate the actual steps, systems, and exceptions.
How many metrics should a workflow have?
Start with three: timeliness, quality, and backlog or rework. More measures are useful only if someone owns them and can act on the result.