Daniel sent us this one — he's asking about the other end of the elevator universe. We once talked about those old, slightly sketchy-looking elevators in Jerusalem that somehow keep chugging along decade after decade. Today he wants to look at the opposite pole: the blisteringly fast, algorithm-driven machines in modern skyscrapers. How do you maintain something that rockets up a building at forty-six miles an hour? What technologies even make that possible? And how do the dispatch algorithms figure out who goes where, especially when you're retrofitting a building from the nineteen seventies?
This is one of those topics where the surface-level answer — "bigger motors, stronger cables" — misses almost everything interesting. The real story is that the elevator is becoming a vertical transit system. It's less like a box on a rope and more like a subway that happens to go up.
Which is a sentence that would have gotten you laughed out of an engineering conference thirty years ago.
But here we are. Cities are building taller and denser, and the elevator is the bottleneck. You can design the most brilliant hundred-story tower in the world, but if people are waiting ninety seconds for a car, the building doesn't work. Vertical transportation is the circulatory system of a skyscraper, and we're in the middle of a genuine revolution in how it's engineered.
We've got two poles. On one end, the Jerusalem elevator — the one where the doors close with a sound that suggests they've made peace with their own mortality. On the other end, you've got machines that travel at twenty meters per second in a pressurized shaft, with no cables at all in some cases, deciding where you're going before you even press a button. The gap between those two things is the space we're going to explore.
What makes this worth a full episode is that the three pieces of the puzzle — the physical engineering of speed, the maintenance revolution keeping these things reliable, and the algorithms managing passenger flow — they all had to advance together. You can't just bolt a faster motor onto an old design and call it a day. Each one of those pillars had to be reinvented.
Alright, so let's trace that. Where do we start — with the thing that actually moves?
Let's start with what "fast" even means in elevator terms, because the numbers are genuinely startling. A standard elevator in a mid-rise building might travel at one and a half to two and a half meters per second. The Burj Khalifa's elevators hit ten meters per second — about twenty-two miles an hour. And the Shanghai Tower, which currently holds the record, reaches twenty point five meters per second. That's forty-six miles an hour.
Forty-six miles an hour straight up. In a box.
In a box. And the ride takes under a minute to go over five hundred meters. What's wild is that the air pressure management has to be so precise that your ears don't pop. Mitsubishi designed a proprietary aerodynamic car shape and an active pressure control system for the shaft. It's not just about going fast — it's about making fast feel like nothing.
Which brings up the obvious question. If speed was just about putting in a bigger motor, we'd have done it decades ago. What actually stops you from doing that?
Three things, mostly. First, the rope problem. Steel cables are incredibly strong, but they're also heavy. For a building over about five hundred meters, the weight of the cable itself becomes the limiting factor — the cable has to support not just the car and the counterweight, but its own mass. Beyond that height, you need something else. Otis solved part of this with their Gen2 system, which uses flat, Kevlar-reinforced belts instead of steel ropes. Much lighter, much stronger for the same cross-section.
You're telling me the same material that stops bullets is holding up elevators.
And it's coated in a polyurethane jacket that the traction sheave can grip far more effectively than steel on steel. But even Kevlar belts have a limit. For the truly ultra-tall buildings, the real answer is to eliminate the rope entirely.
Which is where the maglev stuff comes in.
And that's the second thing that stops you — the whole paradigm of one car per shaft, pulled by a cable, is inherently limited. Even if you solve the weight problem, you've still got one car per shaft. Want more capacity? You need more shafts, which eat up floor space. In a super-tall building, elevator shafts can consume up to forty percent of the core footprint. That's rentable space you're losing.
The shaft itself becomes the bottleneck, not just the speed of the car inside it.
And the third thing is safety. A car moving at twenty meters per second has enormous kinetic energy. High-speed elevators have multiple independent braking systems — the service brake, the emergency brake, overspeed governors that trigger if the car exceeds a certain velocity, and buffer springs or hydraulic buffers at the bottom of the shaft designed to absorb the impact if everything else fails. The safety engineering scales with the speed.
The faster you go, the more redundancy you need. It's not just a faster motor — it's a completely different machine.
That's the thread we're going to follow. The physical design had to be reinvented. The maintenance model had to shift from reactive to predictive, because you can't afford unplanned downtime on a machine that moves thousands of people a day. And the dispatch logic had to become intelligent — not just "send the nearest car," but an optimization algorithm that solves something close to a real-time traveling salesman problem for every passenger who steps into the lobby.
Three angles: the hardware that makes speed possible and what comes after cables, the maintenance intelligence that keeps it all from breaking, and the algorithms that decide who goes where. Let's dig into the first one — what's actually happening inside a shaft when a car is moving at forty-six miles an hour?
Alright, so the physics of high-speed elevator travel starts with the counterweight. In a standard elevator, the counterweight balances the car plus about forty to fifty percent of its rated load. That means the motor isn't lifting the full weight of a loaded car — it's overcoming the difference. But at high speeds, the counterweight also stabilizes the system dynamically. When the car accelerates upward, the counterweight drops, and the traction sheave has to maintain grip on the cables or belts without slipping. That's a non-trivial engineering problem at twenty meters per second.
Because if the sheave slips even slightly, you're not just losing efficiency — you're introducing a control problem.
And the forces involved are enormous. A high-speed elevator motor might be rated at three hundred to five hundred kilowatts. But here's where it gets clever: when the car is going down with a full load, or up empty, the motor actually acts as a generator. It's called regenerative braking, and it feeds electricity back into the building's grid. In some installations, the elevator system can recover up to thirty percent of the energy it uses.
The elevator is a net energy producer on the down cycle.
In a sense, yes. It's recovering the potential energy that was stored when the car was lifted. Over the course of a day, the regenerative system meaningfully reduces the building's total energy draw.
Then there's the air problem. A car moving at that speed in a narrow shaft is essentially a piston.
This is one of those things that seems obvious once you think about it but most people never do. An elevator shaft is a long, narrow tube. When a car moves through it at high speed, it compresses the air in front of it and creates a partial vacuum behind it. That air resistance creates pressure differentials that can make doors difficult to open, cause whistling noises, and make passengers' ears pop uncomfortably.
You have to manage the aerodynamics of the car itself.
The Shanghai Tower's elevators use a car with an aerodynamic shroud — shaped to reduce air resistance, almost like the fairing on a high-speed train. The shaft is also equipped with pressure relief vents at intervals, allowing air to bypass the car rather than being compressed ahead of it. Mitsubishi's system actively controls the pressure inside the car to match the rate of change that human ears can comfortably handle. It's not just about speed — it's about making the experience imperceptible.
Which is the whole paradox of high-speed elevators, right? The better they work, the less you notice them.
That's the design goal. If you step out of the Shanghai Tower elevator and think "wow, that was fast," the engineers have actually failed. The goal is that you step out and think about your meeting, not the ride.
We've got counterweights, regenerative braking, aerodynamic cars, pressure management — all to solve the speed problem. But you mentioned earlier that the real frontier isn't about going faster in a single shaft. It's about rethinking the shaft entirely.
And this is where we get to the ThyssenKrupp MULTI system, the first operational ropeless elevator. The core idea is borrowed from maglev trains. Instead of a cable pulling the car, the car has its own linear motor. Electromagnetic coils in the shaft create a moving magnetic field that propels the car upward, downward, and — this is the key part — horizontally.
The MULTI system can move multiple cars in a single shaft, and at the top and bottom of the building, the cars can switch from one shaft to another using a rotating exchanger. It creates a continuous loop, like a paternoster but with independent, computer-controlled cars that don't require passengers to jump on and off a moving platform.
You've got multiple cars running in a loop. They can't pass each other in the same vertical section — that would be a collision hazard — but they can be in the same shaft loop at different positions, and the exchanger at the top and bottom routes them between shafts. The practical effect is that you can have far more cars operating in far less shaft space. A building that would have needed six or eight traditional shafts might need only two or three MULTI shafts. That's a huge gain in rentable floor area.
This isn't a concept on a drawing board. Two operational installations so far: the OVG Real Estate East Side Tower in Berlin, and the Sunac Guangzhou Tower in China. Neither is a super-tall — the East Side Tower is about a hundred and forty meters — but they're proof of concept. The MULTI system works.
What's the catch?
Cost and complexity. The linear motor technology requires electromagnetic coils along the entire length of the shaft, plus the exchanger mechanisms at the top and bottom, plus the control software to manage multiple independent cars in a shared loop. It's significantly more expensive than a traditional cable elevator. For buildings under about three hundred meters, the space-saving argument doesn't always justify the premium.
It's a solution for the ultra-tall, or for buildings where floor area is at an absolute premium.
But that's how every new elevator technology starts. The first safety elevator — Elisha Otis's demonstration in eighteen fifty-four, where he cut the rope and the safety brake caught the car — was a niche curiosity until buildings started going taller than five or six stories. Once the building typology changed, the technology became essential. The same thing is happening now. As cities run out of horizontal space and buildings push past five hundred, six hundred, eventually a thousand meters, ropeless systems stop being a luxury and start being the only way to make the building work.
The MULTI isn't even the only approach. There are other ropeless concepts in development, right?
Some use linear induction motors with permanent magnets on the car. Others use a rack-and-pinion drive like a vertical railway. Some are exploring cable-free systems with onboard battery power and wireless charging at each floor. None are as far along as the MULTI in real-world deployment, but the research direction is clear: the future is cable-free.
The physical engineering story is basically: we pushed cable elevators about as far as they can go — Kevlar belts, aerodynamic cars, regenerative drives, active pressure control — and for the next leap, we're borrowing from trains.
And what's interesting is that all of this physical innovation creates a new maintenance challenge. When you've got a machine with linear motors and electromagnetic coils and multiple cars in a loop, you can't just send a technician up with a grease gun once a month. The maintenance model has to change completely.
Which is where the AI and the sensors come in.
And that's the next piece of the puzzle. But first, the thing that strikes me about the MULTI is that it changes what a building can be. If elevators can move horizontally, a building doesn't have to be a single vertical stack anymore. You could have connected towers, skybridges that are part of the transit system rather than just pedestrian walkways. The elevator becomes a three-dimensional transit network.
We're not just making elevators faster. We're changing what a building is.
That's the big picture. And it connects directly to what Daniel was asking about — the algorithms that manage passenger flow. Because once you have multiple independent cars moving in multiple dimensions, the dispatch problem stops being "which car goes to which floor" and starts being "how do you route a hundred cars through a three-dimensional network in real time without collisions or bottlenecks." That's a hard computational problem.
That's where we'll go next — from the hardware that moves to the software that decides. But I want to sit with the image for a second: a building where you step into a car on the fortieth floor, travel horizontally through a skybridge, and emerge on the thirty-fifth floor of the adjacent tower without ever changing vehicles or feeling a transition.
The MULTI does exactly that. The horizontal movement is slow compared to the vertical — about one and a half meters per second versus five or six — but it's seamless. You don't get out and transfer. The car just changes direction.
So we've established the physical frontier: Kevlar belts, aerodynamic cars, maglev shafts, regenerative braking, and the first operational ropeless systems. Next, we need to talk about how you keep all of that from breaking — and how the algorithms decide who goes where.
Let's define the spectrum Daniel's pointing at. On one end, you've got the Jerusalem special — the one where you make eye contact with a stranger and silently agree not to discuss what that grinding sound was. On the other end, you've got machines that are essentially vertical bullet trains. And the dividing line isn't just speed — it's a whole category shift.
What's the threshold? At what point does an elevator stop being "fast" and start being "high-speed"?
The industry generally draws the line around five meters per second. Below that, you're in standard traction elevator territory — perfectly fine for buildings up to maybe thirty or forty stories. Between five and ten meters per second, you're in high-speed. Above ten, you're in super-high-speed. The Burj Khalifa runs at ten meters per second. The Shanghai Tower at twenty point five. That's the current record.
Twenty point five meters per second. For context, that's faster than most city speed limits.
It's not just a bigger version of the same machine. A standard elevator motor might be fifty or sixty kilowatts. A super-high-speed installation can draw over four hundred kilowatts. The braking systems alone have to dissipate enough energy to stop a car that weighs as much as a small truck, moving at highway speeds, inside a distance measured in meters, without turning the passengers into paste.
Which brings us back to the question Daniel's really asking. If the gap between a nineteen-seventies elevator and a Shanghai Tower machine is this vast, what actually changed? Why couldn't someone in nineteen seventy-five just put a bigger motor on the same design?
Three reasons, and they're all interlocking. First, the rope. A steel cable long enough to service a five-hundred-meter building weighs several tons by itself. At some point, the cable is so heavy that most of the motor's energy is going into lifting the cable, not the car. You hit a point of diminishing returns where adding more motor just means adding more cable weight, which means adding more motor. It's a spiral that doesn't converge.
The cable eats its own gains.
Otis cracked part of this with those Kevlar belts — the Gen2 system. A Kevlar-reinforced flat belt weighs about a fifth of what an equivalent steel cable weighs, and it doesn't corrode, doesn't need lubrication, and has a much longer fatigue life. That single innovation made buildings over four hundred meters practical without exotic cable systems.
Even Kevlar hits a ceiling.
Which is the second reason: the single-car-per-shaft paradigm. No matter how fast one car moves, it can only serve one group of passengers at a time. In a building with fifty floors and three thousand people trying to get to work at nine in the morning, you don't just need speed — you need throughput. The shaft itself becomes the constraint. That's what the MULTI system and its successors are trying to solve.
The third reason?
Safety scales nonlinearly with speed. Double the speed, and you quadruple the kinetic energy. The braking systems in a super-high-speed elevator aren't just bigger versions of the ones in a mid-rise — they're fundamentally different designs. Multiple independent brakes, overspeed governors that trigger within milliseconds, hydraulic buffers at the shaft bottom rated for the full kinetic load of a free-falling car. The safety engineering is the invisible half of the speed equation.
What Daniel's asking about isn't really one topic — it's three that had to advance in lockstep. The physical machine, the maintenance model, and the intelligence layer that decides who goes where.
That's the structure we're working with. The physical engineering solved the "how fast can we go" problem. The maintenance revolution solved the "how do we keep this running without killing anyone or shutting down the building" problem. And the algorithms solved the "how do we move three thousand people through twenty shafts without anyone waiting ninety seconds" problem.
If any one of those three lags behind, the whole thing breaks. You can have the fastest car in the world, but if the dispatch algorithm is dumb, people are still waiting. You can have a brilliant algorithm, but if the maintenance is reactive instead of predictive, the cars are down when you need them.
Which is why this episode is going to trace all three. The hardware, the upkeep, and the brain. And the brain part is where things get strange — because a modern destination dispatch system isn't just an elevator controller. It's solving a real-time optimization problem that looks a lot like what logistics companies use to route delivery trucks.
Except the delivery trucks are carrying people who get impatient if the doors don't open fast enough.
The trucks are moving vertically at forty-six miles an hour in a pressurized tube. Same basic idea, slightly different stakes.
Let's pick up the physical thread. We've got a car moving at twenty meters per second. The motor's pulling over four hundred kilowatts. But here's what most people miss — that motor isn't doing all the work all the time. The counterweight does a huge amount of the heavy lifting, literally.
Counterweights are one of those things that are easy to forget about because they're hidden in the shaft. What's actually happening back there?
In a standard setup, the counterweight balances the car plus about forty to fifty percent of its rated load. So if the car weighs a thousand kilos empty and is rated for sixteen hundred kilos of passengers, the counterweight might be around eighteen hundred kilos. The motor only has to overcome the difference. On the way up with a full car, the motor works hard. On the way up empty, the counterweight is actually heavier than the car, so the motor is braking, not pulling.
Which is where the regenerative piece kicks in.
When the motor acts as a brake, it becomes a generator. The kinetic energy of the descending counterweight — or the descending loaded car, depending on direction — gets converted to electricity and fed back into the building's grid. In a high-traffic building, regenerative drives can recover twenty-five to thirty percent of the total energy the elevator system consumes.
The elevator is effectively a pumped-storage system at building scale. Lift mass when energy is available, recover it on the way down.
That's exactly the right way to think about it. And in a super-tall building with dozens of elevators cycling constantly, the energy recovery adds up to real money. The Shanghai Tower's system feeds enough power back into the building to run the lighting on multiple floors.
The counterweight and the regenerative braking are solving the energy problem. They don't solve what happens to the air in the shaft.
No, and the air problem is where the engineering gets elegant. Think about what happens when a box the size of a small room moves through a tube at forty-six miles an hour. The air in front of it has nowhere to go except through the narrow gap between the car and the shaft walls. That creates a pressure wave. Behind the car, you get a low-pressure zone. The faster the car moves, the bigger the pressure differential.
If you don't manage that, you get the ear-pop problem.
You get more than ear pops. You get structural stress on the shaft walls, doors that are hard to open because of the pressure difference, and at extreme speeds, aerodynamic buffeting — the car literally shakes from the air turbulence. Mitsubishi's solution for the Shanghai Tower was to design the car itself as an aerodynamic body, shaped to reduce drag like the nose cone of a high-speed train. The shaft has pressure relief vents at calculated intervals that let air bypass the car rather than being compressed in front of it.
The shaft breathes.
And inside the car, there's an active pressure control system that adjusts the cabin pressure in real time to match the rate of change the human ear can handle comfortably. The threshold is about five millibars per second — anything faster and people feel it. The control system manages the pressure curve so precisely that you can ascend five hundred meters in under a minute and your ears never register the change.
Which is the kind of detail that nobody thinks about unless it fails. The whole experience is designed to be invisible.
That's the hallmark of good vertical transportation engineering. If you notice it, something's wrong.
Alright, so we've solved the energy problem with counterweights and regeneration, and we've solved the air problem with aerodynamics and pressure control. But you said earlier that the real ceiling isn't speed — it's the rope itself.
The rope problem is fundamental. Steel cables are strong in tension, but they're heavy. For a building over about five hundred meters, the cable has to support its own weight plus the car plus the counterweight. The weight-to-strength ratio of steel means that beyond roughly six hundred meters of cable length, the cable is spending most of its strength just holding itself up. You can't fix that with a bigger motor — the cable literally can't take the tension.
This is where the Kevlar belts come in.
Otis's Gen2 system replaced steel ropes with flat belts made of Kevlar strands encased in polyurethane. Kevlar has about five times the strength-to-weight ratio of steel. The belts are flat rather than round, which gives the traction sheave more surface area to grip, and they don't need lubrication, don't corrode, and have a fatigue life measured in millions of cycles rather than hundreds of thousands. That one material change pushed the practical height limit from around five hundred meters to over eight hundred.
Even that has a ceiling.
Everything has a ceiling. And for the next generation of super-tall buildings — the kilometer-plus towers being designed in Saudi Arabia and China — even Kevlar belts become impractical. The belt still has weight, and at some length, you're back to the same problem. Which is why the real frontier is eliminating the rope entirely.
Let's talk about the MULTI. How does a ropeless elevator actually move?
The core technology is a linear motor. In a conventional rotary motor, you've got a stator with coils and a rotor that spins inside it. In a linear motor, you essentially unroll that arrangement. The shaft is lined with electromagnetic coils that create a moving magnetic field. The car has permanent magnets or a secondary set of coils mounted on it. When the shaft coils are energized in sequence, the magnetic field moves upward or downward, and the car is carried along with it — exactly the same principle as a maglev train.
The car is riding a magnetic wave.
That's a good way to picture it. And because there's no physical connection between the car and the propulsion system, you can have multiple cars in the same shaft loop. Each car has its own set of magnets and its own control system. The shaft coils are divided into segments, and each segment is energized only when a car is passing through it. The cars communicate with the shaft controller wirelessly, and the system routes them through the loop without collisions.
The horizontal movement?
At the top and bottom of the building, there's an exchanger mechanism — essentially a rotating section of track that can pivot a car from one vertical shaft to another. The car moves onto the exchanger, the exchanger rotates, and the car is now aligned with a different shaft. It can also move horizontally along a guideway to connect different parts of the building. The horizontal speed is lower than the vertical — about one and a half meters per second versus five or six — but it's continuous. You don't stop and transfer.
The building becomes a circuit. Cars go up one shaft, across the top, down another shaft, across the bottom, and back around.
That's the continuous loop model. And the implications for building design are enormous. First, you dramatically reduce the number of shafts needed. A traditional building might dedicate thirty to forty percent of its core to elevator shafts. The MULTI can cut that by more than half. Second, because cars can move horizontally, you can connect towers at height — not with pedestrian skybridges, but with actual transit connections. The elevator becomes a three-dimensional people-mover.
We've got these machines that can rocket up a building at forty-six miles an hour, with no cables in the most advanced versions, riding magnetic waves through pressurized shafts. But here's the question Daniel's really getting at — how do you keep something that fast and that complex running reliably day after day? Because the old model doesn't work anymore.
The old model being "wait till it makes a noise, then call someone.That was fine when elevators were simpler machines in ten-story buildings. But when you've got a super-high-speed installation moving thousands of people a day, unplanned downtime isn't an inconvenience — it's a building-scale crisis. You can't have the Shanghai Tower's elevators go dark for four hours because a bearing wore out.
The maintenance model had to change as dramatically as the hardware.
The shift is from reactive to predictive — fix it before it breaks. And the enabler is sensors. A modern high-speed elevator has dozens, sometimes hundreds of IoT sensors monitoring everything: vibration on the traction sheave, temperature in the motor windings, door cycle counts, belt tension, brake pad wear, oil condition, even the current draw profile of the motor. All of it streams in real time to a monitoring system.
The elevator is constantly reporting on its own health.
More than reporting — it's generating a data stream that machine learning models can analyze for patterns no human technician would ever spot. A slight change in the vibration signature of a bearing, a tiny increase in the time it takes the doors to close, a subtle shift in the motor's current draw during acceleration. Individually, each of those is meaningless. Together, they can predict a failure weeks before it happens.
This is actually deployed, not theoretical.
It's the industry standard now for major manufacturers. Otis has a system called Otis ONE that creates a digital twin of each elevator — a real-time virtual replica that mirrors the physical machine exactly. The digital twin runs simulations constantly, playing out "what if" scenarios: what happens if this bearing degrades at the current rate, when is the optimal moment to replace the brake pads before they cross the safety threshold but after they've delivered maximum service life.
A digital twin. So there's a ghost elevator living in a server somewhere, aging faster than the real one, and when the ghost breaks, you know the real one is next.
That's the metaphor, yeah. And the accuracy is impressive — these systems can predict component failure with over ninety percent accuracy, sometimes weeks in advance. The maintenance team gets an alert that says "car four, hoist machine bearing, probable failure in fourteen to twenty-one days, schedule replacement." Not "something's wrong" — a specific component, a specific timeframe.
Which changes the economics completely. Instead of emergency repairs at triple overtime, you're doing planned replacements during scheduled downtime.
The downtime itself shrinks. Predictive maintenance can reduce unplanned outages by fifty percent or more, and it extends the service life of components because you're replacing them at the optimal moment — not too early, not too late. For a building operator, that translates directly to lower costs and happier tenants.
The sensors and the digital twin are only half the intelligence story. The other half is what Daniel asked about — the algorithms that decide who goes where. Because even the fastest, most perfectly maintained elevator is useless if the dispatch logic is dumb.
This is where we go from the maintenance brain to the traffic-control brain. The technology is called destination dispatch, and if you've been in a modern high-rise, you've probably used it without realizing what's happening under the hood.
Instead of pressing up or down and then telling the elevator your floor, you enter your floor on a keypad in the lobby, and it tells you which car to take.
And on the surface, that seems trivial — it's just a different way to press a button. But what's happening behind the scenes is a real-time optimization problem that's computationally intensive. The system knows the destination of every passenger who's entered a request in the last few seconds. It's grouping people by floor clusters, assigning them to specific cars, and calculating the optimal route for each car to minimize total travel time — not for any individual passenger, but for the whole population moving through the building.
It's optimizing for the group, not the person.
And that's why it can feel counterintuitive. You might enter floor forty-two and the system assigns you to a car that's currently on floor fifteen, while another car is sitting right there in the lobby with its doors open. Your instinct says "why isn't that car taking me?" But the algorithm knows that the lobby car is about to be assigned to a group going to floors fifty through sixty, and if it took you, those people would wait longer and the whole system would be less efficient.
Which is the traveling salesman problem you mentioned — except the salesmen are elevator cars and the cities are floors and the problem is being solved in real time for hundreds of passengers.
The constraints are brutal. You've got hard physical limits — car capacity, door open and close times, acceleration and deceleration curves, maximum speed. You've got time constraints — people expect a car within thirty to forty-five seconds during peak hours. And you've got a constantly changing set of requests — new passengers are entering destinations every second. The algorithm is continuously re-optimizing as new data arrives.
What's the actual gain? How much better is destination dispatch than the old up-down button approach?
The numbers are substantial. Travel time drops by up to thirty percent compared to conventional group control systems. Energy consumption drops by up to forty percent, because cars are making fewer unnecessary stops and running at more efficient load factors. And average wait times during peak hours can be cut in half. The Empire State Building's twenty-ten retrofit with destination dispatch took average wait times from sixty seconds down to thirty.
Wait, the Empire State Building — a nineteen-thirties building — got destination dispatch?
That's the part of Daniel's question that I think is most interesting. Can you put a modern algorithm in a nineteen-seventies building? The answer is yes, but it's not just a software update. The Empire State Building modernization was a hundred-and-fifty-million-dollar project that touched almost every system in the building. For the elevators, they had to install new controllers, new keypads in the lobbies, new sensors throughout the shafts, and integrate it all with a modern building management system.
You can't just push a firmware update to a nineteen-seventies elevator.
You can't. The hardware is the constraint. Older buildings have fixed shaft configurations — you're not adding shafts or widening them. The control systems might be relay-based or use early solid-state logic that can't talk to anything modern. Retrofitting destination dispatch means ripping out the old controllers, installing new ones, running data cables, mounting keypads, and often upgrading the door operators and motor drives to handle the more dynamic dispatching.
Once you do it, the gains are real.
They're real, and they compound. The Empire State Building retrofit is the textbook case because it proved something that wasn't obvious at the time — that the algorithm gains are real even when the physical plant is eighty years old. They couldn't widen the shafts or add cars, but they could make the cars they had run smarter. And the fifty percent wait-time reduction wasn't from faster cars — it was purely from better dispatch logic.
The intelligence layer is separable from the hardware layer. You don't need maglev to get the algorithm benefits.
And that's the actionable piece for building managers. If you're running a twenty-story office tower from the nineteen eighties, you're not installing a MULTI system. But you can retrofit IoT sensors and predictive maintenance on your existing traction elevators. Vibration sensors on the motor bearings, door cycle counters, oil analysis sensors in the hydraulic system if it's hydraulic. The sensor packages have gotten cheap enough that a mid-rise building can instrument its entire elevator bank for a few thousand dollars.
The payoff is what — fewer surprise breakdowns?
Fewer breakdowns, shorter outages when something does happen, and extended equipment life. The industry numbers suggest predictive maintenance can cut unplanned downtime by fifty percent and add years to the service life of major components. A traction machine that might have needed replacement at twenty years can run to twenty-five or thirty if you're catching bearing wear and alignment drift early. For a building owner, that's real capital expenditure deferred.
The same sensor-and-AI approach that keeps the Shanghai Tower humming scales down to a much more modest building.
It's going to scale further. The cost curve on IoT sensors and edge computing keeps dropping. Five years from now, predictive maintenance will be standard on mid-rise buildings, not just super-talls. The digital twin concept that Otis uses for their high-end installations is already filtering down to their mid-tier product lines.
Which means the gap between the Jerusalem elevator and the Shanghai Tower elevator is shrinking, at least on the maintenance side.
On the maintenance side, yes. On the dispatch side, it's more complicated — retrofitting destination dispatch requires new controllers and keypads, which is a bigger capital project. But even there, the software is getting more modular. Some manufacturers now offer overlay systems that can sit on top of older relay-based controllers and add basic destination logic without a full rip-and-replace.
Alright, so for the building manager listening to this: IoT sensors are the low-hanging fruit, predictive maintenance is the next step, and destination dispatch is the bigger investment but with the biggest passenger-experience payoff.
That's the hierarchy. And for the person who just rides the elevator — the tenant, the visitor — there's something worth noticing too. The next time you walk into a lobby with a destination dispatch keypad, watch how the system behaves. You punch in floor thirty-seven, and it tells you car D. Car D might not be the closest car. It might not be the one that seems obvious. But the algorithm has just solved a miniature optimization problem involving every other person who pressed a button in the
