# WFDASH Standard Operating Procedures (SOPs)

These documents define the **what, how, and how-measured** for every operator
role in the Westcott Fasteners business. Each role has its own SOP file
covering:

1. **Daily / Weekly Checklist** — concrete actions with cadence
2. **Step-by-Step Procedures** — how to do each recurring task
3. **Decision Tree** — what to do when X happens
4. **KPIs** — the scorecard, with how each metric is measured

The source of truth is the markdown in this folder. The WFDASH app
renders them at `/sops` for in-app reference.

---

## Roles

| Role | File | What they own |
|---|---|---|
| **Quote Operator** | [`quote-operator.md`](./quote-operator.md) | Sprint queue, line-item pricing, sending quotes, follow-ups |
| **Order Operator** | [`order-operator.md`](./order-operator.md) | Order lifecycle, purchase orders, delivery, invoicing handoff |
| **Collection Driver** | [`collection-driver.md`](./collection-driver.md) | Mobile app, supplier pickups, deliveries, surplus/shorts |
| **Approver / Supervisor** | [`approver-supervisor.md`](./approver-supervisor.md) | Approvals queue, pricing policy, escalations, dashboards |

---

## How to read these

- Each SOP is **role-scoped**. Don't read another role's SOP unless you're
  cross-training. They overlap on shared handoffs — those overlaps are
  intentional and called out in the relevant procedures.
- The **Daily Checklist** is the minimum bar. If you only have 10 minutes,
  do the checklist.
- The **Decision Tree** is a fallback. When you encounter the situation
  and you don't know what to do, find the branch. The tree is not
  exhaustive — when in doubt, escalate (see each role's escalation path).
- **KPIs are not aspirational.** They are how your performance is measured
  in the weekly review. If a KPI is unclear, raise it — don't ignore it.

---

## How to suggest changes

1. Open a PR against the relevant file.
2. PR title: `sop(<role>): <change>` (e.g. `sop(quote-operator): add
   partial-approval procedure`).
3. Tag the approver / supervisor in the review.
4. After merge, the `/sops` page in the app updates on the next deploy.

If you can't write the change yourself, drop the suggestion in
`#sop-feedback` and someone will turn it into a PR.

---

## Conventions used in these documents

- **Routes** are written as `/path/to/page` (e.g. `/sprint`,
  `/orders/123`).
- **Buttons / actions** are in **bold** (e.g. **Claim**).
- **Status values** are in `code` (e.g. `approval_pending`,
  `collection_pool`).
- **Collection / field names** are in `code` (e.g.
  `order_items.item_status`).
- **SLA times** are in working days (Mon–Fri, SAST). Weekends don't
  count. The `isOlderThanWorkingDays()` helper in the dashboard uses
  the same convention.
- **Currency** is ZAR (excl. VAT) unless otherwise noted.

---

## When a section is missing or wrong

These SOPs are **derived from `APP_CAPABILITIES.md`, the
`item_status` lifecycle, the quote/order state machines, and the
order-workflow-rules**. If the system has changed and the SOP hasn't:

- It's a doc bug. **File a PR** or ping the supervisor.
- The SOP is **not** authoritative over the system. The system is
  authoritative. If they disagree, follow the system and fix the SOP.