Worked example · Weekly reporting
A weekly report with the missing pieces still visible.
Start with the report your team already uses. Agree the sources, reporting period and metric definitions, then inspect what can be assembled and what must remain unknown.
Agree the report before assembling it
A total is useful only when its contributions mean the same thing. This sample combines support-case counts from Email and Chat queues. Each source must cover the agreed week and use the same definitions, with a named person resolving exceptions.
- Sources and coverage
- Both queues are required, each with Day and Evening shift rows. The source list stays fixed when an extract is missing; dropping a source cannot make the report complete.
- Reporting period
- 2026-11-02 00:00 inclusive to 2026-11-09 00:00 exclusive, UTC. A different week or time zone needs compatible source data, not a new label.
- Metric definitions
New support cases: Cases first created during the week, counted once per case.
Resolved support cases: Cases first resolved during the week, including cases created earlier. Counted once per case.
These are sample definitions, not universal support KPIs. New and resolved cases are separate activity counts, not a conversion rate or a backlog calculation. Your team must agree its own boundaries and meaning.
Try four source conditions
Interactive example · synthetic data · local only · no real company data
Build the report. Keep the interpretation.
All rows and corrections are written into this example. No source system is connected and no AI runs. Nothing is sent or saved outside this component. Interpretation and business decisions stay with your team.
- 1Agreed definitions and sources
- 2Coverage and exceptions
- 3Complete or incomplete report
Agreed weekly support report
2026-11-02 00:00 inclusive → 2026-11-09 00:00 exclusive, UTC.
Required: Email and Chat queues, each with Day and Evening shift counts for both metrics. Every case belongs to one queue and one shift in this sample.
- New support cases
- Cases first created during the week, counted once per case.
- Resolved support cases
- Cases first resolved during the week, including cases created earlier. Counted once per case.
These are separate activity counts, not a conversion rate or a backlog calculation. They do not show whether service improved.
Definition: support-cases-v1. Each row summarizes one queue, week, shift and metric. Its record ID is unique within that source. Equal values on different records still count.
Inspect original Email queue source
Status: sample extract provided.
Source period: 2026-11-02 00:00 inclusive → 2026-11-09 00:00 exclusive, UTC.
Source definition: support-cases-v1.
- Row 1 · ID day-new · Day shift · New cases · count 21
- Row 2 · ID day-resolved · Day shift · Resolved cases · count 20
- Row 3 · ID evening-new · Evening shift · New cases · count 21
- Row 4 · ID evening-resolved · Evening shift · Resolved cases · count 17
Inspect original Chat queue source
Status: sample extract provided.
Source period: 2026-11-02 00:00 inclusive → 2026-11-09 00:00 exclusive, UTC.
Source definition: support-cases-v1.
- Row 1 · ID day-new · Day shift · New cases · count 14
- Row 2 · ID day-resolved · Day shift · Resolved cases · count 16
- Row 3 · ID evening-new · Evening shift · New cases · count 14
- Row 4 · ID evening-resolved · Evening shift · Resolved cases · count 15
Inspect the agreed report and sources
Inspect the fixed definitions and original extracts. Checks compare periods, definitions, required rows and repeated identities. They do not interpret the business.
Choose a sample, inspect its sources, then check the report.
See what each source can support
- Matching sources
- Both queues supply the agreed week, case definitions and required shift rows. The report can be complete within this sample's checks. Passing those checks does not explain why activity changed or tell the team what to do.
- Missing source
- The Chat extract is absent. After documenting that absence, you can assemble an incomplete report. Email counts remain clearly labelled partial subtotals; the required combined totals stay unknown. A missing extract is not evidence of zero activity.
- Repeated export row
- One Chat record appears twice with the same identity and values. An explicit count-once decision and note exclude the repeated occurrence while keeping both originals inspectable. Distinct records with equal counts still contribute separately.
- Wrong definition and week
- Chat initially supplies message counts for the previous week. Acknowledging them cannot make them this week's case counts. Inspect and select the separate corrected sample extract, with a note, or leave the source unavailable and the report incomplete.
An incomplete report is a useful, labelled result
When a required source is unavailable, say so beside the unknown total. A compatible source can still contribute a partial subtotal, clearly labelled as partial. Acknowledging the gap lets you assemble an incomplete report; it does not fill the gap or turn the subtotal into a total.
The original rows, periods and definitions stay inspectable beside your source decision and note. A correction uses separate sample evidence. Changing a note or decision clears the assembled report, so old output cannot stand in for the revised checks.
Complete means every agreed source passed this example's checks. It does not establish that service improved. Interpreting results, investigating disputed numbers and deciding what to do remain with your team.
This example stays in local page state. It connects to no source system, sends no report and keeps no saved report history. Reset restores the starting sample.
Check the tools you already use
Check whether your existing tools can produce and schedule the agreed report first. Consider custom work only where a specific source, validation or assembly requirement remains unsupported. The AI, no-code and custom software decision guide can help frame that choice.
If a gap remains, bring the report format, source examples, period boundaries, metric definitions and the person who resolves exceptions. Describe the assembly work you want to change and the interpretation your team needs to keep.