process-docs

流程文档

适用场景

当创始人或运营人员需要记录内部流程，以便团队中的任何人都能一致地执行时启用。包括诸如“为 X 编写一份 SOP”“创建一份事故响应操作手册”“记录我们的入职指南”“如何将这个流程标准化”，或任何将隐性知识转化为可重复执行流程的请求。

所需上下文

• 来自 startup-context： 公司阶段、团队规模、当前使用的工具和系统、组织结构、合规要求。
• 来自用户： 要记录的流程、负责人和执行者、当前痛点或失效模式、执行频率、涉及的工具，以及这是要替代现有的（未记录的）流程，还是全新流程。

工作流

1. 确定文档类型 — 判断这是操作 SOP（日常流程）、事故操作手册（应急响应）还是入职指南（循序渐进的学习路径）。每种文档使用不同模板。
2. 梳理端到端流程 — 从触发事件到完成，逐步梳理所有环节。确定输入、输出、决策点、交接环节和升级路径。
3. 明确所有权和 RACI — 指定一位负责人（Responsible），并为每个主要步骤确定审批人（Approves）、咨询对象（Consulted）和知会对象（Informed）。
4. 起草文档 — 使用下方相应的模板。采用祈使语气（“打开仪表板”，而不是“应打开仪表板”）。
5. 添加决策树 — 对于包含条件逻辑的步骤，明确写出 if/then 分支。绝不让分支选择含糊不清。
6. 纳入失效模式 — 记录每个步骤失败时应采取的措施。没有错误处理的流程文档并不完整。
7. 设定审查周期 — 明确规定何时以及由谁审查此文档（例如由流程负责人每季度审查一次）。

输出格式

按照以下三个模板之一编写结构化的 Markdown 文档。每份流程文档都应包含元数据标题，正文应确保没有先验背景知识的人也能端到端地执行流程。

模板 1：操作 SOP

# [Process Name] — Standard Operating Procedure
**Owner:** [Name / Role]
**Last Updated:** [Date]
**Review Cadence:** [Quarterly / Monthly]
**Version:** [1.0]

## Purpose
Why this process exists and what business outcome it supports.

## Scope
What this SOP covers and explicitly does not cover.

## Prerequisites
Tools, access, permissions, or context needed before starting.

## Procedure
1. Step with specific action
   - Sub-step with detail
   - **Decision point:** If [condition], go to Step X. Otherwise continue.
2. Next step...

## Escalation Path
| Condition | Escalate To | SLA |
|-----------|------------|-----|
| [Trigger] | [Person/Role] | [Timeframe] |

## Success Criteria
How to verify the process was completed correctly.

## Changelog
| Date | Author | Change |
|------|--------|--------|

模板 2：事故操作手册

# [Incident Type] — Runbook
**Severity:** [P0-P3]
**On-Call Owner:** [Role]
**Last Tested:** [Date]

## Detection
How this incident is identified (alerts, customer reports, monitoring).

## Immediate Actions (First 5 Minutes)
1. Triage step...
2. Communication step...

## Diagnosis
Decision tree for identifying root cause.

## Resolution Steps
Step-by-step fix for each known root cause.

## Post-Incident
Checklist for after the incident is resolved.

模板 3：入职指南

# [Role/Process] — Onboarding Playbook
**Duration:** [e.g., 2 weeks]
**Buddy/Owner:** [Role]

## Day 1-2: Orientation
Tasks, access setup, key introductions.

## Day 3-5: Core Training
Hands-on exercises, shadowing, tool walkthroughs.

## Week 2: Guided Practice
Supervised execution of real tasks with checkpoints.

## Graduation Criteria
What the person must demonstrate to be considered onboarded.

框架与最佳实践

• “巴士因子”测试。 如果通常负责执行此流程的人无法参与，其他人能否仅凭这份文档完成流程？如果不能，就补充更多细节。
• 只用祈使语气。 每个步骤都以动词开头。“点击 Deploy 按钮”，而不是“应点击 Deploy 按钮”。
• 每个步骤只做一件事。 如果一个步骤中包含“并且”，就拆成两个步骤。复合步骤容易被跳过或只完成一半。
• 明确写出决策点。 使用 if/then 语言，并说明清晰的条件。“如果客户使用 Enterprise 套餐，则跳至第 7 步”，而不是“区别处理 Enterprise 客户”。
• 时间估算很重要。 为每个主要阶段标注预计时长。这有助于人们安排时间，也能提示何时出了问题（某一步耗时达到预期的 3 倍时，应升级处理）。
• 截图很快会过时。 优先用文字描述 UI 路径（Settings > Integrations > Slack），而不是容易因重新设计而失效的截图。只有界面确实复杂时才使用截图。
• 标注版本和日期。 没有最近更新时间的流程文档，会被默认视为有误。
• 逐步展开细节。 每个部分先用一句话概述，再展开说明。有经验的运营人员会快速浏览，新员工会逐字阅读。两者都要照顾到。
• 添加链接，不要重复内容。 如果另一份 SOP 涵盖了某个子流程，就链接到该文档，而不是直接复制步骤。重复内容会逐渐产生偏差。
• 请新人测试。 最好的审查方式，是让不熟悉该流程的人按照文档操作，并记录他们在哪些地方遇到困难。

相关技能

• support-docs — 如果记录的流程面向客户，且需要编写相应的帮助中心文章或故障排查指南，则串联使用。
• board-update — 如果需要将运营流程总结为投资者或董事会报告内容（例如“以下是我们的事件响应成熟度”），则串联使用。

示例

示例 1：运营标准操作流程

用户：“编写一份处理客户退款的标准操作流程。”

优质输出摘录：

流程

1. 在 Zendesk 中打开退款申请。确认工单包含：订单 ID、退款原因和客户邮箱。
2. 在 Stripe 中检查退款资格。
   • **决策点：**如果订单距今已超过 30 天，请将问题升级给支持负责人，并附上说明客户情况的备注。请勿处理退款。
   • 如果在 30 天内，请继续执行第 3 步。
3. 通过 Stripe Dashboard > Payments > [Order ID] > Refund 发起退款。除非支持负责人已批准部分退款，否则请选择“全额退款”。
4. 使用 Stripe 退款 ID 更新工单，并将状态设为“已解决”。
5. 在 Refund Tracker 电子表格中记录退款（A 列：日期，B 列：订单 ID，C 列：金额，D 列：原因代码）。

**预计耗时：**每笔退款 5-8 分钟。

示例 2：事件处置手册

用户：“我们需要一份支付处理服务中断时的处置手册。”

优质输出摘录：

立即采取的行动（前 5 分钟）

1. 在 PagerDuty 中确认警报，以停止重复升级。
2. 查看 Stripe Status Page（status.stripe.com）。如果 Stripe 报告发生服务中断，请跳转到“外部服务提供商中断”部分。
3. 在 #incidents Slack 频道发帖：“正在调查支付处理故障。每 15 分钟更新一次。负责人：[你的姓名]。”
4. 通过 Admin > Feature Flags > payment_maintenance_mode = true 启用维护横幅。这会向用户显示“支付暂不可用，请稍后重试”，而不是原始错误信息。