Closing a record and restoring a function

A “closed” status can mean a repair, referral to another service or merger with an earlier report. Those are different outcomes for a resident. A ticket needs a reason for closure and information about completed work to explain what changed on site.

Imagine a broken streetlight

Imagine a fictional courtyard. A resident reports a dark passage, a crew replaces a bulb and closes the request with a daytime inspection photo. That evening it still does not light because the fault is in the supply line. Work occurred, but the function was not restored. A second report is mistakenly treated as an unrelated new fault.

Completion for this task should involve checking lighting under relevant operating conditions. A photograph may confirm a visit or component replacement, but does not alone prove the whole circuit works. Choose evidence according to the problem, rather than the convenience of filling in a record.

Statuses should explain waiting

Between receipt and resolution lie meaningful stages: clarifying location, checking object ownership, assigning an executor, awaiting materials, doing the work and verifying it. Residents need not see all internal complexity, but the interface should explain what is done and what the next step depends on.

Management needs transition dates and delay reasons. Otherwise, slow execution cannot be distinguished from waiting for assignment. Preserve transition history so a new shift can continue without a telephone retelling or restarting the investigation.

Repeated reports retain useful signals

Merging duplicates avoids dispatching several crews to one object. Yet each report may add important details: a different fault time, a new photo or recurrence after repair. Automatically deleting such records removes the chance to notice an unresolved problem.

Link reports to shared work and explain how each reporter receives the outcome. A repeat after claimed resolution should prompt a quality check. It does not prove crew error; there may be a new cause. History helps distinguish explanations and choose the next inspection.

Measures should not reward disappearing records

Closed-request counts are convenient but reveal little about the condition of a city. Add time to a verified result, repeat reports at the same object and closure reasons. Measures should expose weak stages rather than turn difficult cases into obstacles to a positive report.

In the example, rapid first closure would look successful while the passage remained dark. Review a small sample of completed jobs and their evidence. This manual work reveals the meaning that average processing time conceals.

Agree criteria for one problem type

Start with a recurring category such as lighting. Define required initial information, object responsibility, what counts as completed work and how function is verified. Provide a clear return route when residents say the problem remains.

Sources