WFDASH-WEBAPP/docs/sops/README.md

81 lines
3.2 KiB
Markdown
Raw Normal View History

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