Finding the Job That Has Been Reopened Three Times

Imagine a facilities maintenance company handling this situation. The dashboard counts every completed visit as a success, although the same fault has required repeated attendance.

For a facilities maintenance company, this hypothetical scenario is worth considering because the mistake can look like an isolated oversight. Following the information usually reveals a repeatable weakness that better process design could address before anyone recommends new software. Understanding the distinction helps the business consider a proportionate change.

Return work is opened as unrelated jobs, so the reporting cannot distinguish new demand from unresolved earlier work.

A visit and an issue are different units of work. Linking them makes it possible to examine repeated effort without pretending every return visit represents a new customer problem.

The reason for a return visit should be reviewed rather than inferred from the address alone. A planned follow-up and an unresolved fault can require different interpretation. Linking the relevant issue history gives managers useful context without automatically classifying every second visit as a failure. The problem can persist without anyone making an obvious mistake. People follow the available information, but that information does not express the full business situation. Adding reminders would only make the same ambiguous record reach people more often.

Link relevant return visits to the original issue and record a reviewed reason. Show repeat attendance alongside completion counts without assuming every revisit is avoidable.

A useful report makes its limitations understandable alongside its numbers. Write down the decision the report is meant to support and the records included in its measure. Existing reporting features may be sufficient once the definitions are made consistent. Keep unavailable information distinct from a measured result so a reassuring display does not hide uncertainty. A dashboard should let an authorised reader trace a surprising figure back to relevant source information. Agree the time window, record level and important exclusions before choosing visualisations. Where information is combined, check how missing, repeated or late records affect the result.

Some repeat visits are planned or involve new faults, so categorisation needs operational judgement.

For background relevant to repeat repair issues, see Are You Measuring the Work or Just Counting It. The issue here is the narrower workflow described in this example.

Close a repair, reopen it twice and compare the issue history with the visit-level report. Follow one ordinary example and one awkward example through the proposed process. Involve the people at both ends of the handover and agree what they should observe. A demonstration of the happy path alone will not show whether a correction is understandable.

For repeat repair issues, review the proposed outcome with the staff responsible. Trace a surprising result back to its included records and definition. Check that the person reading the view can distinguish a genuine result from missing or incomplete information, and that the report supports the intended decision rather than merely displaying data. Before expanding the change, check whether staff can identify and correct an unsuitable result. A small reliable adjustment is more useful than a wider process that nobody can safely maintain.

Software Logic approaches business reporting by examining the actual handover, the information involved and whether a modest improvement would be sufficient. How much of your completed work is returning to a problem you thought was already resolved?