Scheduling: Reports
Objective. Scope and generate a shareable report of coverage, violations, overtime/VTO and acknowledgment for a period - naming the scope, period and schedule version so two reports do not silently disagree.
Reports answer: can I produce a shareable record of the schedule's state for a team and period? The key read is that a report is a snapshot of a chosen scope, period and version, and is planned data unless it is explicitly an actuals report.
See it in the demo
What this screen answers
A Sales or CSM person opens reports to answer: can I extract a clear, shareable record - coverage, rule exceptions, overtime and VTO, acknowledgment - for a defined team and period, to use in a review or a handover? It turns the schedule into evidence others can read.
The task
Choose the team, period and schedule version, and generate the relevant report. State those parameters explicitly on the output so a reader knows exactly what the report covers and which version it reflects.
How to read it
A report is a snapshot of the schedule state at the scope, period and version you chose - change any one and the numbers change. Define them clearly or two reports of 'the same week' will disagree because they used different versions or periods. A scheduling report reflects planned schedule data unless it is explicitly an actuals report - confirm which before presenting it as outcome. The misread to avoid: comparing two reports without checking they share scope, period and version.
Honest limits
A report reflects its parameters, not an objective truth, and planned data is not delivery. Confirm with product which report types, export formats and actuals-vs-planned distinctions are available for a customer; the demo uses seeded data.
Interpretation check
A report reflects the scope, period and schedule version you set - and it is planned data, not actual, unless stated; name those parameters before comparing or presenting it.
In the field
A CSM preparing a scheduling pack for a business review: labelling each report's period and version prevents the classic 'these two numbers disagree' confusion when the sponsor compares them.
Practical task
On the demo, generate one report for a team and period and write the scope/period/version it reflects, plus whether it is planned or actuals data.
Self-check
Two reports of 'the same week' show different numbers. What is the likely cause?
They used different scope, period or schedule version. A report is a snapshot of chosen parameters - align them before concluding the data is wrong.
Can you present a scheduling report as proof of what was delivered?
Only if it is explicitly an actuals report. By default it reflects planned schedule data; delivery is confirmed in RTA and output. Confirm which before presenting.
What must always accompany a report you share?
Its scope, period and schedule version, so the reader knows exactly what it covers and cannot misread a planned snapshot as actual outcome.
Verified vs demo. Screen is live in the demo at /#/reports; exact controls, labels and figures are SME-validation-pending.