There is a hope that attaches itself to automation in almost every property company: that the messy, manual, error-prone process everyone complains about will be fixed by automating it. The reasoning feels obvious. The process is painful because people do it by hand, so if software does it instead, the pain goes away. The purchase gets approved on that logic, the workflow gets automated, and then, often, things get worse rather than better, and faster than they did before.

The reason is that automation does not fix a process. It executes one, at speed and at scale, exactly as it was given. If the process was good, automation makes it faster and more reliable, which is a real and large benefit. If the process was broken, automation makes the breakage faster and more reliable too, propagating the same errors more widely, more quickly, and with less friction to catch them. Automation is a multiplier, and a multiplier applied to a negative number does not produce a positive one. It produces a bigger negative.

The rule is old, and it comes from someone who believed in automation

This is not a warning from an automation skeptic. The clearest statement of it comes from Bill Gates, who built one of the largest technology companies in history.

In The Road Ahead, Gates set out what he called the first two rules of applying technology in business: automation applied to an efficient operation will magnify the efficiency, and automation applied to an inefficient operation will magnify the inefficiency. The second rule is the one that gets forgotten, because it is the uncomfortable one. Automation is not a corrective force. It is an amplifier, and it amplifies whatever it is pointed at, the good process and the bad one alike, with complete indifference to which it is working on.

That framing matters because it comes from someone whose life's work was automation. The point is not that automation is bad or that you should avoid it. It is that automation is a multiplier rather than a repair, and the outcome depends entirely on the quality of what you multiply. Pointing it at an efficient property operation is one of the highest-return things you can do. Pointing it at a broken one scales the dysfunction, and calls it progress because it is now faster.

Why automating a broken process is worse than leaving it manual

It would be easy to assume that automating a bad process is at worst neutral, that you end up with the same bad process, just quicker. But it is usually worse than that, for reasons specific to how automation changes a process.

• It removes the friction that was catching errors: A slow manual process has human friction in it, and that friction, annoying as it is, is often the only thing catching mistakes. A person notices that a charge looks wrong, that a lease term does not match, that a number is off, and pauses. Automating the process removes that pause. The error that a human would have caught now flows straight through, because the checkpoint was the very slowness you automated away. The friction was sometimes the only thing keeping the bad process honest.

• It scales the error rate: A manual process handles a limited volume, which caps how much damage a flaw can do. Automation removes that cap. A process that mishandled one case in twenty when a person did it slowly now mishandles one case in twenty at machine speed across the whole portfolio, so the same error rate produces far more errors, and they accumulate before anyone notices the pattern.

• It embeds the dysfunction and makes it harder to fix: A bad manual process is at least visible and changeable, someone can decide tomorrow to do it differently. Once it is automated, it is encoded in a system, wired into other systems, and depended on by workflows built on top of it. What was a process problem you could fix by changing how people work has become a systems problem you can only fix by re-engineering software, which is slower, costlier, and riskier. Automation does not just preserve the bad process. It sets it in concrete. This is the same hardening effect that makes an under-examined operating model so expensive later, examined in you can't outsource operational maturity.

• It buries the reasoning: Many broken processes are not designed but inherited, a workaround that became standard, a one-time exception that became a rule, its original logic long forgotten. Automating such a process preserves its shape while burying its reasoning even deeper, so that later, when someone asks why it works this way, the answer is "the system does it" and nobody can explain further. The dysfunction becomes not just faster but unquestionable.

• The evidence bears this out. In its report on why robotics projects succeed or fail, EY found that as many as 30 to 50% of initial robotic process automation projects fail, and was explicit that this is not a reflection of the technology but of common mistakes in how projects are planned and run. The report even has a section called "the multiplier effect," describing how problems compound once automation is layered onto them, which is precisely the dynamic this piece is about.

What this looks like in a property operation

The pattern is concrete in property management, where the manual processes are exactly the kind people rush to automate.

A messy month-end close, full of manual reconciliations and workarounds, gets automated, and now it produces wrong numbers faster, with the manual checks that used to catch them removed. A broken maintenance-dispatch process, where work orders are already routed by unclear rules, gets automated, and now the wrong vendor gets dispatched automatically, at scale, without the coordinator who used to quietly fix the routing. A rent-escalation process with inconsistent logic gets automated, and now the inconsistency is applied uniformly to every lease, turning scattered errors into a systematic one that surfaces in an audit. In each case the automation worked perfectly. It did exactly what it was told, which was the problem, because what it was told was a process nobody had fixed first.

This is also why the spreadsheets and workarounds a team has built up are worth reading before automating anything, they are a map of where the real process actually lives, a point developed in the spreadsheet that runs your company. Automating the official process while ignoring the workaround that actually makes it function is a reliable way to scale a version of the process that was never the real one.

The honest part

Several qualifications keep this from becoming an argument against automation, which would be the wrong lesson entirely.

Automation is genuinely transformative when applied to a sound process, and the point is emphatically not to avoid it. A good process, automated, is faster, more consistent, more scalable, and less error-prone than any manual version, and for a growing property operation that leverage is exactly how you handle more without proportionally more staff. The argument is about sequence, not about whether to automate. Fix first, then automate, and the automation pays off enormously.

It is also true that you do not need a perfect process before automating, and waiting for perfection is its own failure. The bar is not flawless; it is understood and sound. A process that is well-defined, whose logic people can explain, and whose exceptions are known can be automated even if it is not perfect, and the automation will often surface remaining improvements. What you cannot safely automate is a process nobody understands or one that is actively broken, because automation will preserve exactly what you did not examine.

And sometimes automating a process is itself the thing that forces you to fix it, because you cannot automate what you cannot define, and the act of specifying it for a machine exposes the gaps. Used deliberately, an automation project can be the occasion to redesign the process, and that is a legitimate and powerful approach. The failure is not automating alongside improvement. It is automating instead of it, encoding the mess because defining the fix felt like the harder job.

Fix the process, then multiply it

The practical discipline follows directly from the rule: because automation multiplies what it is given, the work is to make sure what you give it is worth multiplying.

Before automating any process, map it as it actually runs, not as it is supposed to, and look for the parts that exist only as workarounds, the steps nobody can justify, the exceptions that reveal the rule is wrong. Ask, of the process as a whole, whether you would design it this way from scratch today. Where the answer is no, fix that before you automate, because automating it will only make the wrong design permanent and fast. Run the improved process manually for long enough to confirm it is actually sound, then automate the version that works, so the multiplier lands on efficiency rather than dysfunction.

There is a single question that tells you whether you are about to automate a solution or scale a problem. If this process ran perfectly, at speed, across my entire portfolio, exactly as it is designed today, would that be a good outcome or a faster disaster? If the honest answer is that running it flawlessly at scale would expose or multiply its flaws, then the process is not ready to automate, and automating it will amplify exactly what you have not fixed. Automation is one of the most powerful tools a property operation has. It is just a multiplier, and the first job is always to make sure the thing being multiplied is one you want more of.

FAQs

Q1. Doesn't automating a manual process make it better?
Only if the process was good to begin with. Automation executes a process at speed and scale exactly as given; it does not improve the logic. A sound process automated becomes faster and more reliable, a genuine benefit. A broken process automated becomes faster and more reliably broken, propagating its errors more widely and quickly. Automation is a multiplier of whatever it is applied to, not a corrective force, so the quality of the underlying process decides the outcome.

Q2. What did Bill Gates actually say about this?
In The Road Ahead, he framed two rules: automation applied to an efficient operation magnifies the efficiency, and automation applied to an inefficient operation magnifies the inefficiency. The second rule is the one people forget. Coming from someone who built a major technology company, it is not an anti-automation stance but a precise description of automation as an amplifier, one that magnifies whatever process it is pointed at, good or bad, without discrimination.

Q3. Why is automating a bad process worse than leaving it manual?
For four reasons. It removes the human friction that was quietly catching errors, so mistakes now flow straight through. It scales the error rate, since automation lifts the volume cap that limited how much damage a flaw could do. It embeds the dysfunction in software and dependent systems, turning a fixable process problem into a costly systems problem. And it buries the reasoning, so the bad process becomes not just faster but unquestionable.

Q4. How common is this failure?
Common enough to be well-documented. In its report on robotics projects, EY found that as many as 30 to 50% of initial robotic process automation projects fail, and stated plainly that this reflects not the technology but common mistakes in planning and execution. The same report describes a "multiplier effect" in which problems compound once automation is layered on top of them, which is exactly the dynamic behind automating a process that was not sound to begin with.

Q5. What does this look like in property management specifically?
A messy month-end close automated to produce wrong numbers faster, without the manual checks that caught them. A maintenance-dispatch process with unclear routing automated to dispatch the wrong vendor at scale. A rent-escalation process with inconsistent logic automated to apply that inconsistency uniformly, turning scattered errors into a systematic one an audit will find. In each case the automation worked exactly as instructed, which is the problem when the instruction is a process nobody fixed first.

Q6. Do we need a perfect process before automating?
No, and waiting for perfection is its own mistake. The bar is not flawless but understood and sound: a process that is well-defined, whose logic people can explain, and whose exceptions are known can be automated even if it is not perfect, and automation will often surface further improvements. What you cannot safely automate is a process nobody understands or one that is actively broken, because automation preserves precisely what you did not examine.

Q7. Isn't automation itself a way to force process improvement?
It can be, when used deliberately, because you cannot automate what you cannot define, and specifying a process for a machine exposes its gaps. An automation project run as an occasion to redesign the process is a legitimate and powerful approach. The failure is automating instead of improving, encoding the existing mess because defining the fix felt harder. Automating alongside deliberate redesign is good practice; automating in place of it scales the dysfunction.

Q8. What single question should we ask before automating a process?
Ask whether the process running perfectly, at speed, across your entire portfolio, exactly as designed today, would be a good outcome or a faster disaster. If running it flawlessly at scale would expose or multiply its flaws, it is not ready to automate, and automating it will amplify what you have not fixed. If running it flawlessly at scale would be genuinely good, the process is sound and automation will pay off. That question separates solutions worth scaling from problems about to be scaled.