Intraday Management: Reports
Objective. Produce an IDM report for sharing or a review, and understand that a report fixes figures as of a scope and moment that must be stated, and still carries the projection-versus-outcome distinction.
Reports package the day's or period's intraday activity - decisions, drift, action completion - into a shareable artefact for a review or stakeholder, turning the live screens into a record someone can read later.
See it in the demo
What this screen answers
'Can I take today's or this period's intraday story out of the tool and into a review?' Reports serve the moment when the decision loop needs to be communicated - a business review, a stakeholder update, a handover - by rendering the activity into a fixed, shareable form rather than a live screen only one person can drive.
The task
Scope the report to the operation and period that answer the question being asked, generate it, and - before sharing - read it to confirm it says what you think. For a CSM, the task is to pair the report with the customer's own baseline and the honest framing, so the artefact supports the review conversation rather than implying claims the data does not carry.
How to read it
A report is a snapshot: its figures are fixed as of the scope and moment it was generated, which must be stated on the artefact so no one reads a Tuesday report as Thursday's position. Two misreads to avoid: treating a report figure as current when the day has moved on, and treating any projected or simulated figure in it as a delivered outcome. Keep the projection-versus-outcome and process-versus-service distinctions visible in the report itself, not just in your head.
Honest limits
A report does not add evidence beyond its source screens and inherits every feed limit. Which reports exist, their formats and whether they are customisable or exportable is production-dependent - confirm with product. Exact report contents, formats and the demo figures are SME-validation-pending; the handover rule is that deliverables stay editable and honest about scope and recency.
Interpretation check
A report fixes figures as of its scope and moment - state that on the artefact, and never let a projected or simulated figure inside it be read as a delivered service outcome.
In the field
OVO (contact centre): an intraday report feeding a weekly ops review is useful only if it states its period and separates projected fixes from actual results - otherwise the review argues about numbers instead of decisions.
Practical task
On the demo, generate or open one report, check that its scope and timing are clear and that any projected figure is distinguishable from actuals, and write a one-line note on what you would add before sharing it.
Self-check
A report generated Tuesday is shared Thursday. What must the reader understand?
That its figures are a snapshot fixed as of Tuesday's scope and moment, not the current position. The scope and generation time must be stated on the artefact to prevent a stale read.
A report contains what-if projections. How should they appear?
Clearly labelled as projections on assumptions, distinct from actuals, so no reader mistakes them for delivered outcomes. The projection-versus-outcome distinction must be visible in the report itself.
Does a report prove anything the live screens did not?
No. It packages the same source data and inherits its limits. Its value is shareability and record, not new evidence - and it must be paired with the customer's own baseline for any value claim.
A prospect asks whether reports export to their format. What is the safe answer?
Confirm with product - report formats, customisation and export are production-dependent. The demo shows the reporting model, not a guarantee of a given customer's options.
Verified vs demo. Screen is live in the demo at /#/reports; exact report contents, formats, export options and figures are SME-validation-pending.