The direct answer
Name the exact fallback in the PRD. The moment the model can't be reached, every ticket goes straight to a real person in a real queue, and the employee sees one exact line telling them that's what happened, not a blank spinner or a generic error. Then watch that fallback path itself, because a PRD line nobody tests is just words.
Do this, in order
Send every ticket straight to a live human queue the second the model can't be reached.Why: without a named target, "handle it" defaults to whatever the error page already does, which is nothing.
Write the exact words the employee sees when that happens.Why: a spinner and "something went wrong" both read the same as the whole company being down, and the person has no way to tell those apart.
Test the fallback path itself on a clock, not just the model.Why: a fallback that's never been triggered for real is a sentence in a document, not a working system.
Track "sent but never acknowledged" as its own number.Why: the model's own uptime can sit at 100 percent while the queue underneath it is the part that's actually silent.
Give genuinely time-sensitive ticket types a guaranteed response window in the fallback, and leave routine ones on best-effort.Why: promising the same speed everywhere spends real engineering effort where nobody's actually hurt by waiting.
How to answer this, stage by stage
Seven moves, from pinning it to one real product to the line you'd close on.
1
Pin it to one real product before naming any framework
Say it like this
"Say a company built an AI assistant that reads every IT ticket an employee submits, sorts it, and either fixes the easy stuff itself or routes it straight to the right team with a note attached. A few thousand people use it. What I want to walk through is one line that's usually missing from the PRD: what happens the moment that model can't be reached at all."
Why this works
Grounds "the model is unavailable" in one real pipeline before any framework language shows up.
2
Say your structure out loud
Say it like this
"I'd run this through GUARD, because 'what happens when the model's unavailable' is really a fairness question dressed up as an infrastructure question. Who's covered and who isn't, where the gap lands hardest, who can't tell what's actually wrong, the actual fix, and how I'd catch the fix itself failing."
Why this works
Two seconds naming the plan, not a recited acronym before the real thinking starts.
3
Reframe what "handling it" actually means
Say it like this
"Most PRDs already say something here. They say 'show an error message.' That's not a fallback, that's silence with a friendlier font. The real question isn't whether the system can go down, it's whether the person on the other end of it can tell the difference between the AI being down and the whole company being down."
Why this works
This is where a checklist answer and a real answer split apart.
4
Give the one decision, as a real mechanism
Say it like this
"I'd write two things into the PRD by name. One: the moment the model can't be reached, every ticket routes straight into a live human queue, no exceptions, no silent retry loop. Two: the person submitting it sees an exact line, something like 'Smart triage is down right now. A person has your ticket and you'll hear back within 15 minutes,' not a spinner, not 'something went wrong, try again.'"
Why this works
A mechanism you could point to in the PRD, not a description that still needs interpreting.
5
Prove it with the failure it prevents
Say it like this
"Here's what it looks like without that. The model's provider has a 95-minute outage one night during a fiscal close. Thirty tickets go in during that window. All thirty just see a generic error and sit in a queue nobody's watching, because the PRD never named where they should land. One of them is an access request that has to clear before a midnight filing deadline, and the person who filed it has no way to know if it's the AI that's broken or her own laptop."
Why this works
The compressed version of the story below. Four sentences, and the gap is concrete, not hypothetical.
Say it like this
"I'd send a fake ticket through the fallback path itself every few minutes, like a canary, and alert someone if it doesn't get a real acknowledgment back within two minutes. I'd also track 'sent but never acknowledged' as its own number. The model's own uptime can read 100 percent while the fallback route underneath it is the part that's quietly dead."
Why this works
Shows judgment past launch day, catching the gap before it costs anyone a deadline.
Say it like this
"So: name the fallback, name the message, and watch the fallback path like it's a feature, because the day it breaks silently is the day you find out from someone who missed a deadline instead of a dashboard."
Why this works
Restates the decision in one breath, the line an interviewer remembers on the way out.
Let's learn
The ticket box on the intranet doesn't know the difference between a jammed printer and a filing deadline. Same box, same button, for both.
Say a company builds an AI assistant that reads whatever an employee types into that box, works out what kind of problem it is, and either fixes small things itself or sends the ticket straight to the right team with a note attached.
Before it, a ticket landed in one long shared inbox. A person on the helpdesk read it by hand, worked out what it actually was, and passed it along. On a busy day that could take most of a morning before anyone even looked at it.
Now the assistant reads it in under two seconds, tags it, and tells the employee exactly where it went and about how long the wait will be. Across the company's roughly 3,000 employees, it handles about 240 tickets a day this way.
Knowledge spark: what "the model is unavailable" actually means
The assistant doesn't run on the company's own computers. It sends every ticket out to another company's AI system and waits for an answer back, the way a phone call travels over a line you don't own. When that other company has a bad hour, the line just goes dead, and it has nothing to do with the employee's own laptop or Wi-Fi.
None of that is the problem. The problem is the one hour nobody built for: the hour the model itself can't be reached at all. The PRD for this assistant never said, in so many words, what happens then.
On one night in October, that line went dead for 95 minutes, from 10:15pm to 11:50pm, still the middle of the working day for two of the company's overseas offices. Thirty tickets came in during that window. All thirty saw the same line: "Something went wrong. Please try again." None of them got a real answer back until an engineer happened to check the logs three hours later.
Tickets acknowledged within 5 minutes
Same assistant, same night, before and after the fallback existed.
An ordinary day, no outage
99%
During the outage, before the fix
0%
During a later outage, after the fix
100%
The middle row is the one the PRD never planned for. Zero of the thirty tickets that came in during the outage got any real word back inside five minutes, because there was nowhere written down for them to go.
We didn't lose the model for ninety-five minutes. We lost the twenty minutes one of those thirty people didn't have.
Here's the part that matters. Ninety-five minutes of downtime isn't the real cost, not on its own. Most of those thirty tickets could wait until morning and nobody would notice. The real cost lands on whichever one of the thirty happened to be racing a clock that didn't move for the outage.
At its worst, that person has no way to know if this is a five-minute blip or a five-hour outage, so they can't tell anyone above them anything useful, they just keep retrying a form that was never going to answer, and the one thing standing between them and a missed deadline is luck about how long the outage happens to run.
The decision I would take back
The PRD said the assistant would "show a standard error state, consistent with the rest of the intranet" if the model couldn't be reached. That read as handling it. It just meant nobody had actually decided what happens to the person on the other side of that screen.
What I would leave alone. A ticket about a stuck printer or a software install doesn't need any of this. If it sits in a queue for an extra hour during a rare outage, nobody's hurt and nothing's lost. The fix only has to matter where waiting genuinely costs someone something.
The lesson. A PRD line that says "show an error" looks like it answered the question. It didn't. It just moved the actual decision from a document onto whichever employee happens to be using the tool the moment it breaks.
Now here is the same thing as a story
The short version sits above. Read this one for how one PRD line turned into a two-minute margin nobody should have had to gamble on.
Yelena Brandt can close a set of year-end audit workpapers faster than anyone else on her team, and she almost never needs a second pass at them. She's a senior associate at Pemberton Ash, an accounting and advisory firm with about 3,000 people across a dozen offices.
Before the ticket assistant, she'd log a request into a shared inbox and wait, sometimes for hours, while someone on the helpdesk read it and decided where it should go. Once the assistant arrived, that changed almost overnight. She'd type what she needed into the box on the intranet, and within a couple of seconds it told her exactly which team had it and about how long the wait would be.
She trusted it enough that she stopped doing what she used to do, which was pinging the helpdesk's Slack channel directly to make sure a ticket had actually landed somewhere. The first month, she still pinged for every single one, just in case. By the third month, she only pinged for anything she'd call urgent. By month six, she'd stopped pinging altogether. The assistant's confirmation note was enough, every time, for six straight months.
Then came an ordinary Tuesday in October, nothing dramatic about it, deep into her firm's fiscal year-end close.
At 10:15pm, the outside company that runs the model behind the assistant had a service incident. Nothing announced it on Pemberton Ash's end. The ticket box on the intranet just spun a beat longer than usual, then showed: "Something went wrong. Please try again." She tried again. Same message.
Holt held the decision. Yelena just hit whatever the decision had left out.
She needed a VPN certificate reissued to reach a client's financial system before a regulatory filing was due at midnight, and a partner was waiting on it. Nothing on her screen told her the ticket system itself was the problem, so she assumed it was her own laptop. She submitted the request four more times over ten minutes. She texted a colleague to ask if the portal was down for them too. She dug through an old onboarding email looking for a helpdesk phone number that had been retired eighteen months earlier, back when the box on the intranet replaced it.
The step that should sit third, and doesn't
We didn't lose the model for ninety-five minutes. Yelena lost the twenty minutes she didn't have.
The outage cleared on its own at 11:50pm, ninety-five minutes after it started, for reasons that had nothing to do with anything Yelena did. The assistant picked back up, reissued her certificate, and she was into the client's system with the filing sent at 11:58pm. Two minutes to spare. If the outage had run ten minutes longer, the filing simply wouldn't have gone out, and nobody would have known why until the next morning.
She wasn't careless, not for one second of it. She did exactly what a careful person does when a form breaks: assume it's you, try again, ask around, look for another way in. The design gave her no other move.
Eight months earlier, when the PRD for this assistant was under review, Holt Bannerman, the product manager who owned it, had asked the room what should happen if the model couldn't be reached. The answer that made it into the document: show a standard error state, consistent with the rest of the intranet. It read as reasonable at the time. Outages were supposed to be rare, and building a whole separate pathway for something that would almost never happen felt like effort spent in the wrong place. Nobody in that room pictured one specific person with one specific deadline.
Run the same Tuesday again, with the fix in place. The moment the model call fails, Yelena's ticket drops straight into a queue a live person watches, tagged the way she'd flagged it: regulatory deadline, tonight. Her screen tells her exactly that: "Smart triage is down right now. Your ticket went straight to a person, and you'll hear back within 15 minutes." An on-call engineer sees it, resets her certificate by hand, and she's back into the client's system by 10:35pm. The filing goes out over an hour before the deadline instead of two minutes before it.
The old design assumed the average case protected everyone. It did, almost all the time, which is exactly why nobody noticed it had never protected the one person who'd land in the gap.
What I'd tell myself, back in that PRD review: we asked what happens when the model goes down. We never asked what happens to the one person who's in the middle of something when it does.
GUARD, when the fallback is the whole feature
This is a risk question wearing an infrastructure question's clothes. "What happens when the model's unavailable" sounds like uptime and error codes. The real test is whether the PRD ever named who's standing on the other side of that failure, and what they actually see.
G, groups. Every employee who submits a ticket, most of them landing in an ordinary minute when the assistant is working fine, and the smaller group who happen to submit one in the exact window it isn't.
U, unequal. The gap doesn't cost the same to everyone who hits it. It's nearly free for a ticket about a stuck printer. It's expensive for a ticket tied to a deadline that doesn't move, like Yelena's midnight filing, where there's no other way to get the same thing done in time.
A, ability to contest. Yelena can't tell "the AI triage is down" from "the whole intranet is broken" or "it's my laptop," and there's no route around it, because the old way of calling the helpdesk directly doesn't exist anymore. This box replaced it.
R, reduce. Name the fallback in the PRD by name: the moment the model can't be reached, every ticket goes straight into a live human queue, and the employee sees an exact line telling them that's what happened, not a generic error.
D, detect. Send a fake ticket through that same fallback path every few minutes, and alert someone the second it doesn't get answered within two minutes. Track "sent but never acknowledged" as its own number, not folded into the model's uptime score.
Where this answer would fail
If the fix here is "add a status page" or "tell people to email IT when the tool's acting up," it doesn't count. A status page still asks Yelena to already suspect the AI, and an email address is exactly the manual path the product was built to replace. Routing the ticket itself into a real queue, automatically, is the only version that actually closes the gap.
And if you want to be sure it really works, try it somewhere else
A regional hardware and home-goods chain runs an AI ticket-triage assistant for its store associates, built the same way: read the ticket, fix it or route it. Different company, same five letters, same trap.
G, groups. The chain's IT platform manager, who wrote the ticket-triage spec, and the store associates on the sales floor who submit tickets from a tablet at the register.
U, unequal. The gap barely registers on a quiet Tuesday morning about a broken label printer. It costs real money during a Saturday promotional rush, when a register goes down and a line is forming behind it.
A, ability to contest. An associate has no way to tell "the triage bot is down" from "the whole store network is down," and the only escalation left is calling a manager who doesn't know either.
R, reduce. Route straight to a live regional support line the instant the bot can't be reached, with an exact line on the tablet screen saying that's what happened.
D, detect. Send a canary ticket from a dummy register every few minutes, and page the on-call team the moment one goes unanswered.
Swap the trigger and it still runs
- Speed: the team doubles how often it pushes new triage categories, so an untested one hits the gap before anyone spots the pattern.
- Cost: writing a named fallback message for every category takes real design and engineering time, so it keeps losing to whatever's next on the roadmap.
- The model gets better: a newer version cuts wrong-routes in half, and outages start looking rarer, which makes it easier to keep skipping the fallback instead of harder.
Where people run it wrong
- Treating "we show an error message" as though it's already the fallback, instead of the absence of one.
- Testing the fallback once at launch and never again, even after the on-call rotation, the routing rules, or the ticket categories change underneath it.
- Watching model uptime as the whole health picture, when the fallback path underneath it can be the part that's actually broken.
How to buy yourself thinking time
Ask "what does the person actually see the second this fails?" before you say anything about the fix. It's almost always where the real gap is hiding, and it buys you a few seconds to find it.
Flashcards (click a card to flip it)
1 · THE FRAMEWORK
What framework fits a question about what a PRD says when the model's unavailable, and why?
Tap to flip
ANSWER
GUARD, for risk and fairness. The real question is the power gap between whoever decides what counts as "handled" and whoever hits the outage window with no way to tell what's wrong.
2 · THE PERSON
Who is this answer about?
Tap to flip
ANSWER
Yelena Brandt, a senior audit associate at Pemberton Ash, who can close a set of year-end workpapers faster than anyone else on her team.
3 · THE HABIT
What did Yelena stop doing once the assistant reliably confirmed her tickets had landed somewhere?
Tap to flip
ANSWER
She stopped pinging the helpdesk's Slack channel to double-check a ticket had actually landed. By month six she never checked at all, because the assistant's own note had always been enough.
4 · THE GAP
What's the gap this answer turns on?
Tap to flip
ANSWER
The PRD never named a fallback, so the moment the model went down, Yelena couldn't tell "the AI is down" from "the whole intranet is broken," and had no way to route around it because the box had replaced the old manual path.
5 · THE OLD DECISION
What old decision does this answer take back, and why did it make sense at the time?
Tap to flip
ANSWER
The PRD said the assistant would "show a standard error state" if the model couldn't be reached. It made sense when outages looked rare enough not to deserve a whole separate pathway. It stopped working the moment a real person hit that window with a deadline attached.
6 · THE NUMBER
Fill in: of the thirty tickets that came in during the outage, ______ got a real acknowledgment inside the first five minutes.
Tap to flip
ANSWER
Zero. All thirty saw the same generic error, and nobody found out until an engineer checked the logs three hours later.
7 · THE REPLAY
Same outage, new PRD. What changes?
Tap to flip
ANSWER
Yelena's ticket drops straight into a live human queue the moment the model call fails. An on-call engineer resets her certificate by hand, and she's back into the client system by 10:35pm, over an hour before the deadline instead of two minutes before it.
8 · TRANSFER
Section four runs GUARD again on a different product. Which one, and what does the "unequal" gap become?
Tap to flip
ANSWER
A regional hardware chain's AI ticket-triage tool for store associates. The gap: it barely matters on a quiet Tuesday, and costs real money the moment a register goes down during a Saturday rush.
Check yourself Score: 0 / 0
Multiple choice
1. During the outage, Yelena assumed her own laptop was the problem and kept retrying the same form. She had no way to know the model behind the assistant, not her VPN, was actually down. What does this actually show?
- A. Yelena should have known to check the intranet's status page before assuming her laptop was broken.
- B. The PRD never named a fallback or a distinct message, so the same generic error covered both "your laptop" and "the whole AI feature is down," and Yelena had no way to tell them apart.
- C. The model provider's outage was unusually long, and a shorter outage wouldn't have caused a problem.
- D. Yelena needed more training on how the ticket system works.
Show hint
Ask what the screen actually told her, not what she could have theoretically guessed.
Show answer
B. A, C, and D all put the fix on Yelena or on luck. The real failure is that one generic message covered two completely different problems, and nothing on her screen told her which one she had.
True or false
2. True or false: since a ticket about a broken software install can safely wait out an outage with no real cost, the fallback response window should be the same relaxed pace for every ticket category, including regulatory-deadline requests like Yelena's.
Show hint
Ask who actually gets hurt by a slow fallback, and who doesn't.
Show answer
False. A software-install ticket sitting an extra hour costs nobody anything. A deadline-tied ticket sitting the same hour can cost a filing. The guaranteed response window belongs on the categories where waiting is actually expensive, not spread evenly for its own sake.
Fill in the blank
3. The outage that hit Yelena's ticket lasted ______ minutes, and cleared on its own with only two minutes left before her filing deadline.
Show hint
It's the number the whole story turns on, from 10:15pm to 11:50pm.
Show answer
95 minutes. Ten more minutes of outage, and the filing would have missed the deadline entirely, with nobody able to say why until the next morning.
Short answer
4. If the outage that hit Yelena had lasted 9 minutes instead of 95, would the PRD still need to name a fallback? Why or why not?
Show hint
Ask whether the problem is the length of the outage or the fact that nobody ever decided what happens during one.
Show answer
Model answer: "Yes, still needed. A 9-minute outage during the wrong 9 minutes costs exactly the same as a 95-minute one, if that's the window a deadline falls into. The fix isn't about how long the outage runs, it's about whether any length of silence has somewhere defined to go."
Short answer, apply it yourself
5. Think of an app or tool you rely on that occasionally goes down or errors out. When it fails, does it tell you what actually broke, or just show you a generic error? What's the cost of not knowing the difference?
Show hint
Look for the moment a "try again" message left you guessing whether the problem was you, your connection, or the service itself.
Show answer
Model answer: "My bank's app just says 'unable to complete request' whether it's my Wi-Fi, my card being frozen, or their servers being down. I've resubmitted a payment three times before realizing it was on their end the whole time, which is exactly the same guessing game Yelena was stuck in."
Multiple choice
6. Why couldn't the fix here just be "make the error message friendlier and ask people to wait a few minutes and try again"?
- A. Because a friendlier tone would confuse employees even more than a plain error would.
- B. Because "wait and try again" still leaves the person with no route around the outage and no way to know if waiting is even the right move, which is exactly the gap that hurt Yelena.
- C. Because the model provider would need to approve any change to the error message text.
- D. Because friendlier language costs more engineering time than a real fallback does.
Show hint
A nicer version of "try again" is still "try again." Ask what it actually changes for the person stuck in the outage window.
Show answer
B. A softer tone is a dial turned up on the same broken design, not a decision taken back. The person still has no queue to land in and no way to judge whether to keep waiting, which is the actual problem.
