Property management, built natively on Oracle NetSuite

Request a demo

Platform

Six connected areas on one NetSuite system of record.

Solutions

Start from the places you manage, the business you run, your role or the workflow you want to fix.

NetSuite

Property management built natively on NetSuite, not synced to it.

Integrations

External tools exchange data with RIOO. Core property and financial records stay in NetSuite.

Markets

Localised pages for the five markets RIOO serves, with the rules that change how property is run.

Resources

Answers for choosing, implementing and running property management on NetSuite.

Company

The team behind the NetSuite-native property platform.

General Business

Post Incident Review in Property Management: Fix the System

Why blame makes incidents repeat, and how property leaders run post incident reviews that find the real conditions and stop the next one.

LinkedIn X
RIOO cover for Post incident review in property management, with abstract shapes on plum: a timeline bar and a magnifying lens over connected nodes

Short answer: a post incident review in property management is a structured look back after something goes wrong. Think of a flood, a missed inspection or a resident safety issue. Its purpose is to find the conditions that let the incident happen and change them. Good reviews build a factual timeline and ask what made the right action hard at the time. They end with a few actions, each with an owner, a date and a check that the fix worked. Reviews that hunt for someone to blame tend to produce a warning letter and a repeat of the same incident.

Many operators know the second flood from the same riser. Or the inspection that was missed twice in three years at the same building. Or the vendor who was sent to the wrong unit again. When an incident repeats, look first at how the work is set up. A gap in the process is still there after the person involved has been spoken to.

This piece is for leaders who want each incident to make the next one less likely.

Why blame makes the next incident more likely

Blame feels like accountability. In practice it changes behaviour in three costly ways.

First, people stop reporting near misses. A technician who sees a colleague disciplined after a leak learns to fix small problems quietly. The organisation loses its early warning.

Second, the record gets thinner. When a review might end in a warning, people write less and remember selectively. The timeline that would show the real cause never gets built.

Third, the fix targets the person. A warning letter does nothing about the alarm that rang on a phone nobody carried, or the checklist that skipped a step. The next person in the role meets the same trap.

None of this means poor performance goes unaddressed. It means performance issues are handled in a separate process, and the review stays focused on the system. We have written before about how the shortcut that works becomes the standard. Incidents are often where that drift finally shows.

When to hold a review

Not every broken tap needs one. Set clear triggers so the decision is not made case by case:

  • Injury to a resident, tenant, employee or contractor.
  • Damage that displaces residents or closes a commercial space.
  • A missed legal or compliance deadline.
  • A data or security breach.
  • Any incident that repeats at the same property or with the same vendor.
  • A near miss serious enough that luck was the main control.

Hold the review once the immediate response is over. The first two days belong to people, safety and the building, as set out in our guide to the immediate response after a major incident. The review comes after, while memories are still fresh.

How to run one

Post incident review loop in four stages: build the timeline from records, find the conditions that allowed the incident, agree actions with an owner, date and check, then verify the fix and share the lesson across the portfolio

Build the timeline first

Start with records. Use work order times, call logs, messages, alarm logs, access logs and photos. Then add what people remember, marked as recollection. Keep the two separate. The timeline should show what each person knew at each point, not what everyone knows now.

Find the conditions

Ask what made the right action hard at the time. Common areas to look at are procedures, staffing, tools, training, communication and the handoffs between teams. Handoffs deserve extra attention. Information often stops at the line between the leasing office and maintenance, or between the site and the vendor.

Agree a few actions

A long action list tends to stall. Pick the changes that would have stopped this incident or caught it sooner. Give each one an owner, a due date and a way to check it worked. A vague action such as "retrain staff" cannot be checked. A good action reads like this: "Add the riser valve check to the monthly inspection form and confirm it appears in the next three completed inspections."

Verify and share

Close the review only when each action is done and checked. Then share a short summary across the portfolio. A riser failure at one building is a warning for every building of the same age.

Keep other processes separate

Insurance claims, legal matters and personnel decisions have their own rules and their own advisers. Run them in parallel, not inside the review. Ask counsel how the review record should be handled where a claim is likely.

Questions that work

The wording of the questions sets the tone of the room. These open the conversation:

  • What did you know at that moment, and where did it come from?
  • What were you expecting to happen next?
  • What made the right step hard, slow or unclear?
  • Where did information stop moving?
  • What would have caught this earlier?
  • Has anything like this happened before, here or elsewhere?

Questions that start with "why didn't you" close it, because they put people on the defensive.

Write it up on one page

A review that nobody reads changes nothing. Keep the written summary to one page so it travels across the portfolio. A simple template works:

  • What happened: two or three sentences, in plain words.
  • Impact: who was affected, for how long, and the cost where known.
  • Timeline: the key moments, with times.
  • Conditions found: what made the incident possible or worse.
  • What went well: the parts of the response worth keeping.
  • Actions: each with an owner, a date and a check.

Leave names out of the conditions section. Describe roles and steps instead. That keeps the focus on the work and makes the summary safe to share widely.

What leaders have to do differently

A blameless review only works if senior people behave as if they mean it. That asks for a few specific habits.

  • Turn up. Attend some reviews in person, listen more than you speak, and thank people for detail that reflects badly on the process.
  • Fund the fixes. If the action is a new alarm route or extra cover on weekends, approve it or say plainly why not.
  • Track closure. Review open actions in the same meeting where you review occupancy and arrears.
  • Measure repeats. Count incidents that recur. Fewer repeats is the result that matters, and the number of reviews held tells you little.
  • Watch for single points of failure. Reviews often reveal one person or one contractor the operation cannot run without. Our piece on vendor concentration risk covers the contractor side, and our piece on tribal knowledge covers the staff side.

A worked example

This is an illustrative case. A boiler at a 90 unit building fails on a Saturday night. Residents are without heat until Sunday afternoon.

The blame version: the on call technician did not respond to the alarm. He receives a written warning. The review closes.

The system version: the timeline shows the boiler alarm was sent to a phone number changed two months earlier. The on call rota lived in a spreadsheet that only the maintenance supervisor updated. Nobody tested the alarm route after the change. The technician never received the alert.

The actions that follow are different:

  • Alarm routes point to a shared on call number rather than a personal one. Owner: maintenance supervisor.
  • Any change to the rota triggers a test alert, logged on the asset. Owner: property manager.
  • The same check runs across every building with remote alarms. Owner: regional manager.

Six months later, the check finds the same problem at a second building before it causes a failure. That catch is the return on the review.

Signs your review culture is working

  • Near misses are reported more often, not less.
  • Timelines are detailed, and people volunteer their own mistakes.
  • Actions close on time and stay closed.
  • Lessons from one property change practice at others.
  • The same incident does not come back.

Where RIOO fits

A good review needs a clean record, and that record is easier to build when the response lives in one place. In the RIOO community manager portal, an emergency is raised as a work order and assigned to a vendor. Managers alert residents with a community or building message, track vendor status, and record costs and evidence such as photos, invoices and timings. The final step is to close and review, noting causes and any follow up work. Workflow actions record who acted and when, which gives the review its timeline.

Frequently asked questions

What is a blameless post incident review?

A review that looks for the conditions behind an incident rather than a person to punish. Individual performance issues are handled separately.

Who should attend a post incident review?

The people involved in the response, their supervisor, a facilitator who was not involved, and a senior leader for significant incidents. Keep the group small.

How soon after an incident should the review happen?

After the immediate response is complete, and while memories are fresh. Set a target in your incident policy, such as within ten working days, and keep to it.

Does blameless mean nobody is accountable?

No. Leaders stay accountable for fixing the system, and action owners are accountable for their actions. Misconduct is still handled through the normal personnel process.

How do we stop the same incident happening again?

Fix the conditions, check that each fix worked, and apply the lesson across similar properties. Then track repeat incidents as a leadership measure.