weekly-ops-report

Topics in the source

• Weekly Ops Report
• Workflow
• Pitfalls to check explicitly
• Output format

A weekly report is a contract: what changed, where is it concentrated, what needs a decision. Anything that does not serve one of those three questions is decoration and gets cut. 1. Data-quality gate first. Before any KPI: duplicated rows, missing calendar days, impossible values (negative quantities, dates out of range). Fix what is safe to fix, and report every finding in a footer - an unattended report must audit its own inputs. 2. Compute the KPI set agreed for the audience (typical core: revenue/volume, service level, stock cover; keep it under 6). For each: this week, vs last week, and vs the trailing 8-week average. The baseline comparison prevents one unusual prior week from faking a trend. 3. Apply movement thresholds. Only movements beyond agreed thresholds (state defaults, e.g. |revenue| >= 5%, |service| >= 1.5 pts) become findings. Reporting every wiggle trains readers to ignore the report. 4. Decompose every finding. A movement without its driver is not a finding. Break the moved metric by its main dimension (region, carrier, category...) and name the concentrated segment with its share of the move. 5. Write findings as sentences, one line each, using: METRIC moved X

This is an excerpt. Refer to the complete source and its current requirements.