What is the right latency expectation for an agent, and how do you set it with users?

Interviewer's question: "What is the right latency expectation for an agent, and how do you set it with users?" Falkenridge Air's SwiftPath agent rebooks passengers during weather cancellations and mechanical delays. Nadira Vosloo is the product lead. Osric Dumaine is a passenger stranded on a cancelled connection.

How to answer this, stage by stage

Nobody is grading whether you know agents can feel slow. They are grading whether you can name which kind of wait actually costs you the passenger.

Let's learn

SwiftPath watches for flight disruptions and rebooks affected passengers automatically, without a phone agent working the case by hand.

Before SwiftPath, a passenger calling about a cancelled flight during a storm night waited an average of twenty two minutes on hold before a human agent could even start searching for a new seat.

Ninety seconds sounds slow next to a spinner. It sounds fast next to twenty two minutes on hold.

Now, the moment a flight is marked cancelled, SwiftPath shows the passenger a held seat on the next available flight within about three seconds, clearly marked as temporary, while it keeps searching every interline option underneath for up to ninety seconds.

Here is the turn: three seconds versus ninety seconds is not really the argument. The real argument is whether the wait, however long it runs, is silent or honest. A passenger who sees an instant, clearly-labeled hold relaxes. A passenger staring at a spinner for even ten seconds starts calling the airline's help line on a second phone, undoing the whole point of automating this.

At its worst: a passenger's interim hold gets treated as final because nothing on screen said otherwise, they board a routing that cost them a four hour layover, and never learn a better one existed forty seconds after they stopped looking.

Both panels are labeled as costs. Only one of them can quietly cost you the passenger forever.

What I would leave alone: a routine same-day rebooking with no disruption, a passenger asking to move to an earlier flight on a normal Tuesday, doesn't need any of this. The answer there is already fast and already final, and adding a "temporary" label would just create doubt where none belongs.

The lesson: latency is not one number to hit. It's a decision about which kind of wait a passenger will forgive, and silence is never the kind they forgive.

Now here is the same thing as a story

The short version above is what you'd say defending this design in a product review. Read this one for how the gap actually got found.

Osric Dumaine's connection got cancelled at 9:40pm on a night Falkenridge Air grounded eleven flights for weather. He had a hotel booked forty minutes from the wrong airport and a nine year old asleep on his shoulder.

He opened the app expecting to wait. Instead, three seconds after the cancellation posted, SwiftPath showed him a seat on the 6:05am flight the next morning, marked "Temporary hold, still checking for a better option."

The second step is the one the whole design bet rides on.

He didn't love the 6:05am flight. But he had a seat, in three seconds, on the worst night of Falkenridge's month. He put the phone down and went to find his son a blanket.

Eighty seconds later, quietly, SwiftPath found a 4:50am departure on a partner airline with a shorter layover. It swapped the hold and sent a notification. Osric didn't see it until he woke his son at 4am for the shuttle, and by then the better seat was simply the one waiting for him.

Nadira Vosloo's team almost shipped a different version. In an early design, SwiftPath said nothing for the first ninety seconds, so the very first thing a passenger ever saw was the fully optimized answer, no interim hold, no "still checking." It tested beautifully in calm conditions, where ninety seconds barely registered.

Then came a real storm night with four thousand passengers rebooking inside twenty minutes. The optimization queue backed up. Some passengers waited past four minutes for any answer at all, staring at a spinner, with no idea whether the app had frozen or was simply thinking.

The middle branch is the one the silent design never built.

Support calls spiked, not because the rebooking was wrong, but because nobody could tell if anything was happening. Several passengers called Falkenridge's help line and got rebooked manually by a human agent, moments before SwiftPath's own optimized answer would have landed, wasting both the passenger's patience and the agent's time on a case the system was already solving.

The decision Nadira's team took back: silence was never neutral. Waiting for a "complete" answer with nothing shown in between reads, under real load, exactly like a broken product. They rebuilt it to show the instant hold first, every time, live-inventory-confirmed, and let the optimization keep running visibly underneath.

Replayed on the same storm night with the new design: every one of those four thousand passengers sees a seat within three seconds. The ones whose hold later improves get a notification instead of silence. Support calls on disruption nights dropped by more than half, not because SwiftPath got smarter, but because nobody was left wondering if it was even working.

I once believed the "real" answer was the honest one and anything shown before it was a lesser version pretending to be finished. It took one bad storm night to see that a fast, clearly-labeled interim answer is not a lesser version of honesty. Silence dressed up as thoroughness is the actual dishonesty.

PICK, in one screenNot a UX debate about spinners. PICK is what tells you which kind of wait a passenger will forgive.

Skip the first item and a fast answer becomes a confidently wrong one.

The recap, one line per letter: position is a fast honest hold, not a silent wait, impact is the passenger's anxiety against the airline's rework cost, cost asymmetry is a visible correction beating a hidden lost booking, and kill criteria is watching how many passengers never see an upgrade at all.

And if you want to be sure it really works, try it somewhere elseSame four letters, a veterinary telehealth line instead of an airline gate. A different cost asymmetry, the same shape of decision.

Thornvale Veterinary Telehealth runs an agent that answers a pet owner's call at 11pm, gives immediate triage guidance, and can either resolve the call or queue a full callback from an on-duty vet who reviews the pet's history first.

Mapped onto PICK: position is the same shape, show fast interim guidance immediately ("keep them calm, don't give food or water, here's what to watch for") rather than making a frightened owner wait in silence for a vet to become free. Impact: the owner feels every silent minute as rising panic over a possibly sick animal; the clinic feels a rushed, incomplete answer as a real risk of missing something serious. Cost asymmetry, and here it flips: an interim answer that's too confident about a symptom can be genuinely dangerous, not just annoying, so the interim guidance has to be strictly limited to safe, reversible advice, never a diagnosis, while the full vet callback is what actually cost asymmetry protects. Kill criteria: if pet owners start treating the interim guidance as a full diagnosis and skip the vet callback altogether, that is evidence the interim answer needs to state its limits more forcefully, not just faster.

Swap the trigger and it still runs.
Speed: an interviewer caps you at thirty seconds. Say "fast honest interim beats slow silent complete, because silence is what a passenger can't forgive," and stop.
Cost: if interline API calls get too expensive to run on every passenger, cap the optimization pass by time or by fare-class tier instead of removing the interim hold, since the interim hold is the part that protects trust.
The model gets better, for real: if SwiftPath's full search gets fast enough to run in three seconds flat, the interim/final split still matters during a true mass-disruption event, when queueing thousands of full searches at once would recreate the exact same silent wait a faster median hides.

Where people run it wrong.
They treat "make it faster" as the whole answer, and never ask what the wait actually communicates while it's happening.
They ship a spinner with no interim result because it feels more honest than showing something that might change, and then watch trust collapse under real load anyway.
They let the fast answer look identical to the final one, so nobody notices when it quietly upgrades, and nobody notices when it doesn't.

How to use it live. When someone asks you about agent latency, ask yourself one thing out loud: if this exact wait went on twenty times longer than expected tonight, would the user know something was happening, or would they assume it broke.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0