Picture your team at the end of a genuinely busy week. Everyone's slammed, nothing's on fire, a lot got done. Now sort that week's work into two piles.

In the first pile, put everything that actually served a resident or an owner: a unit leased, a real repair completed, a genuine question answered. In the second pile, put everything that only happened because something upstream didn't work: re-keying the same data into a second system, reconciling two numbers that should already match, chasing a status nobody could see, re-explaining context that didn't travel with the work.

For a lot of property operations, the second pile is bigger. And almost nobody is counting it, because it doesn't look like waste. It looks like work.

Two kinds of Demand, and Only One of Them Should Exist

There's a concept for this from a British management thinker named John Seddon, who spent years studying how service organizations actually behave. He split the work a service does into two kinds of demand.

Value demand is the work the service exists to do. A resident wants to lease a unit, report a real problem, get an answer. That's the job. That's what you want more of.

Failure demand is different. Seddon defined it as demand caused by a failure to do something, or to do something right, the first time. It's work that only exists because the system already failed somewhere. The customer calls back because the first call didn't fix it. The report gets rebuilt because the first one couldn't be trusted. None of it advances anything; it just cleans up after a gap.

You can read his definition of failure demand here.

Seddon's original focus was customer-facing, and the same logic runs straight through the back office. A huge amount of internal work exists for exactly one reason: the system didn't do something right, so a person has to. In some of the service organizations Seddon studied, failure demand reached as high as 80% of total demand. Most of what people were doing all day wasn't the job. It was the cost of the job being badly designed.

Where The Software Quietly Manufactures Work

Failure demand has many causes, but in property operations, disconnected software is one of the biggest. A lot of it comes down to the gaps between tools that don't talk to each other properly. Here's the work that exists only because of those gaps:

• Re-keying. The same lease, tenant, or invoice detail entered into a second system because the first one won't carry it across. Pure duplication, zero new information.
• Reconciling. Squaring two numbers that were always supposed to be the same. If operations and finance ran on one record, there'd be nothing to reconcile.
• Chasing status. "Did maintenance ever pick this up?" "Was the deposit returned?" Time spent finding out where something is, because nothing shows you.
• Rebuilding reports. Assembling the same portfolio view by hand every period because no existing report can be trusted to be current.
• Re-explaining context. Repeating the backstory to the next person or system because the detail that mattered didn't carry across with the task.
• Answering "which one is right?" The recurring meeting where two versions of the truth get adjudicated by a human.

Read that list back and notice what's missing from all of it: a resident. An owner. Not one of those tasks serves anybody. They exist to compensate for a system that didn't do its job, and your team does them anyway, quietly, all day.

Why It's Invisible

The reason failure demand is so hard to see is that it's indistinguishable from real work while you're doing it. It fills the calendar. It feels productive. People come home tired having done a lot of it. Everyone's genuinely busy.

But busy isn't the same as productive, and most operations don't measure the difference. They count activity, tasks done, hours worked, tickets closed, without ever asking how many of those tasks should have existed in the first place. So the failure demand hides in plain sight, disguised as a full day. The team isn't underperforming; it's working hard to keep a badly wired system upright.

The Trap: You Scale The Waste Along With The Work

Here's the part that turns this from an annoyance into a real limit on the business.

When failure demand is baked into how you operate, growth multiplies it. Add properties and you add more re-keying, more reconciling, more chasing, in direct proportion. So you hire to keep up, and what you're really hiring for is the work that shouldn't exist. You're funding the waste and calling it scaling.

This was Seddon's sharpest observation. When call centers filled up with demand, everyone read it as volume to be staffed. It wasn't. It was failure demand, and the right response was never to add more people to process it faster. It was to remove the thing generating it. Add capacity to absorb failure demand and you lock the waste in permanently, one hire at a time.

The Wrong Fix and The Right One

Faced with a team drowning in this work, the instinct is to make the work faster: better templates for the re-keying, a shared tracker for the chasing, a tighter reconciliation checklist. All of that optimizes the failure demand. It helps you do the unnecessary work more efficiently, which means you'll do it forever.

The actual fix is to remove the conditions that create the demand at all. The re-keying exists because two systems hold the same data. The reconciling exists because two systems disagree. The chasing exists because no system shows the whole picture. Those aren't productivity problems to be tuned; they're design problems, and the demand disappears entirely when the design changes, rather than getting processed a little quicker. Seddon's rule was blunt: don't manage failure demand, eliminate the system conditions causing it.

Value Demand Versus Failure Demand

Both fill the day. Only one of them is worth doing, and telling them apart is the first honest look most operations have ever taken at where their capacity actually goes.

How To Find Yours

You don't need a study. You need a week and a simple tag on every task: did this serve a resident or an owner, or did it only exist because something upstream failed?

• Watch for the words re-enter, reconcile, chase, rebuild, and double-check. Each one is usually failure demand wearing a verb.
• Count how often two people spend time agreeing on which number is correct. That entire category is failure demand.
• Ask your best person what eats their week. The answer is rarely the actual job. It's the work around the job.
• Notice what gets worse, not better, as you add properties. Whatever scales up fastest with volume is where the failure demand lives.

Whatever ratio you land on, it's almost always higher than anyone guessed, and that's the useful part. It means a large slice of your capacity is recoverable, not by working harder, but by removing work that never should have been there.

The Takeaway

Your team's problem probably isn't that it's too small or not trying hard enough. It's that a meaningful share of what it does every day is failure demand, work manufactured by disconnected systems and left for people to absorb. It's invisible because it looks exactly like the job, and it's expensive because you scale it right alongside the real work.

The move isn't to process that work faster. It's to stop generating it. When the underlying causes disappear, so does the work they created, and the demand doesn't get more efficient, it stops existing. That's the difference between a team that's busy and a team that's productive. Platforms like RIOO exist to remove those system conditions, though the first step costs nothing: spend one week sorting your work into the two piles and see how big the second one really is. What that redesigned operation looks like is covered in the companion pieces on running a property operation as one connected system and optimizing property management operations.

FAQ

1. What is failure demand?
Failure demand is a term from management thinker John Seddon: demand caused by a failure to do something, or do it right, the first time. It's work that only exists because the system failed somewhere upstream, like a customer calling back because the first contact didn't resolve their issue. It's distinct from value demand, which is the work the service exists to provide.

2. How does software create failure demand in property management?
Failure demand has many sources, and disconnected systems are one of the largest. Re-keying data into a second system, reconciling numbers that should already match, chasing status no system shows, and rebuilding reports by hand are all work that exists only because the tools don't share one record. None of it serves a resident or an owner; it compensates for the system.

3. Why is failure demand so hard to notice?
Because it looks identical to real work while you're doing it. It fills the day and feels productive, and most operations measure activity rather than whether that activity should have existed. So the waste hides as a full, busy schedule, and the team appears to be working hard rather than working around a poorly designed system.

4. Won't better tools and templates fix it?
Those usually make the failure demand faster, not smaller, which means you keep doing the unnecessary work indefinitely. The durable fix is to remove the conditions that create the demand, for instance putting operations and finance on one record so there's nothing to reconcile, rather than reconciling more efficiently.

5. How do I measure failure demand in my operation?
For one week, tag each task by whether it served a resident or owner or only existed because something upstream failed. Watch for work described as re-entering, reconciling, chasing, or double-checking, and note what grows fastest as you add properties. The resulting ratio shows how much of your capacity is recoverable by redesign rather than effort.