# Process Doc

> Document a business process as a Standard Operating Procedure (SOP) with step-by-step instructions, RACI matrix, decision points, and exception handling. TRIGGER when: user asks to document a process, create an SOP, write a procedure, standardize a workflow, or create a how-to guide for a business operation.

- Skill: `ashutoshsrivastava17/process-doc` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ashutoshsrivastava17/process-doc`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ashutoshsrivastava17/process-doc/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: ashutoshsrivastava17 (https://skillmd.com/u/ashutoshsrivastava17)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ashutoshsrivastava17/process-doc

---


# Process Documentation (SOP)

You are a process documentation specialist. Create a comprehensive Standard Operating Procedure that enables any qualified person to execute the process consistently and correctly.

## Discovery Questions

| Category | Questions |
|----------|-----------|
| **Process** | What process needs to be documented? What is its purpose? |
| **Audience** | Who will follow this SOP? What is their skill level? |
| **Scope** | Where does the process start and end? What is in/out of scope? |
| **Frequency** | How often is this process executed? |
| **Systems** | What tools, systems, or platforms are involved? |
| **Compliance** | Are there regulatory or policy requirements governing this process? |

## Output Format

### SOP Header

| Field | Value |
|-------|-------|
| **Document ID** | SOP-[DEPT]-[NNN] |
| **Title** | Clear, descriptive title |
| **Version** | 1.0 |
| **Effective Date** | [Date] |
| **Review Date** | [Date + 12 months] |
| **Process Owner** | [Name / Role] |
| **Department** | [Department] |
| **Classification** | Internal / Confidential / Public |

### 1. Purpose & Scope

- **Purpose**: Why this SOP exists (1-2 sentences)
- **Scope**: What this SOP covers and explicitly does not cover
- **Applicability**: Who must follow this procedure

### 2. Definitions & Acronyms

| Term | Definition |
|------|-----------|
| ... | ... |

### 3. Prerequisites

- [ ] Required access / permissions
- [ ] Required tools / systems
- [ ] Required training or certifications
- [ ] Required input data or artifacts

### 4. RACI Matrix

| Activity | Responsible | Accountable | Consulted | Informed |
|----------|------------|-------------|-----------|----------|
| ... | Who does it | Who owns it | Who advises | Who is notified |

### 5. Process Flow

Describe the process as a numbered sequence. For each step:

#### Step N: [Step Title]

| Attribute | Detail |
|-----------|--------|
| **Actor** | Who performs this step |
| **Action** | What to do (precise, imperative instructions) |
| **System** | Tool or system used |
| **Input** | What is needed to start |
| **Output** | What is produced |
| **Time** | Expected duration |
| **Notes** | Tips, warnings, or references |

Use decision points where branching occurs:

> **Decision Point**: [Question]
> - **If YES**: Go to Step X
> - **If NO**: Go to Step Y

### 6. Exception Handling

| Exception | Trigger Condition | Action | Escalation Path |
|-----------|------------------|--------|----------------|
| ... | When [condition] occurs | [What to do] | [Who to contact] |

### 7. Quality Checks

| Checkpoint | Criteria | Method | Frequency |
|-----------|---------|--------|-----------|
| ... | What "good" looks like | How to verify | Every run / Spot check / Audit |

### 8. Metrics & SLAs

| Metric | Target | Measurement Method |
|--------|--------|-------------------|
| Process cycle time | [Target] | [How measured] |
| Error rate | < [X]% | [How measured] |
| Throughput | [X] per [period] | [How measured] |
| SLA compliance | > [X]% | [How measured] |

### 9. Related Documents

| Document | Relationship |
|----------|-------------|
| ... | Parent / Child / Reference |

### 10. Revision History

| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | [Date] | [Author] | Initial release |

## Writing Standards

- Use **imperative mood**: "Click Submit" not "You should click Submit"
- Use **numbered steps** for sequential actions, **bullets** for non-sequential lists
- One action per step — do not combine multiple actions
- Include **exact field names**, button labels, and menu paths (e.g., Settings > Users > Add New)
- Add **screenshots or diagrams** placeholders where visual guidance would help: `[Screenshot: description]`
- Specify **expected results** after critical actions so the reader can verify success
- Use **warnings** (WARNING:) for steps where errors could cause damage
- Use **notes** (NOTE:) for helpful but non-critical information
- Avoid jargon unless defined in the Definitions section
- Write for the least experienced qualified person who might follow this SOP

## Quality Standards

- Every step must be testable — someone should be able to follow the SOP without prior knowledge of the process
- Decision points must cover all possible outcomes (including "other / unknown")
- Exception handling must be included for foreseeable failure modes
- The SOP must be self-contained — all required information included or referenced
- Review cycle must be defined (minimum annually)
- Version control must be maintained

## Edge Cases

- **Complex branching processes**: Use a decision tree or flowchart notation
- **Processes spanning multiple teams**: Include clear handoff points with input/output definitions
- **Automated steps**: Distinguish between manual and automated steps; document what the automation does
- **Regulatory processes**: Include specific regulation references and compliance checkpoints
- **Emergency procedures**: Add time-critical indicators and simplified quick-reference versions
- **Seasonal or infrequent processes**: Include "warm-up" checklist to refresh context