Describe how you would use support tickets, search logs and abandoned sessions as an opportunity source.
Marrowbox mails a curated box of regional pantry ingredients and a recipe card to subscribers every month. Solaun Odame owns the account page: the help center, the search bar, and the cancel button. This is the cycle she learned her three biggest data sources had been sitting three logins apart, each one holding a third of the same story.
- Cross-reference all three sources against the same flow and the same time window.Why: one source alone can look like noise. The same shape in all three at once is the strongest proof you will get.
- Start with the abandoned sessions, not the tickets.Why: most people who hit a wall never write in, they just leave, so this is the biggest source and the one every team skips.
- Treat a zero-result search as a need someone already put into words.Why: it is a complaint that never got angry enough to become a ticket, caught before it disappears.
- Rule out the boring explanations before believing the exciting one.Why: a noisy handful of people, or a badly labeled button, can look exactly like a real gap until you check.
- Test the fix small before anyone builds it big.Why: only a real drop in the abandonment number proves the opportunity, not a hopeful reading of ticket sentiment.
- Route by what someone actually says, not by one static button.Why: an intent check can send "just need a break" to pause and "too much this month" to a different offer, from the same screen.
How to answer this, stage by stage
Nobody is grading whether you know subscription boxes. They are grading whether you can turn three separate, half-ignored data sources into one testable opportunity.
Let's learn
What happens to a complaint that never gets typed?
Marrowbox mails a curated box of regional pantry ingredients and a recipe card to subscribers every month. Solaun Odame owns the account page: the help center, the search bar, and the cancel button.
For two years, every ticket tagged "cancellation" went into a queue, got answered, and got closed. Search queries lived in a tool the SEO contractor checked once a quarter. Recordings of the cancel flow lived in a product analytics tool the growth team used for new-subscriber onboarding, never for cancellation. Three tools, three logins, and nobody had ever pulled all three for the same flow in the same weeks.
This cycle, a support agent's stray comment sent Solaun looking sideways instead of deeper. Not further into the tickets. Into the search bar and the cancel flow's own drop-off numbers, for the very first time.
Here is what showed up once she actually lined them up. Over eight weeks, 214 searches for "pause" or "skip" landed in the help center, and 152 of them, 71 percent, came back with no useful result at all. Three hundred eighty seven people opened the cancel flow and quit on the very first screen, the one where you pick a reason, a 43 percent drop-off against 11 percent everywhere else in that same flow. And ninety six tickets that same eight weeks said some version of "I just wanted to skip a box, not cancel."
The timing mattered as much as the size. Three days before every ship date, all three numbers moved together: the pause and skip searches climbed, the reason-select screen lost more people than usual, and the tickets calling it a mistake landed in the same narrow window.
Here is what it costs at its worst. Every cycle Marrowbox goes without cross-referencing, some share of those 387 people get counted as a lost customer instead of what they actually were: someone who wanted a week off, not a goodbye. And the engineering time nobody spent on this keeps going somewhere else, usually into a bigger, more general help-center chatbot that answers everything except the one specific thing four hundred people a cycle were actually stuck on.
What I would leave alone: the new-subscriber quiz that picks a starter box. It has one clean number, how many people finish it, and nobody has found a hidden pattern split across three tools there. Running a three-way cross-reference on a problem that already shows up cleanly in one source is wasted work.
The lesson: three tools sitting apart is not a neutral fact. It is a decision, even when nobody chose it on purpose. Looked at alone, each one will always seem calm enough to leave for later.
Now here is the same thing as a story
Say the short version out loud in an interview. Read this one when you want to feel exactly how three tools sat three logins apart for two years without anyone noticing.
Solaun Odame has read every ticket her team escalates for two years. Ask her what the top five complaint categories were last quarter and she'll list them from memory before her coffee's gone cold.
Marrowbox's account page has had a cancel button since the company's first year. Click it, pick a reason from a short list, confirm, and you're done in under a minute. It has worked, more or less, since 2019.
Three other tools sat around that button the whole time. The helpdesk held every ticket. A search analytics tool held every query typed into the help center's search bar. A session tool, built for the onboarding team, quietly recorded where people clicked and where they gave up, on every page, including the cancel flow. Nobody had ever pulled all three for the same eight weeks.
It started with a stray comment. In a Tuesday standup, a support agent two desks over said, half joking, "we get the same weird ticket every month, right before boxes ship." Nobody wrote it down. Solaun did.
That week she opened all three at once, for the first time, and lined up the same eight weeks side by side on one sheet. Each source turned out to be a different kind of proof. The tickets were something someone got angry enough to type. The search queries were something someone looked for and never found, whether or not they ever complained. The abandoned sessions were the biggest pile of all: everyone who tried something, hit a wall, and left without saying a word.
Three days before every ship date, searches for "pause" and "skip" climbed. The same three days, the cancel flow's reason-select screen, the very first click after "cancel my subscription," started losing people at nearly four times its normal rate. And the tickets that mentioned wanting a break instead of a goodbye landed in exactly the same window.
Before she believed any of it, Solaun wrote down three honest guesses. One: this was just a noisy handful of people, no real pattern. Two: pause already existed somewhere, badly labeled, and people just couldn't find it. Three: there was a real, common want, a short break, not a goodbye, that nothing in the product currently served.
The first guess didn't survive the repeat. Both ship cycles in the eight-week window showed the same shape, three days out, roughly the same size. The second guess didn't survive a look at the actual product: there was no pause button to mislabel. It had never been built. Only the third guess matched everything the three sources showed at once.
The team's first idea on the table was the cheap one: add a plain "skip this month" link next to the cancel button and call it done. Solaun turned it down. A static link handles pause. It does nothing for the customer whose real answer is "this is too expensive right now," who needs a discount offer, not a pause, or the one who's genuinely moving and just needs cancellation to work cleanly. So instead of one new button, the team built one new question.
The first screen of the cancel flow now asks, in plain text, "what's going on today?" A lightweight model reads the answer and routes it: a short break becomes an instant pause, a cost complaint becomes a discount offer, anything else drops straight into the same reason-and-confirm screen that's always been there.
The risk sitting inside that model is real. Get the routing wrong and a customer who typed "I want to cancel, this is too much" could get shown a pause option instead of an actual way out, and now they're stuck arguing with a screen instead of leaving. So the model only routes above a set confidence bar, checked against a labeled set of past answers. Anything it isn't sure about falls straight back to the old plain menu, reason, confirm, cancelled, no guessing forced on anyone. The cancel button, importantly, never disappears. The new question sits in front of it, never behind it.
That check costs a little time, a beat's pause while the model reads the answer, against a menu that used to load instantly. Solaun took that trade on purpose. A half-second delay is nothing next to routing someone into an argument with a screen when all they wanted was a week off.
In the next cycle, half of cancel sessions saw the old menu and half saw the new question, the same two ship dates. The old menu's reason-select screen still lost 43 percent of people who reached it. The new question's screen lost 17. Tickets mentioning wanting a break instead of a goodbye had been running about fifty a cycle before the test. On the new-question side that cycle, they dropped to six.
The thing I'd tell my past self: I didn't need a fourth data source. I needed to open the three I already had at the same time, on the same afternoon, instead of one at a time, whenever each team happened to remember it existed.
TRACE, so the ticket queue stops being the whole story
Not a way to prove Solaun was right to trust her gut. TRACE is what stops "a few complaints" and "a real gap in the product" from getting the same shrug, when only a cross-reference actually tells them apart.
Three things worth having ready when an interviewer pushes here. The team's first, cheaper idea was a static "skip this month" link, rejected because it only handles one of several reasons customers actually give. The AI-specific risk worth naming: the routing model could misread someone who genuinely wants to leave and steer them into a pause instead, so it only acts above a set confidence bar and always leaves the plain cancel menu one tap away. And the trade-off, taken on purpose: a half-second pause to read the answer, against a menu that used to load instantly, because trapping someone in an argument with a screen is worse than a half-second wait.
And if you want to be sure it really works, try it somewhere else
Same five letters, a building permit portal instead of a pantry box. This time the triangulated signal points at one missing check, not a missing feature.
Cobbleridge County's online building permit portal lets contractors file for inspections, additions, and re-roofs without a trip to the counter. Zoltan Amadife owns the intake form. Over ten weeks, he ran the same cross-reference Solaun did: search queries, form abandonment, and support tickets, lined up against the same flow.
The search log showed "add a co-applicant" searched most weeks, with nothing useful coming back, because the field was never labeled that way, it lived under a header that just said "additional parties." The form itself showed a drop-off spike at exactly that step, contractors filling out everything else and quitting there. And the tickets showed a cluster of a different shape: not "I can't find it," but "why did my permit get rejected two weeks later," because contractors who skipped the field entirely got a form that let them submit, then a rejection notice they didn't understand until they called.
The cause candidates weren't the same as Marrowbox's. One: contractors were simply careless, skipping a field they should have caught. Two: the label was just badly worded, and a plain rename would fix it. Three: the form let people submit incomplete applications it should have blocked at the door, and the real fix was catching the gap before submission, not after rejection. The first guess didn't survive a check: the same contractors filed clean permits on other counties' portals and only hit this wall on Cobbleridge's form. A three-week test of the second guess, a plain rename of the header, moved the search number but barely touched the drop-off or the ticket cluster. Naming something correctly doesn't help if the form still lets you submit without it.
So the fix wasn't a label change either. It's a lightweight check that reads the project type a contractor already entered, and when a co-applicant is legally required for that type, it flags the gap on the same screen, in plain words, before submission is even possible. Rejections for that reason dropped from thirty one a month to four.
Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to the one question: does the same shape show up in all three sources, for the same flow, at the same time?
Cost: no time to pull all three sources in full. Sample two weeks of each and check whether the shape still lines up before committing to the full pull.
The model got better, for real: say the routing model's intent classification gets far more accurate. The cross-reference still runs the same way, it just shrinks how often the fallback menu gets shown, not whether you still test the fix on the real number.
Where people run it wrong.
They read ticket volume alone and call a small number "not worth it," missing everyone who never wrote in.
They find one real signal and assume the other two agree, without checking whether the timing and the flow actually line up.
They ship the fix and call it done, trusting ticket sentiment instead of watching whether the actual abandonment number moved.
How to use it live. When an interviewer throws this at you cold, buy two seconds by asking one thing back: "do we know if this shows up in more than the ticket data, or is that all we have?" That question alone is usually exactly what a question shaped like this one is listening for.
Flashcards (tap any card to flip it)
Check yourself Score: 0 / 0
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
"What if the three signals line up by coincidence, not because they share a real cause?" Response: that's exactly what the evidence test is for. A coincidence doesn't move when you fix the thing you think is causing it. The drop from 43 to 17 only happens if the fix is actually resolving the shared cause behind all three.
From answering questions to owning outcomes.
A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.
- A live AI agent you actually shipped
- A launch decision you can defend under pressure
- An interview-ready portfolio, not more flashcards
More on Opportunity identification for AI
- #1 What characteristics make a workflow a good candidate for AI? List five.
- #2 Describe a method for finding AI opportunities inside an existing product without starting from the technology.
- #3 How do you distinguish a problem AI solves from a problem AI merely touches?
- #4 Rank these by AI suitability and justify: expense approval, contract review, invoice matching, hiring decisions.
- #5 Explain why high-volume, low-stakes, tolerant-of-error tasks are the best first targets.
- #6 Your support team handles 8,000 tickets a month. Structure a discovery process to find the AI opportunity.