Elevators Are Algorithms: Scheduling, Dispatching, and Why Waits Feel Personal

You’ve pressed the button. Twice, maybe—because the first time you weren’t sure it registered. The doors don’t open. You look up at the floor indicator, half-expecting it to blink back an apology.

It’s tempting to treat elevators like stubborn furniture. But the truth is more interesting: an elevator bank (a group of cars serving the same set of floors) is basically a distributed scheduling system. Every “what floor should this car stop at?” and every “who should get into which car?” decision gets computed under time pressure, with uncertainty, and with competing goals.

This is why elevators feel both magical and maddening. The magic is real optimization. The maddening part is that you only experience the output, never the trade-offs.

The first model: one car, one job at a time

Start with the simplest case: a single elevator car serving a set of floors. Now the problem is mostly about ordering stops.

A classic strategy from computer science for this kind of scheduling is called SCAN. SCAN is the “sweep” approach: when the car starts moving in one direction, it keeps going, serving requests in order, until it reaches the end of its range—then it reverses.

If you’ve ever ridden an elevator that seems to “commit” to going all the way up before turning around, you’ve seen SCAN-like behavior.

LOOK: SCAN’s more practical cousin

SCAN assumes requests might exist all the way at the top. But real buildings aren’t full of worst-case surprises. If there are no pending requests beyond some floor in the current direction, the elevator doesn’t need to waste time continuing.

That tweak leads to LOOK: the car “looks” for the farthest pending request in the current direction, and reverses as soon as it has served the last useful stop.

The beginner-friendly takeaway: both SCAN and LOOK are ways to reduce back-and-forth movement. LOOK tends to feel smarter because it avoids pointless travel when nothing is waiting above or below.

When there are multiple cars, you get a coordination problem

Add more than one elevator car, and suddenly the story changes.

Now there are two intertwined decisions:

1. Assignment: which car should serve a new hallway call (the request created when you press “up” or “down” at a floor)?
2. Routing: once a car is assigned, what sequence of stops should it make?

A very basic system uses a central scheduler: whenever a call arrives, it assigns that call to the “closest” elevator. “Closest” might mean fewest floors away, or best predicted arrival time.

That works until you notice something uncomfortable: “closest” doesn’t account for the fact that a car can be busy, almost-full, heading in the wrong direction, or about to become crowded. In other words, the car that’s nearest isn’t always the car that will actually deliver the best experience.

Measuring elevator quality: not averages, but distributions

When people talk about elevator performance, they often default to mean wait time. That’s understandable—means feel objective.

But elevator waits are bursty, and sometimes “one terrible wait” dominates your memory. So engineers care more about the distribution of wait times.

What p50 and p90 mean

Two common summary statistics are:

• p50 (median): the time where 50% of riders waited less, and 50% waited more.
• p90: the time where 90% of riders waited less, and only 10% waited more.

Here’s the intuition: if p90 is high, that means there’s a “long tail” of bad experiences. Riders don’t remember the average; they remember the worst stretch.

This is why elevator scheduling often targets reducing those long waits rather than merely shaving off small amounts from everyone.

Why morning rush is different from lunch

Elevator traffic isn’t uniform throughout the day. A corporate building has distinct patterns:

• Morning: mostly lobby → upper floors (up-peak)
• Evening: mostly upper floors → lobby (down-peak)
• Lunch: a mix
• Interfloor traffic: people bouncing between mid-levels

Those patterns change the “shape” of the call queue and how many cars are likely to be positioned usefully.

And this is where your frustration makes sense: some schedules accidentally create situations where the system spends time moving cars in directions that temporarily don’t match where new callers are coming from. Morning rush, in many buildings, amplifies that mismatch.

Smarter dispatching: scoring which car is best

Now let’s talk about the more advanced approach described by industry scheduling systems: instead of saying “choose the nearest car,” they compute a score for each car.

A real example is Otis’s Relative System Response (RSR) idea. The core pattern is:

• For each incoming hall call, estimate how good it is for each car to pick it up.
• Assign the call to the car with the best (lowest) score.

The scoring function in the story is a mix of:

• ETA to pickup: estimated time until the car reaches your floor.
• Onboard load penalty: if the car is already carrying lots of riders, it’s more likely to be uncomfortable and slower to handle future flows.
• Same-direction anti-bunching penalty: a rule to avoid “bunching” cars that both chase the same kind of requests.
• Direction match bonus: if the car is already moving in the direction that matches your trip, that’s valuable.
• Idle nearby bonus: idle cars close to you are great candidates.
• Low-load bonus: lightly loaded cars are preferred because they can absorb demand.

This is a theme you’ll see in many scheduling systems: the algorithm isn’t trying to be “right” in one dimension. It’s balancing multiple objectives at once.

Re-optimization matters

One of the reasons these systems can outperform simpler rules is that they don’t treat assignment as permanent. As conditions change—new calls arriving, cars moving, congestion forming—the dispatcher can revise decisions.

Conceptually, it’s the difference between:

• choosing once and committing forever, versus
• continuously updating your best guess as the world evolves.

LOOK vs RSR: when smarter rules help (and when they don’t)

With the scoring mindset in place, it’s natural to benchmark:

• LOOK: “serve stops in direction order; keep things moving efficiently.”
• RSR-style dispatching: “also choose the best car based on a multi-factor score.”

A key outcome shown by simulation-style thinking (and often seen in real systems) is that the benefit of complex rules depends on demand level.

When traffic is modest, the system has flexibility. It can route callers to less-busy cars, spread load across the bank, and avoid bad long waits.

When traffic is extremely heavy, cars get “cornered” into stopping everywhere. In that saturated regime, there’s less room for dispatch cleverness to change outcomes—so a simpler strategy can sometimes match or even beat the more complex one.

This is a broader lesson from engineering: an algorithm can be brilliant in the middle of the operating range and less distinctive at the extremes.

Destination Dispatch: more information, less freedom

Now we reach the feature that feels futuristic: Destination Dispatch.

Instead of pressing “up” or “down,” passengers enter their destination floor on a kiosk or keypad. The system then tells them which elevator to take.

In theory, this gives the optimizer more information. And yes, it can reduce the number of unnecessary stops by grouping riders who share destinations.

But the crucial trade-off is rigidity.

In a traditional hall-call setup, the system assigns cars in a flexible way, and reassignment can happen as new calls arrive and the world changes. With Destination Dispatch, passengers are steered toward an assigned car early, and that makes it harder to “swap plans” when conditions evolve.

So the counterintuitive result shows up:

• Destination Dispatch can be great for flow and grouping.
• Yet for wait-time distribution—especially the long tail—it can underperform traditional up/down buttons in many common building scenarios.

There are, of course, edge cases where the trade flips in favor of Destination Dispatch. The more cars you have per group, the more the optimizer can turn destination knowledge into true savings without losing too much flexibility.

The part you never see: the simulation of all those “what ifs”

If you zoom out, elevator banks are doing something like an ongoing simulation:

• Generate new calls (passengers entering the system).
• Predict where each car will be.
• Decide assignments using a scheduling policy.
• Route cars using a stop-order strategy.
• Re-evaluate as time passes.

When you model it, knobs matter. Building size, number of cars, call rates (flow), and traffic patterns shift which algorithm wins.

That’s why the “same elevator building” can feel totally different depending on the hour.

Conclusion: your elevator isn’t ignoring you

Waiting for an elevator can feel personal. The doors don’t open on your schedule, and the moment stretches.

But underneath that moment is a real optimization problem, full of competing incentives: reduce long waits, keep cars moving efficiently, avoid congestion, and respond to changing demand.

Next time an elevator seems late, it’s less that it didn’t hear the call and more that it had a lot of competing calls to think about. Your request was one input into a fast, continuously changing decision system—like a tiny piece of real-time scheduling math carried out in steel and motion.