Pet Fee & Policy Benchmark

PropertyOps PostPropertyOps Post

Cross-sector
Operator-first

OperationsSector Playbook

Closed Isn’t Fixed: How to Audit Repeat Maintenance Calls

A closed ticket does not prove a lasting repair. Auditing repeat requests helps operators distinguish unresolved problems, recurring failures, and planned follow-ups.

So what: Link related requests, verify why the problem returned, and assign corrective action. Count original problem episodes, not every callback ticket.

Two maintenance men looking at a kitchen sink.
AI-generated illustration.

The disposal is marked repaired. Four days later, the resident submits another request: it still stops working.

The second ticket may go to a different technician. Its description may say “kitchen sink” rather than “disposal.” Both requests can appear as completed jobs without the reporting identifying one unresolved problem.

A repeat-call audit connects those records. It asks what happened after the team represented the repair as complete, why the resident reported the condition again, and whether the response addressed the problem.

That is a different question from how quickly technicians close work orders. It also requires more care than counting every second visit as a failed repair.

The framework below is a proposed internal operating approach, not an industry standard or a validated multifamily benchmark.

Follow the condition across tickets

Work-order IDs identify records. They do not necessarily identify distinct problems.

A resident might report one issue through the portal, a phone call, and the office. A technician might create a separate order for specialist work. A repair might require a diagnostic visit followed by installation of an ordered part.

Those situations should not receive the same classification.

IBM defines first-time fix rate as the percentage of field-service jobs completed on the first visit without requiring follow-up visits, supplementary parts, or external support. Its explanation identifies documentation, communication, parts availability, and skill gaps among the factors that can affect return visits.ibm

For a property maintenance audit, distinguish that first-visit measure from what happens after recorded resolution. A repair requiring two planned visits may not generate a repeat problem. A repair completed in one visit may later recur.

Track both if they matter to the operation. Do not combine them into one number and call it repair quality.

Build a review queue, not a failure list

Identify requests that may be related using the property, apartment, equipment or location, reported symptom, and timing.

Where possible, include an equipment identifier. Two requests in the same apartment may concern different problems, while similar failures across several apartments may warrant a broader equipment review.

For an initial pilot, an operator could screen for new reports received within 30 days of a previous recorded resolution. That is a proposed starting window, not an industry standard.

The matches are candidates for review. Before classifying them, examine:

  • The resident’s original description.
  • The technician’s observations and diagnosis.
  • The work performed and parts installed.
  • How the result was checked.
  • Whether another visit was already planned.
  • What the resident reported afterward.

If the system cannot reliably link related requests, a periodic export can support manual review. The important step is confirming the relationship, not assuming that proximity in time proves it.

Separate recurrence from unfinished work

Use classifications that explain why the maintenance process continued:

  • Duplicate contact: another record of the same contact or open request, without evidence of a new post-resolution problem.
  • Planned follow-up: another visit was documented as necessary, and the problem remained open.
  • Access or scheduling problem: the work could not proceed because entry or an appointment was unavailable.
  • Unresolved original condition: the reported problem persisted after the team recorded it as resolved.
  • Repair recurrence: the condition appeared resolved, then returned.
  • Separate problem: the later request concerns a different condition.
  • Unclear: the records do not establish what happened.

The unclear category matters. Incomplete notes should not become a confident explanation simply because the report requires one.

A classification is also not a technical diagnosis. A confirmed repeat establishes that the condition persisted or returned. It does not establish whether the cause was workmanship, a defective part, aging equipment, or an incomplete diagnosis.

If unfinished work was prematurely marked resolved, retain that closure in the audit. Do not relabel it as a planned follow-up after the fact merely to improve the result.

Investigate the cause, not just the last visit

Fiix describes root cause analysis as identifying the systemic cause of a failure rather than addressing only its symptoms. Its guidance on the five whys method recommends checking explanations against visible or measurable evidence and considering other plausible causes.fiixsoftware+1

For a maintenance team, that means looking beyond the last employee who touched the equipment.

Did dispatch provide the service history? Were the appropriate parts available? Was the diagnosis tested? Did a temporary restoration become a completed repair in the record? Did a replacement recommendation reach someone with approval authority?

Consider a hypothetical cooling complaint. A technician restores operation, but the same symptom returns several days later. The audit should establish what was tested, what changed, and whether the intervention addressed the underlying condition. It should not automatically label the case a technician error.

Technical diagnosis belongs with qualified personnel. The audit preserves the evidence, routes the case, and ensures that an accountable decision follows.

Make closure notes describe the result

“Fixed” gives the next technician little to work with.

For a repair, record the reported symptom, observed condition, work performed, parts used, and test or observation used to check the result. Identify anything unresolved and the next action required.

The detail should match the job. An intermittent leak or repeated equipment shutdown needs a different record from a minor hardware adjustment.

Separate the visit outcome from the problem’s resolution status where the system permits. A technician can finish a visit while the repair remains open.

“Temporary restoration; replacement part ordered; follow-up assigned” tells the next employee something materially different from “complete.” When another visit is required, document it rather than recording resolution simply to close the assignment.

Ask about the same condition

For selected jobs, particularly confirmed repeats, resident follow-up can help establish whether the condition remains.

Ask a specific question: “Has the kitchen drain backed up again since the repair?”

Keep the answer connected to the service history. If the resident reports that the problem continues, link the follow-up and route it for review rather than allowing it to become another isolated ticket.

Resident feedback is one source of evidence, not a substitute for technical verification. No response does not establish that the repair worked. An intermittent problem may also return after the resident initially believes it is resolved.

Urgent or potentially unsafe conditions belong in the property’s immediate-response process. They should not wait for an audit meeting.

Count original problems, not callback tickets

For internal reporting, calculate a confirmed repeat-problem percentage:

PW=RWNW×100P_W=\frac{R_W}{N_W}\times100PW​=NW​RW​​×100

The variables are:

  • PWP_WPW​: The confirmed repeat-problem percentage within the selected observation window.
  • RWR_WRW​: Eligible problem episodes with at least one confirmed related repeat reported within that window.
  • NWN_WNW​: All eligible problem episodes in the same cohort that were recorded as resolved and have a complete observation window.
  • WWW: The fixed window after recorded resolution, such as 30 days.

A problem episode consists of the original condition and its linked contacts, tickets, and visits. Count it once in the denominator and, if it qualifies, once in the numerator. Track additional callback visits separately as workload.

Select the reporting cohort by first recorded-resolution date. For example, a September cohort contains episodes first recorded as resolved during September. Each receives its own complete follow-up window, even when that window extends into October.

Do not divide October repeat reports by October closures. Those counts may represent different groups of problems.

Keep the counting rules consistent

Start the window when the team first represents the problem as resolved, not when a visit ends with work explicitly outstanding. Do not restart it when a callback ticket closes.

Use the repeat’s report date to determine whether it falls within the window. A report received on day 29 qualifies even if the technician returns on day 32.

Include both unresolved original conditions and repair recurrences. Exclude unrelated new problems, duplicate records, and planned follow-ups that were never represented as final resolution.

Every denominator episode needs the full observation window and usable reporting coverage throughout it. Flag missing records rather than interpreting their absence as evidence of success.

Specify whether the window uses calendar days or exact timestamps. A same-day report can qualify if review establishes that it occurred after recorded resolution and was not a duplicate contact.

As with any proportion, the numerator must be a subset of the denominator. A fixed-window percentage also needs a consistent population and observation period. These are general measurement principles, not property-maintenance benchmarks.archive.cdc+1

Show what the number cannot establish

Suppose 100 eligible episodes have complete 30-day observation windows. Eight have a confirmed related repeat.

The confirmed repeat-problem percentage is 8%, even if those eight episodes generated 12 callback visits. The visits belong in a separate workload count.

If three more episodes cannot be classified, retain those eligible episodes in the denominator and disclose the three unclear cases beside the result. If candidate cases remain unreviewed, label the result preliminary.

Do not describe the remaining 92 episodes as verified successful repairs. The measure establishes that no related repeat was confirmed in those cases, not that every repair was independently checked.

Likewise, a lower percentage is not sufficient evidence of improvement if reporting coverage, linking practices, or classification rules changed. Keep those rules stable and review the cases behind the number.

Assign an action to the finding

A repeat-call review is unfinished until its findings produce a decision.

For each material pattern, record the supporting evidence, corrective action, responsible employee or vendor, completion date, and method for checking the result.

The response might involve parts stocking, access to service history, technician training, a clarified vendor scope, or an equipment-replacement decision.

Account for the work people receive before comparing technicians or vendors. Someone handling difficult equipment should not be judged against someone completing mostly routine repairs without that context.

Use the review to identify where the process needs attention, not to reward employees for avoiding repeat classifications.

Follow the repair beyond closure

A closed ticket records an administrative decision. A resolved problem needs evidence.

Linking related requests helps the team explain why the resident called again, what the earlier work accomplished, and what needs to change.

The audit’s value is not a cleaner completion report. It is a service history the next technician can use and a corrective action someone owns.

More in Operations

See all