Choose the decision the report supports
Ask the intended reader what they need to decide. A service manager may need to identify work waiting too long. A programme lead may need to compare progress across locations. Those questions require different views and definitions.
Write the question in ordinary language before choosing a chart. Then identify the few measures that help answer it. This prevents a report from becoming a collection of whatever numbers are easiest to obtain. If a measure has no clear use, consider leaving it out of the first version.
Define each measure carefully
Terms that sound obvious often hide different interpretations. A “completed request” could mean a decision was recorded, a response was sent or the requested work actually finished. Agree the definition, relevant dates and any exclusions.
Record those choices in a short metric dictionary. Include the owner and the source information. When the definition changes, record the change rather than silently comparing unlike periods. A reader should be able to understand what a number represents without asking the original analyst to explain it each month.
Check the records before the chart
Look for duplicates, missing values and inconsistent labels. Compare a sample of the prepared records with the original information. Investigate differences before combining them into a summary.
For a service report, two records might describe the same request or two genuinely separate tasks. That distinction matters. Agree a matching rule with the service team and keep uncertain cases visible for review. Data preparation should make the information more understandable, not conceal ambiguity by forcing every record into a convenient category.
Show context that changes the interpretation
A chart needs enough context to support a sensible reading. Label the period, unit and relevant comparison. Where information is incomplete, show that limitation near the result. A small number of observations should not be presented with the same confidence as a well-established pattern.
Design the report around the reader’s sequence of questions. Start with the overall position, then provide a way to investigate the parts that need attention. Use tables where exact values matter and charts where the pattern is the useful information.
Make the report maintainable
Check the finished view against known examples and ask the intended users to explain what they would do with it. Resolve disagreements about meaning before widening access. Provide a simple guide covering definitions, routine checks and who handles questions.
The deliverables include the data-quality findings, a metric dictionary, a dashboard and a reconciliation record. The test of usefulness is whether the next person can update it and reach the same interpretation from the same evidence. A report that depends on one person’s memory is difficult to sustain.
Explore our Data quality, migration and useful dashboards, related services and Map your applications before planning a replacement.