PRACTICAL WORKSHOP · 50 MINUTES

Build a trustworthy management dashboard

A practical pensions administration workshop, not a quiz

Build a decision-ready dashboard specification using a small fictional case ledger. Define the measures, check the arithmetic, sketch the page and prepare a controlled review and handover.

No quizzes, scores or assessed completion. Work on paper or in an approved blank Word document. This page does not collect or save your notes or track workshop progress.

Use fictional information only. Do not enter real member, customer or payroll data, passwords or confidential files into this course or external AI tools.

Before you begin: safety and scope

Use only the synthetic Harbour dataset supplied here. Do not enter real member, beneficiary, employee or payroll data, National Insurance numbers, bank details, health information, credentials or confidential organisational information in this workshop, AI tools or shared training files. Changing a real name does not make the remaining data safe. This workshop gives no authority to connect a live source, share a dashboard, change permissions or deploy a service.

This is a reporting and service-management exercise, not a guide to benefit calculation or legal compliance. A real pensions administration dashboard must use the relevant scheme’s approved definitions, service commitments, information-handling rules and decision authorities. For LGPS (NI), do not import another jurisdiction’s scheme rules. The fictional 10-calendar-day expectation below is only a teaching convention.

Work through six modules in order. The 50-minute estimate includes reading and short practical tasks; use up to 60 minutes if you want to try the optional AI prompts.
Use paper or an approved blank document. A calculator is sufficient; a spreadsheet or BI product is optional. No licence-specific feature is needed to complete the workshop.
Copy only the fictional ledger supplied after the modules. It is a separate teaching extract, not the full workload used in the strategy workshop.
Optional Copilot prompts can help draft definitions, explanations or tests. Use only an account and tool permitted for this training task; review the result yourself and do not enable new data connections.
There are no marks or multiple-choice questions. Completion means you have a dashboard sketch, metric dictionary, checked results and a review/handover note.
All roles, dates, service expectations and proposed actions in the examples are invented training assumptions. They are not organisational policies, legal deadlines or claims about a real pensions service.
The 50-minute core uses the six lessons and selected exercises. Worked answers, the full ledger, extra checks and Copilot prompts are reference material: open the parts you need rather than reading every template in sequence.
Optional Copilot assistance: check your signed-in account, licence and employer’s approval. Microsoft supports some personal Premium use with work documents under administrator controls, but features vary. This course uses synthetic material only, regardless of licence. Never paste real member data or connect organisational sources for these exercises. Review outputs yourself.

Start the workshop

Harbour’s synthetic employer-query extract

You are helping the fictional Harbour Pensions Service prepare an operations review of employer-file queries. The manager wants to understand why waiting work is growing without overlooking rework or overstating data quality. Your task is to turn a separate 20-case teaching extract into a trustworthy dashboard specification and a defensible decision, not to publish a live report.

Reporting period: 1–28 September 2026 inclusive. Opening backlog is immediately before 1 September; closing backlog and open-case age are measured at the end of 28 September.
This extract contains one case type and one row per synthetic case. Four cases were already open, 16 arrived during the period, 12 completed and eight remained open. There are no cancellations, transfers, duplicate IDs or reopened cases in this fixture.
Use calendar-date subtraction with no clock pauses: completed date minus received date for turnaround; 28 September minus received date for open-case age. A same-day interval is zero days.
The fictional internal expectation is completion within 10 calendar days, inclusive. Nine of 12 completions meet it; three of eight open cases are already older than 10 days.
Three of the 12 completed cases had at least one avoidable correction recorded before closure. Rework is counted once per completed case, not once per correction event.
At the snapshot, 17 of all 20 case rows have the required reference recorded as present. This is one-field completeness for this extract only, not accuracy, first-pass acceptance or a whole-scheme data-quality score.
The supplied ledger and worked calculations appear in the templates section. All values are invented and have been arithmetically checked.

MODULE 1 OF 6 · 7 MINUTES

1. Start with the decision

You will: Identify the dashboard audience and the decision it supports. Keep the first page small and balanced.

Scenario

You are preparing a short operations review for Harbour’s service manager and employer liaison lead. A colleague suggests a large wall of green indicators because 12 cases have been completed. Your goal is to show whether the service is keeping up and what needs investigation, without confusing completed work with everyone’s experience.

Example

Turn a reporting wish into a decision

“Show 12 completions” describes an output. Harbour’s stronger question is: “With 16 arrivals and 12 completions, should we first investigate the oldest open queries or change how we manage intake?” The proposed page pairs the growing backlog with open-case age, rework and a clear warning about missing references. The ledger does not identify the cause, so the first decision is a bounded investigation rather than a staffing conclusion.

Takeaway: Choose a decision before choosing a visual.

Your task

Name the two fictional readers and one decision they need to make.
Choose four measure groups: workload, turnaround, rework and data quality.
Write one question the supplied data cannot answer.
State what information and actions are outside this training dashboard.

Your output: A dashboard purpose and a clear scope.

Working-note template

Audience: ___
Decision to support: ___
Scope and period: ___
Four measure groups: ___
Evidence we do not yet have: ___
Excluded information and actions: ___
Optional AI drafting help: see the Optional Copilot help: Start with the decision template.

Reflect: What important risk would the reader miss if the page showed only completed work?

Read the lesson: why this matters

Start by writing what the reader must decide. A useful question is: “Which part of this service needs attention next, and what evidence supports that choice?” Choose a narrow service and reporting period before deciding on colours, charts or software.

Use a balanced set of measures. Flow shows work received and completed; backlog and age show work still waiting; turnaround shows elapsed time for completed cases; rework and data quality show whether speed is being achieved safely. A count of completions alone cannot show whether the queue is growing.

Separate facts, interpretations and proposed actions. A rising backlog is evidence of an imbalance in this extract. Staff shortage, complex cases and poor input information are possible explanations, not findings established by these five columns.

Keep the audience and data need proportionate. This management sketch needs aggregate results and synthetic references for a teaching investigation, not names, payroll values or member-level details. Real operational access and drill-through would need their own approved design.

Sources for this module

MODULE 2 OF 6 · 9 MINUTES

2. Write the metric dictionary

You will: Specify the population, dates and counting rules for each measure. Keep completion performance separate from open-case ageing.

Scenario

You are agreeing definitions with Harbour’s reporting colleague before anyone builds a chart. One person counts calendar days, another stops the clock while awaiting information, and a third calls blank completion dates zero-day completions. Your goal is to write one reproducible set of training definitions so that the same extract produces the same result.

Example

Define two different timeliness questions

Completed-case timeliness is 9 cases completed in 10 calendar days or fewer ÷ 12 completions = 75%. Open-case ageing is a different population: 3 cases aged more than 10 days ÷ 8 open cases = 37.5%, with an oldest age of 29 days. The first measure describes completed work; the second shows waiting work already beyond the fictional expectation. Neither is a legal compliance measure.

Takeaway: Do not let a convenient denominator hide people still waiting.

Your task

Use the metric dictionary template to define closing backlog, completed turnaround, rework and reference completeness.
Write the numerator and denominator for both completed-case timeliness and open cases older than 10 days.
Record calendar days, the fixed snapshot date and the rule that blank completion means open.
Add one limitation and a fictional review owner to each measure.

Your output: A metric dictionary with explicit counting and date rules.

Working-note template

Metric name and decision: ___
Population and counting unit: ___
Numerator / denominator, or aggregation: ___
Reporting period or snapshot: ___
Calendar and clock rules: ___
Inclusions, exclusions and missing-value rule: ___
Source and version: ___
Owner and reviewer: ___
Limitation: ___
Optional AI drafting help: see the Optional Copilot help: Write the metric dictionary template.

Reflect: Would two colleagues independently calculate the same result from your definitions?

Read the lesson: why this matters

A metric dictionary records the name, purpose, population, formula, time basis, exclusions, source, owner and limitation. A percentage also needs its numerator and denominator. A count needs its counting unit: here it is distinct case ID, not rows produced by joining several logs.

The reporting period is 1–28 September inclusive. Opening backlog includes cases received before 1 September and not completed before that date. Closing backlog includes cases received by 28 September with no completion by that date. The fixture has no cancellations, transfers or reopenings; a real reconciliation would need separate agreed treatment for each.

For this exercise, completed turnaround equals completed date minus received date in calendar days, with no pauses. The completion-based timeliness denominator is the 12 cases completed within the reporting period, including three received earlier. Open cases have no turnaround result yet. Their age uses the fixed 28 September snapshot, not today’s date.

Rework means a completed case recorded as needing at least one avoidable correction before closure. Count each such case once. Reference completeness means rows marked Yes for required_reference_present divided by all 20 rows in this extract at the snapshot. A present value may still be wrong; this check does not measure accuracy or first-pass submission acceptance.

Sources for this module

MODULE 3 OF 6 · 10 MINUTES

3. Calculate and reconcile the evidence

You will: Reconcile the case flow and reproduce the main results. Handle missing data and edge cases without hiding them.

Scenario

You are checking the first draft of Harbour’s numbers using the supplied 20-row ledger. A proposed chart labels all 20 records as completions and therefore understates the rework rate. Your goal is to rebuild the results from defined populations and leave an audit trail that another colleague can repeat.

Example

Reproduce Harbour’s results

The flow is 4 + 16 − 12 = 8, an increase of four open cases. Sorted completed durations are 4, 5, 6, 7, 8, 8, 8, 9, 9, 11, 11 and 12 days: median 8 days; 9/12 meet the fictional expectation, or 75%. Rework is 3/12 = 25%, not 3/20. Required-reference completeness is 17/20 = 85%, leaving three missing. Open ages are 0, 3, 5, 6, 9, 16, 23 and 29 days; three are over 10 days.

Takeaway: Reconcile counts before trusting percentages or visuals.

Your task

Calculate the opening, received, completed and closing counts. Show the reconciliation.
Reproduce timeliness, median turnaround, rework and reference completeness with their denominators.
List the eight open-case ages and identify the three older than 10 days.
Check the four weekly reconciliations against the worked results, then record one edge-case test you would use before a real build.

Your output: A reproducible calculation sheet with reconciled totals and limitations.

Working-note template

Flow reconciliation: ___ + ___ − ___ = ___
Weekly opening / received / completed / closing: ___
Completed durations and median: ___
Within fictional expectation: ___ / ___ = ___
Rework among completions: ___ / ___ = ___
Reference completeness in the extract: ___ / ___ = ___
Open-case ages and oldest age: ___
Cases older than 10 days: ___ / ___ = ___
Check performed / result / evidence: ___
Optional AI drafting help: see the Optional Copilot help: Calculate and reconcile the evidence template.

Reflect: Can you trace every displayed number back to the included synthetic case IDs?

Read the lesson: why this matters

Copy the synthetic ledger from the templates section and keep an unchanged source copy. If using a spreadsheet, import the received and completed fields as dates, preserve empty completion cells, and confirm Yes, No and NA stay distinct. You can also work directly from the rows with a calculator.

First reconcile the flow: opening backlog + received − completed = closing backlog. Repeat it for each week using that week’s boundaries. Do not add weekly closing balances to obtain a monthly backlog; they are snapshots of overlapping work, not separate flows.

For the 12 completions, calculate each elapsed interval, count those at 10 days or fewer and sort the intervals for the median. With an even count, the median is the mean of the two middle values. Separately calculate ages for the eight open cases using 28 September. Retain counts beside rates so small denominators stay visible.

Check unique IDs, valid dates, completion not before receipt, allowed values and consistent missing-data rules. Do not silently remove a duplicate, replace a missing date or treat no observations as 0% success. In an empty completion period, report no completed cases and show turnaround, timeliness and rework as NA, with the denominator zero.

Sources for this module

MODULE 4 OF 6 · 8 MINUTES

4. Sketch a page that can be read correctly

You will: Arrange the measures so the service story is easy to understand. Show dates, scope, denominators and warnings without relying on colour.

Scenario

You are sketching Harbour’s one-page report for a manager who has five minutes to read it. The initial design uses large percentages but hides the reporting date and makes a missing-data warning hard to find. Your goal is to make the decision, supporting evidence and limitations visible before considering a reporting product.

Example

A compact page with the caveat in view

Harbour’s sketch shows eight cases open, up four; median completed turnaround of eight calendar days and 9/12 within the fictional expectation; rework 3/12; and reference completeness 17/20. Supporting panels show weekly arrivals of 4, 4, 4, 4 against completions of 3, 4, 2, 3, plus open-age bands with counts 4, 1, 1, 2. A visible note says the 20-row extract is synthetic, one-field completeness is not accuracy, and causes have not been established.

Takeaway: Make the scope and caveat as easy to find as the headline number.

Your task

Draw one page using the blank dashboard sketch template.
Fill the four headline areas and two supporting views using your checked values.
Add the period, snapshot date, fixed-fixture label, denominator notes and one limitation.
Describe the page in two sentences for someone who cannot see the charts.

Your output: An annotated dashboard sketch with an accessible text summary.

Working-note template

PAGE TITLE AND DECISION: ___
Scope / period / snapshot / source freshness: ___
TOP ROW
Workload: ___ | Completed turnaround: ___ | Rework: ___ | Data quality: ___
SUPPORTING VIEWS
Weekly arrivals and completions: ___
Open-age bands and oldest case age: ___
VISIBLE LIMITATIONS: ___
DECISION AND OWNER: ___
Text alternative: ___
Optional AI drafting help: see the Optional Copilot help: Sketch a page that can be read correctly template.

Reflect: Could the reader mistake old data, a filtered view or a small sample for the whole current service?

Read the lesson: why this matters

Put the page purpose, case type, reporting period, snapshot date and last successful refresh at the top. The data-through date and refresh time are different: a report refreshed today can still contain an old extract. In this static workshop, label the ledger as a fixed training fixture rather than pretending it has a live refresh.

Use a small number of headline measures, then supporting evidence. The top row can show closing backlog and change, completed-case median and timeliness, rework, and required-reference completeness. Beneath it, pair arrivals and completions by week with an open-age distribution. Keep the open cases older than 10 days visible.

Use bars for comparisons with a zero baseline, direct values and clear units. A short run of four weekly points is descriptive, not proof of a long-term trend. Show counts beside percentages and give a text alternative to the chart. Colour may add emphasis but must not carry the only meaning.

Any filter must make its scope clear and update related numerator and denominator populations consistently. Reset filters visibly. For a real build, verify the ability to view or export underlying detail separately from the visual design. This exercise authorises neither sharing nor adding drill-through to member records.

Sources for this module

MODULE 5 OF 6 · 8 MINUTES

5. Test whether the dashboard deserves trust

You will: Specify checks for confidentiality, integrity and availability. Define visible failure and safe handover behaviour.

Scenario

You are reviewing the dashboard design before a colleague turns it into a working report. A refresh failure could leave yesterday’s green indicators on screen, while an unexpected export might reveal more detail than the manager needs. Your goal is to specify tests and operating controls before anyone connects real information.

Example

A small test pack with observable outcomes

Harbour’s training test pack checks that H004 remains open and has age 29 at the snapshot, H020 has age zero, and H015’s 11-day duration misses the fictional expectation. A separate synthetic same-day closure should produce zero days; a closure exactly at 10 days should meet the expectation. A duplicate-ID test must raise an exception rather than silently alter counts. A simulated failed refresh must visibly label the last result as stale or unavailable.

Takeaway: A trustworthy report makes its failures and limits visible.

Your task

Write one confidentiality, one integrity and one availability control with an owner and evidence.
Choose four calculation or data-validation tests and record the expected outcome before running them.
Describe what the reader sees after a failed refresh and who resolves it.
Add a stop condition that prevents an unverified result being presented as decision-ready.

Your output: A small assurance checklist and a visible-failure plan.

Working-note template

Risk / control / owner / evidence / exception route: ___
Confidentiality check: ___
Integrity check: ___
Availability check and deputy: ___
Test fixture / expected result / actual result / status / evidence: ___
Failed-refresh display and fallback: ___
Stop condition: ___
Optional AI drafting help: see the Optional Copilot help: Test whether the dashboard deserves trust template.

Reflect: What would prevent a plausible but wrong number being used to make a service decision?

Read the lesson: why this matters

Confidentiality asks who can view the page, download it and access its source or underlying detail. Prefer the minimum necessary information and an approved audience. In a real setting, aggregation alone does not guarantee anonymity, particularly for small groups; follow the organisation’s approved disclosure and access approach rather than inventing a threshold.

Integrity asks whether the report remains correct as data and definitions change. Keep an identified source version, documented transformation rules, a unique-case check, reconciled totals and independent expected results. Test date boundaries, missing dates, duplicates, an empty completion period and a filtered subset. Record unresolved exceptions rather than hiding them.

Availability asks whether the authorised reader can obtain reliable information when needed. Show the last successful refresh and data-through date. If a future refresh fails, display a clear failure or stale-data warning and use an agreed, labelled fallback; do not silently present the previous result as current. Name a primary owner and deputy.

Keep approval and evidence proportionate to the real risk. A built visual is not necessarily deployed, and a deployed visual is not necessarily verified. Before real use, the appropriate owners need evidence for calculations, permissions, freshness, accessibility and failure handling. Completing this workshop does not grant that approval.

Sources for this module

MODULE 6 OF 6 · 8 MINUTES

6. Turn the dashboard into a management action

You will: Write an evidence-based action without claiming an unproved cause. Assemble a practical dashboard specification and handover note.

Scenario

You are presenting the checked Harbour results to the fictional service manager. The group wants to reduce waiting time, but the ledger contains no case-complexity, staffing or root-cause evidence. Your goal is to agree a limited next step, a named owner and a review point while preserving the distinction between facts and assumptions.

Example

A measured next step

Harbour’s fictional operations lead proposes checking the reasons for delay on H004, H008 and H012, while the reporting colleague resolves the evidence behind the missing-reference flags on H004, H012 and H019. The training review point is the next fictional weekly review, not a promise about real case handling. Closure evidence is a documented delay reason, an agreed next action and a rerun with reconciled counts, not simply a greener dashboard. Any proposed input-process change remains a hypothesis until supported.

Takeaway: Record the decision and evidence needed, not just the colour of the indicator.

Your task

Write a three-sentence review: observed fact, limitation and proposed next action.
Complete the decision log with a fictional owner, review point and closure evidence.
Assemble the final dashboard pack using the blank specification and worked example below.
Review your pack against the completion checklist. Mark completion when the artifact is ready for discussion, not when an AI tool agrees with it.

Your output: A complete draft dashboard specification and review/handover note.

Working-note template

Observed fact: ___
What we cannot yet conclude: ___
Proposed next action: ___
Decision owner: ___
Review point and closure evidence: ___
Reason to stop or revise: ___
Pack status: Draft for discussion
Optional AI drafting help: see the Optional Copilot help: Turn the dashboard into a management action template.

Reflect: What will someone do differently because this page exists, and how will you know that helped?

Read the lesson: why this matters

Run a short review in a consistent order: confirm data fitness and scope, identify the material change, inspect the balancing measures, then decide the next action. A warning about missing or stale data comes before performance interpretation. A dashboard can support judgement, but it cannot supply evidence that was never collected.

In this fixture, backlog grows because 16 arrivals exceed 12 completions. The three oldest open cases warrant investigation, and the incomplete-reference flag overlaps two of them. That association does not prove the missing references caused their age. Do not use this tiny extract to rank staff or promise a capacity saving.

Write the decision as action, owner, review point and closure evidence. State what observation would support changing the plan. A real target needs an agreed basis and authority; this exercise uses a fictional expectation solely to demonstrate reporting. Avoid changing a denominator or closing easy cases merely to improve an indicator.

Finish the handover with the purpose, dictionary, source, calculation checks, sketch, limitations, controls and review log. Label the pack Draft for discussion. In real use, any deployment, access or connection decision would follow the appropriate approval route, separate from completion of this workshop.

Sources for this module

Your working templates

Use the blank templates for your fictional exercise. Compare your approach with the worked examples, not with a pass mark.

Synthetic case ledger: copyable source data

FICTIONAL TRAINING DATA ONLY
This 20-row extract covers one case type, employer-file queries. It is not the whole Harbour service. Blank completed_date means still open at the end of 2026-09-28; NA in rework_at_close means not applicable because the case is not closed. required_reference_present is a recorded check result at the snapshot, not the reference itself. No real names, employers, member identifiers or payroll values are included.

case_id,received_date,completed_date,rework_at_close,required_reference_present
H001,2026-08-20,2026-09-01,Yes,Yes
H002,2026-08-25,2026-09-03,No,Yes
H003,2026-08-28,2026-09-08,No,Yes
H004,2026-08-30,,NA,No
H005,2026-09-01,2026-09-05,No,Yes
H006,2026-09-02,2026-09-08,No,Yes
H007,2026-09-03,2026-09-10,Yes,Yes
H008,2026-09-05,,NA,Yes
H009,2026-09-08,2026-09-13,No,Yes
H010,2026-09-09,2026-09-18,No,Yes
H011,2026-09-10,2026-09-18,Yes,Yes
H012,2026-09-12,,NA,No
H013,2026-09-15,2026-09-23,No,Yes
H014,2026-09-16,2026-09-24,No,Yes
H015,2026-09-17,2026-09-28,No,Yes
H016,2026-09-19,,NA,Yes
H017,2026-09-22,,NA,Yes
H018,2026-09-23,,NA,Yes
H019,2026-09-25,,NA,No
H020,2026-09-28,,NA,Yes

Metric dictionary: blank template

DRAFT FOR DISCUSSION
Metric name: ___
Decision supported: ___
Population and counting unit: ___
Formula or aggregation: ___
Numerator and denominator, if a percentage: ___
Period or snapshot and inclusive boundaries: ___
Clock/calendar rules: ___
Inclusions, exclusions and missing-value treatment: ___
Source, version and refresh/data-through dates: ___
Metric owner and independent reviewer: ___
Proposed expectation, if any, and its authority: ___
Known limitation: ___
Check and evidence: ___

Metric dictionary: worked Harbour example

DRAFT FOR DISCUSSION. All measures use distinct case IDs from synthetic ledger v1. Fictional reporting owner: reporting colleague. Fictional reviewer: operations lead. Data-through and snapshot date: 28 September 2026. This is a static fixture, not a live refresh.

Closing backlog: cases received on or before 28 September and not completed by that date. Count = 8. Includes waiting-for-information cases. Limitation: count gives no effort or urgency. Check against 4 opening + 16 received − 12 completed.

Received and completed flows: received dates or completed dates, respectively, from 1–28 September inclusive. Received = 16; completed = 12. A case can appear in both flows. Cases received earlier but completed in the period count as completions. No cancellations, transfers or reopenings occur in this fixture.

Median completed turnaround: calendar days between received and completed dates, for the 12 period completions only. No paused clock. Sort all 12 intervals; the middle two are 8 and 8, so median = 8 days. Missing completion dates are excluded as open, never set to zero. Limitation: does not describe open cases or hands-on effort.

Completed-case timeliness: number of period completions with duration ≤10 calendar days ÷ all period completions = 9/12 = 75%. The 10-day expectation is fictional, not a scheme or legal standard. A zero denominator gives NA, not 0% or 100%.

Open cases older than 10 days: cases in the closing backlog with 28 September minus received date >10 days ÷ all eight closing cases = 3/8 = 37.5%. Oldest age = 29 days. The same-day arrival has age zero. Limitation: age does not establish cause or priority by itself.

Rework among completions: period completions marked Yes for at least one avoidable correction before closure ÷ all 12 period completions = 3/12 = 25%. Count a case once even if several corrections occurred. Open cases have NA at close and are excluded. Limitation: this does not estimate all rework effort or future rework in open cases.

Required-reference completeness: all extract rows marked Yes for required_reference_present ÷ all 20 extract rows = 17/20 = 85%. Three rows are marked No. This population deliberately includes completed and open cases. Limitation: one-field completeness at one snapshot; not accuracy, first-pass acceptance or whole-scheme quality.

Worked calculations and case sets

PERIOD FLOW
Opening: H001, H002, H003, H004 = 4.
Received: H005 through H020 = 16.
Completed: H001, H002, H003, H005, H006, H007, H009, H010, H011, H013, H014, H015 = 12.
Closing: H004, H008, H012, H016, H017, H018, H019, H020 = 8.
Reconciliation: 4 + 16 − 12 = 8. Change: +4 cases; a 100% increase from a small opening base of four, so show the absolute change prominently.

WEEKLY FLOW
1–7 September: opening 4; received 4; completed 3; closing 5.
8–14 September: opening 5; received 4; completed 4; closing 5.
15–21 September: opening 5; received 4; completed 2; closing 7.
22–28 September: opening 7; received 4; completed 3; closing 8.
Received total = 16; completed total = 12. Do not sum weekly opening or closing snapshots.

COMPLETED TURNAROUND IN CALENDAR DAYS
H001 12; H002 9; H003 11; H005 4; H006 6; H007 7; H009 5; H010 9; H011 8; H013 8; H014 8; H015 11.
Sorted: 4, 5, 6, 7, 8, 8, 8, 9, 9, 11, 11, 12.
Median = (8 + 8) / 2 = 8 days. Optional mean = 98 / 12 = 8.17 days, rounded to 8.2; neither measure reveals the open queue.
Meet ≤10 days: H002, H005, H006, H007, H009, H010, H011, H013, H014 = 9/12 = 75%.
Over 10 days at completion: H001, H003, H015 = 3/12 = 25%.

OPEN AGE AT END OF 28 SEPTEMBER
H004 29; H008 23; H012 16; H016 9; H017 6; H018 5; H019 3; H020 0 days.
Age 0–7 days: 4 cases. Age 8–14: 1. Age 15–21: 1. Age 22+: 2. Total = 8.
Over 10 days: H004, H008, H012 = 3/8 = 37.5%. Oldest = 29 days.

REWORK AND COMPLETENESS
Rework at close Yes: H001, H007, H011 = 3/12 = 25%.
Required reference absent: H004, H012, H019 = 3/20 = 15%; present = 17/20 = 85%.
Two of the three oldest open cases have a missing reference, but the ledger provides no evidence that this caused the delay.

One-page dashboard sketch: blank template

DRAFT FOR DISCUSSION
TITLE AND DECISION: ___
Audience: ___
Case type / included population / filters: ___
Reporting period: ___
Snapshot date: ___
Data-through date / last successful refresh or static-fixture label: ___

HEADLINE AREAS
Workload: opening ___; received ___; completed ___; closing ___; change ___
Completed turnaround: median ___ days; within expectation ___ / ___ (___%)
Rework among completions: ___ / ___ (___%)
Specified data-quality check: ___ / ___ (___%)

SUPPORTING VIEWS
Weekly arrivals and completions, with exact values: ___
Open-case age bands, with exact values: ___
Open cases beyond the fictional expectation: ___ / ___; oldest ___ days

DEFINITIONS AND LIMITATIONS: ___
DATA-FITNESS OR STALE-DATA WARNING: ___
PROPOSED DECISION / OWNER / REVIEW POINT: ___
ACCESSIBLE TEXT SUMMARY: ___

One-page dashboard sketch: worked Harbour example

HARBOUR EMPLOYER-QUERY REVIEW
Decision: choose a bounded investigation into growing and ageing waiting work.
Audience: fictional service manager and employer liaison lead.
Scope: 20 synthetic employer-file query cases, no filters.
Reporting period: 1–28 September 2026. Snapshot/data-through: 28 September 2026. Source: static training fixture v1, not a live refresh.

HEADLINE AREAS
Workload: 4 opening + 16 received − 12 completed = 8 open; change +4.
Completed turnaround: median 8 calendar days; 9/12 (75%) within the fictional 10-day expectation.
Rework: 3/12 completed cases (25%) needed at least one avoidable correction.
Required-reference completeness: 17/20 extract rows (85%); three missing.

SUPPORTING VIEW 1: WEEKLY ARRIVALS AND COMPLETIONS
Use paired bars, a zero baseline and direct count labels.
1–7 Sep: arrived 4; completed 3.
8–14 Sep: arrived 4; completed 4.
15–21 Sep: arrived 4; completed 2.
22–28 Sep: arrived 4; completed 3.
Closing balances, shown as labelled supporting figures: 5, 5, 7, 8.

SUPPORTING VIEW 2: OPEN AGE
Use horizontal bars, a zero baseline and direct labels.
0–7 days: 4; 8–14 days: 1; 15–21 days: 1; 22+ days: 2.
Explicit annotation: 3/8 open cases are older than 10 days; oldest 29 days.

VISIBLE LIMITATIONS
Synthetic extract only; one case type; small denominators. No cause, staffing, effort or whole-service conclusion is established. Completeness is one field, not accuracy. The 10-day expectation is invented for learning.

PROPOSED DECISION
Investigate the three oldest open cases and the three missing-reference flags; record evidence before changing the process. Owner: fictional operations lead with reporting colleague. Review: next fictional weekly review.

TEXT SUMMARY
Sixteen arrivals exceeded 12 completions, so the open queue grew from four to eight; three open cases are already older than the fictional expectation. Completed-case timeliness is 9/12, rework is 3/12, and three of the 20 reference checks are incomplete, so the next step is to investigate rather than claim a proven cause.

Control and test log: blank template

DRAFT FOR DISCUSSION
Control area: confidentiality / integrity / availability
Risk: ___
Control or test: ___
Fixture or scope: ___
Expected outcome, written before testing: ___
Actual outcome: ___
Status: proposed / run and passed / run and failed / blocked
Evidence and source version: ___
Owner and independent reviewer: ___
Exception and next action: ___

Stop before decision use if: ___
Failed-refresh warning: ___
Fallback and deputy: ___
Real access, connection or deployment approval still needed: ___

Control and test log: worked Harbour example

DRAFT FOR DISCUSSION
Integrity arithmetic checks completed on the supplied fixture: 20 distinct IDs; all completion dates are on or after received dates; flow 4 + 16 − 12 = 8; weekly balances reconcile; median 8; timeliness 9/12; rework 3/12; completeness 17/20. This verifies fixture arithmetic, not a software implementation.

Boundary checks evidenced in the supplied fixture: H004 is open with age 29, H020 has age zero, and H015 completed in 11 days and does not meet the fictional expectation.

Additional proposed tests, not executed against a reporting implementation: same-day closure returns zero days; exact 10-day closure meets the expectation; a received date after the snapshot is excluded; duplicate ID is flagged; completion before receipt is rejected or quarantined; no completions gives NA for completion-based rates and median; consistent filters alter both rate populations; failed refresh visibly marks the last result stale or unavailable.

Confidentiality proposal: approved aggregate audience only; review both page and underlying-source/export permissions before any real deployment. Evidence needed: authorised access test with permitted and non-permitted test identities. No such permission test has been performed by this workshop.

Availability proposal: name a primary owner and deputy, display data-through and last-successful-refresh information, and agree a labelled fallback. Evidence needed: authorised simulated failure and recovery test.

Stop condition: unresolved reconciliation, stale-data ambiguity, incorrect case scope or unreviewed access prevents the result being presented as decision-ready. The appropriate owner resolves the issue and records the rerun evidence.

Final dashboard specification and handover: blank template

DRAFT FOR DISCUSSION | SYNTHETIC TRAINING ONLY
Purpose and decision: ___
Audience and scope: ___
Period, snapshot and data-through date: ___
Source and version: ___
Metric dictionary location and reviewer: ___
Checked results with denominators: ___
Reconciliation and calculation evidence: ___
Dashboard sketch and text alternative: ___
Known limitations and unresolved questions: ___
Confidentiality control: ___
Integrity control: ___
Availability, freshness, owner and deputy: ___
Tests executed with evidence: ___
Tests only proposed or not yet possible: ___
Observed fact: ___
Hypothesis, clearly labelled: ___
Proposed decision / owner / review point / closure evidence: ___
Stop or revise if: ___
Status: draft / implemented / deployed / verified, supported by specific evidence
Approvals needed before any real use: ___

Final dashboard specification and handover: worked Harbour example

DRAFT FOR DISCUSSION | SYNTHETIC TRAINING ONLY
Purpose: help Harbour’s fictional service manager decide what to investigate in a growing employer-query queue.
Scope: the 20-case teaching extract only; 1–28 September 2026 inclusive; end-of-28-September snapshot; no filters, live connections, publication or member-level drill-through.
Source: synthetic case ledger v1. Dictionary, worked calculations and one-page sketch are included in this pack.
Checked results: 4 opening + 16 received − 12 completed = 8 closing; median completed turnaround 8 calendar days; 9/12 within the fictional expectation; rework 3/12; reference completeness 17/20; three of eight open cases over 10 days, oldest 29. Weekly flow also reconciles.
Limitations: small fictional extract, one case type, no effort or root-cause data. Completeness is not accuracy. The 10-day expectation is not a real service or legal requirement.
Confidentiality proposal: aggregate audience and underlying access/export controls reviewed by the appropriate owner before real use.
Integrity proposal: versioned dictionary, distinct IDs, date checks, reconciliations and independent review. Fixture arithmetic has been checked; a reporting implementation has not been built or tested by completing this pack.
Availability proposal: visible freshness and failure state, named owner and deputy, agreed labelled fallback. Operational failure and access tests remain proposed.
Fact: arrivals exceed completions by four and three open cases are older than the fictional expectation.
Hypothesis: missing references might contribute to some delays, but this ledger cannot establish causation.
Proposed action: fictional operations lead reviews delay evidence for H004, H008 and H012; reporting colleague reviews missing-reference evidence for H004, H012 and H019.
Review point: next fictional weekly review. Closure evidence: documented reasons, agreed next steps, and a rerun with reconciled counts.
Stop or revise: an unresolved source, denominator, freshness or access problem prevents decision-ready presentation.
Status: draft specification with verified synthetic arithmetic, not implemented, deployed or approved for real operations.
Before real use: service owner confirms definitions and decisions; appropriate data, information-governance and technical owners review source access, disclosure, controls and deployment.

Optional Copilot help: Start with the decision

Use only supplied synthetic information and your fictional working notes. Optional drafting assistance does not replace independent review.

COPYABLE PROMPT
Using only the fictional Harbour facts supplied below, propose a one-sentence dashboard purpose and four balanced measure groups for an operations review. Separate facts from hypotheses. Do not invent causes, scheme standards, individual performance judgements or extra data. [Paste only the supplied fictional facts.]

OUTPUT REVIEW CHECKS
Does it answer a decision? Does it include open work and quality? Remove unsupported explanations or new requirements.

Optional Copilot help: Write the metric dictionary

Use only supplied synthetic information and your fictional working notes. Optional drafting assistance does not replace independent review.

COPYABLE PROMPT
Turn my draft metric notes into a clear dictionary using only the supplied synthetic definitions. Keep completed cases and open cases separate. Preserve inclusive date boundaries, calendar-day subtraction, distinct case counting and NA for an empty denominator. Flag any ambiguity instead of choosing a policy. [Paste only your fictional notes.]

OUTPUT REVIEW CHECKS
Check every population, date boundary and denominator against the source notes. Reject any added clock pause, legal deadline or guessed value.

Optional Copilot help: Calculate and reconcile the evidence

Use only supplied synthetic information and your fictional working notes. Optional drafting assistance does not replace independent review.

COPYABLE PROMPT
Independently calculate the defined metrics from this synthetic CSV for 1–28 September 2026. Show the case IDs included in each numerator and denominator, sorted durations, four weekly flow reconciliations and any data-quality exceptions. Blank completed_date means open; use fixed 2026-09-28 for open age. Do not repair source values or invent missing values. [Paste only the supplied CSV and metric definitions.]

OUTPUT REVIEW CHECKS
Recalculate the totals independently; compare the exact case sets, not just rounded percentages. AI agreement alone is not validation.

Optional Copilot help: Sketch a page that can be read correctly

Use only supplied synthetic information and your fictional working notes. Optional drafting assistance does not replace independent review.

COPYABLE PROMPT
Suggest a plain-language, one-page layout for this fictional dashboard, using only the checked values below. Include the reporting period, snapshot, denominators, fixed-source freshness label, open-case ageing and a prominent limitations note. Provide text descriptions for charts. Do not create a live connection, publish anything or add individual records. [Paste only checked synthetic results.]

OUTPUT REVIEW CHECKS
Check every value and label. Ensure chart descriptions match the values and colour is not the only signal. Remove any invented trend or cause.

Optional Copilot help: Test whether the dashboard deserves trust

Use only supplied synthetic information and your fictional working notes. Optional drafting assistance does not replace independent review.

COPYABLE PROMPT
Draft a test checklist for the fictional dashboard specification below. Organise it by confidentiality, integrity and availability. Include duplicate IDs, date boundaries, blank completion dates, zero denominators, filter consistency and failed-refresh visibility. State expected outcomes, and identify any decision needing a real owner’s approval. Do not claim tests have passed or suggest bypassing access controls. [Paste only your synthetic specification.]

OUTPUT REVIEW CHECKS
Distinguish proposed tests from executed evidence. Check that controls protect underlying data, not only the visible page, and that no organisation-specific policy was invented.

Optional Copilot help: Turn the dashboard into a management action

Use only supplied synthetic information and your fictional working notes. Optional drafting assistance does not replace independent review.

COPYABLE PROMPT
Help me edit this fictional dashboard handover into clear language for an operations review. Preserve all values, caveats, proposed owners and scope. Separate observed facts, hypotheses and decisions. Do not add deadlines, staffing commitments, legal requirements or approval claims. List any unresolved questions at the end. [Paste only your synthetic draft.]

OUTPUT REVIEW CHECKS
Compare it line by line with your draft and calculation sheet. Confirm nothing has been presented as approved, implemented, deployed or verified without evidence.

Copilot: account and safety check

Optional Copilot assistance: check your signed-in account, licence and employer’s approval. Microsoft supports some personal Premium use with work documents under administrator controls, but features vary. This course uses synthetic material only, regardless of licence. Never paste real member data or connect organisational sources for these exercises. Review outputs yourself.

Use only the supplied fictional material with a copyable prompt. Do not attach work files, authorise connectors, enable an agent to act, or ask it to send, publish or update records. If a feature is unavailable, work in a blank document or on paper. Check arithmetic, missing assumptions, invented rules and whether the proposal preserves confidentiality, integrity and availability. An AI draft is not operational approval.

This button opens the sections before printing. Check the print preview and choose which pages you need.

Review your dashboard pack, without a test

The dashboard supports a named decision for a named audience, with an explicit scope.
Every measure has a population, period or snapshot, calculation, exclusions, source and owner.
The four-week flow reconciles to eight open cases; weekly opening and closing balances also reconcile.
Completed-case turnaround is shown alongside open-case ageing, with denominators and limitations.
Rework is case-based and completeness is not presented as accuracy or overall scheme quality.
The sketch includes freshness, units, filter scope, accessible labels and a visible data-quality warning.
The control record covers confidentiality, integrity and availability, including a failed-refresh response.
Any AI assistance was limited to the supplied synthetic material, and its output was independently checked.
A decision, owner, review point and evidence requirement are recorded. No live access, publication or operational approval is implied.

You now have a draft dashboard specification, checked fictional results and a review/handover note. Completion is the working artifact, not a score, certificate or proof of regulatory compliance. Before any real implementation, the appropriate service, data and technical owners must review the scope, definitions, access and operating controls.

There is no saved completion tick for this workshop. Existing course answers and progress are unchanged.

Home