Weekly Ops Report
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.
Workflow
- 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.
- 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.
- 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.
- 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.
- Write findings as sentences, one line each, using: METRIC moved X (vs baseline) - DRIVER is the main contributor (Y, ~Z% of the move) - SUGGESTED NEXT STEP. Tag each finding positive / negative / warning. Maximum five findings; if more qualify, keep the five largest by impact.
- Assemble in fixed order: headline KPI cards, findings list, trend view (13 weeks), attention lists (e.g. low-cover SKUs), data-quality footer. Same structure every week - familiarity is what makes deltas visible.
- Validate before delivering. Recompute one headline KPI directly from raw rows and match it against the report value. If automation is involved, this check runs inside the pipeline, not in someone's head.
Pitfalls to check explicitly
- Week-over-week only (no baseline) - manufactures fake trends
- Unstated metric definitions - pair every service/on-time figure with its definition footnote
- Commentary drift - keep generated findings rule-based and auditable; human judgment belongs in a clearly separated commentary block, not mixed into computed statements
- Silent denominator changes (cancelled orders, excluded lines) between weeks
Output format
The report skeleton in order: title + period + generation stamp; 4-6 KPI cards with deltas; "What changed and where to look" findings (max 5, tagged); 13-week trends; attention table; data-quality footer listing every issue found.
Worked implementation (scheduled pipeline, rule-based insight engine): https://github.com/gulmezeren2-byte/auto-report-pipeline
1---2name: weekly-ops-report3description: Turn raw operational data into a weekly management report that answers exactly three questions - what changed, where is it concentrated, what needs a decision. Use when the user mentions weekly report, haftalık rapor, yönetim raporu, ops review, KPI summary, or asks to summarize operational data for managers. Differentiator - contract-first reporting with plain-language findings and driver decomposition, never a chart dump.4---56# Weekly Ops Report78A 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.910## Workflow11121. **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.132. **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.143. **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.154. **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.165. **Write findings as sentences**, one line each, using: *METRIC moved X (vs baseline) - DRIVER is the main contributor (Y, ~Z% of the move) - SUGGESTED NEXT STEP.* Tag each finding positive / negative / warning. Maximum five findings; if more qualify, keep the five largest by impact.176. **Assemble in fixed order:** headline KPI cards, findings list, trend view (13 weeks), attention lists (e.g. low-cover SKUs), data-quality footer. Same structure every week - familiarity is what makes deltas visible.187. **Validate before delivering.** Recompute one headline KPI directly from raw rows and match it against the report value. If automation is involved, this check runs inside the pipeline, not in someone's head.1920## Pitfalls to check explicitly2122- Week-over-week only (no baseline) - manufactures fake trends23- Unstated metric definitions - pair every service/on-time figure with its definition footnote24- Commentary drift - keep generated findings rule-based and auditable; human judgment belongs in a clearly separated commentary block, not mixed into computed statements25- Silent denominator changes (cancelled orders, excluded lines) between weeks2627## Output format2829The report skeleton in order: title + period + generation stamp; 4-6 KPI cards with deltas; "What changed and where to look" findings (max 5, tagged); 13-week trends; attention table; data-quality footer listing every issue found.3031Worked implementation (scheduled pipeline, rule-based insight engine): https://github.com/gulmezeren2-byte/auto-report-pipeline
gulmezeren2-byte