name: process-docs description: Quand l'utilisateur doit créer des POS, des playbooks, des runbooks ou autre documentation opérationnelle définissant comment un processus récurrent doit être exécuté. related: [support-docs, board-update] reads: [startup-context]

tags: [nontechnical, startup-founder-skills, process-docs, documentation] --------|------------|-----| | [Trigger] | [Person/Role] | [Timeframe] |

Success Criteria

Comment vérifier que le processus a été exécuté correctement.

Changelog

### Template 2: Incident Runbook

[Incident Type] — Runbook

Severity: [P0-P3] On-Call Owner: [Role] Last Tested: [Date]

Detection

Comment cet incident est identifié (alertes, signalements clients, monitoring).

Immediate Actions (First 5 Minutes)

1. Triage step...
2. Communication step...

Diagnosis

Decision tree pour identifier la cause racine.

Resolution Steps

Procédure étape par étape pour chaque cause racine connue.

Post-Incident

Checklist après la résolution de l'incident.

### Template 3: Onboarding Playbook

[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.

## Frameworks & Best Practices
- **The "bus factor" test.** Si la personne qui exécute habituellement ce processus n'est pas disponible, quelqu'un d'autre peut-il l'exécuter à partir de ce document seul ? Si non, ajoutez plus de détails.
- **Voix impérative uniquement.** Chaque étape commence par un verbe. « Cliquez sur le bouton Deploy » et non « Le bouton Deploy devrait être cliqué ».
- **Une action par étape.** Si une étape contient « et », divisez-la en deux étapes. Les étapes composées sont ignorées ou complétées à moitié.
- **Les points de décision sont explicites.** Utilisez un langage si/alors avec des conditions claires. « Si le client a un plan Enterprise, passez à l'étape 7 » et non « Traiter les clients enterprise différemment ».
- **Les estimations de temps comptent.** Incluez la durée attendue pour chaque phase majeure. Cela aide les gens à planifier et signale quand quelque chose ne va pas (étape prenant 3× plus longtemps que prévu = escalade).
- **Les captures d'écran se dégradent vite.** Préférez les descriptions textuelles des chemins UI (Paramètres > Intégrations > Slack) aux captures d'écran, qui cassent à chaque redesign. Utilisez les captures d'écran seulement pour les interfaces véritablement complexes.
- **Versionnez et datez tout.** Un document de processus sans date de dernière mise à jour est supposé être inexact.
- **Détail progressif.** Commencez chaque section avec un résumé d'une ligne, puis développez. Les opérateurs expérimentés scannent ; les nouveaux employés lisent chaque mot. Servez les deux.
- **Liez, ne dupliquez pas.** Si un autre POS couvre un sous-processus, liez-y plutôt que de copier les étapes en ligne. La duplication cause de la divergence.
- **Testez avec un nouveau venu.** La meilleure revue est d'avoir quelqu'un peu familier avec le processus suivre le document et noter où il se bloque.

## Related Skills
- `support-docs` — Chaînez quand le processus documenté est orienté client et nécessite un article du centre d'aide ou un guide de dépannage correspondant.
- `board-update` — Chaînez quand les processus opérationnels doivent être résumés pour les rapports aux investisseurs ou au conseil (p. ex., « voici notre maturité en matière de réponse aux incidents »).

## Examples

### Example 1: Operational SOP
**User:** "Write an SOP for processing customer refunds."

**Good output excerpt:**
> ## Procedure
> 1. **Open the refund request** in Zendesk. Verify the ticket includes: order ID, reason for refund, and customer email.
> 2. **Check eligibility** in Stripe.
>    - **Decision point:** If the order is older than 30 days, escalate to the Support Lead with a note explaining the customer's situation. Do not process the refund.
>    - If within 30 days, continue to Step 3.
> 3. **Issue the refund** via Stripe Dashboard > Payments > [Order ID] > Refund. Select "Full refund" unless partial was approved by the Support Lead.
> 4. **Update the ticket** with the Stripe refund ID and set status to "Solved."
> 5. **Log the refund** in the Refund Tracker spreadsheet (column A: date, B: order ID, C: amount, D: reason code).
>
> **Estimated time:** 5-8 minutes per refund.

### Example 2: Incident Runbook
**User:** "We need a runbook for when our payment processing goes down."

**Good output excerpt:**
> ## Immediate Actions (First 5 Minutes)
> 1. **Acknowledge the alert** in PagerDuty to stop re-escalation.
> 2. **Check Stripe Status Page** (status.stripe.com). If Stripe reports an outage, skip to "External Provider Outage" section.
> 3. **Post in #incidents Slack channel:** "Investigating payment processing failures. Updates every 15 min. DRI: [your name]."
> 4. **Enable the maintenance banner** via Admin > Feature Flags > `payment_maintenance_mode` = true. This shows users "Payments temporarily unavailable, please retry shortly" instead of raw errors.