Skills Product & Business Structured Business Process Documentation

Structured Business Process Documentation

v20260618
process-documentation
This skill generates comprehensive, step-by-step process guides suitable for training new employees or standardizing complex operations. It captures not only the main workflow steps, roles, and tools, but also essential elements like scope definition, prerequisites, edge cases, and escalation paths, ensuring clarity and completeness in business documentation.
Get Skill
79 downloads
Overview

Process Documentation Skill

Produces clear, structured process documentation that someone new to a role can follow without needing to ask questions.

Required Inputs

  • Process name
  • Process description (rough notes are fine)
  • Who does this process (roles involved)
  • How often it runs (daily / weekly / monthly / event-triggered)
  • Tools involved
  • Known edge cases

Output Structure


Process: [Process Name]

Owner: [Role] | Frequency: [How often] | Estimated time: [Duration]


Purpose

[1-2 sentences. Why does this process exist? What breaks if it is not done?]

Scope

In scope: [What this covers] Out of scope: [What it does not cover]

Prerequisites

  • [Required access or information]
  • [Any dependency that must be completed first]

Roles and Responsibilities

Role Responsibility
[Role 1] [What they do]

Process Steps

Step 1: [Step name]

  • Who: [Role]
  • When: [Trigger or timing]
  • How: [Substeps numbered]
  • Output: [What exists at end of this step]
  • Tool: [System used]

[Continue for all steps]


Edge Cases and Exceptions

Situation What to do Who to contact
[Edge case] [Action] [Name/role]

Common Mistakes

[2-4 things people get wrong the first time]

Escalation Path

[Name/role] → [Next level] → [Final escalation]

Review

Next review due: [Date]

Quality Checks

  • Every step has a named role (not "someone" or "the team")
  • Edge cases and exceptions table is complete
  • Prerequisites are listed so someone new can prepare before starting
  • Escalation path is named (specific people or roles, not just "your manager")
  • Review date is set

Anti-Patterns

  • Do not write steps without specifying who is responsible for each — ownership must be explicit throughout
  • Do not omit the escalation path — every process must say what happens when something goes wrong
  • Do not document the ideal process if the real process differs — document reality, then note improvements separately
  • Do not skip edge cases and exceptions — they are where most process failures actually occur
  • Do not produce documentation without a review date — undated process docs quickly become incorrect

Example Trigger Phrases

  • "Document this process: [description]"
  • "Write a process guide for [workflow]"
  • "Map out how [process] works"
Info
Name process-documentation
Version v20260618
Size 2.76KB
Updated At 2026-06-19
Language