Intelligence
What a caller asks for is worth keeping, even when the answer is no. Every call carries more than how it ended — what was actually asked for, what wasn’t there, and what kind of question it even was. This is that layer, kept in a form you can query rather than left to disappear once the line goes quiet.
A request that came back “not on the
menu” doesn’t disappear into a decline.
When a caller asks for an item, a size, or a modifier that isn’t on the current menu, what was actually asked for is kept as its own fact, tied to the call it came from. That’s different from a note a busy host might half-remember and never write down — it’s a specific request, kept exactly as asked, not folded into an undifferentiated count that says something was unavailable somewhere, sometime.
RESOLUTION · [NOT ON THE MENU · OR · NOT CURRENTLY AVAILABLE]
CALL · [LINKED BACK TO THE CALL IT CAME FROM]
EVERY BRACKET STAYS A BRACKET — A SHAPE, NOT A CLAIM ABOUT ANY SPECIFIC REAL REQUEST
The same applies in reverse: when a caller asks whether something is available and the answer is yes, that’s a real signal too — distinct from a request that came back empty, and kept as its own fact. None of this means much from a single call on its own. One caller asking for a topping that isn’t there is just a moment. The same request showing up from several different callers, checked against a date range you actually choose, is a pattern worth looking at — and the gap between those two things is exactly what this page exists to close.
The taxonomy is real and fixed.
The counts are yours, not this page’s.
A large share of what a restaurant’s phone line handles was never going to be an order in the first place. Each call is recorded as what it actually was, never lumped into a single catch-all bucket — the same categorization the call itself used to answer the question live. Here, the same categories are what you’d filter or count by afterward, across many calls instead of one.
A DASH, NOT A NUMBER — WHAT ANY CATEGORY ADDS UP TO IS SPECIFIC TO YOUR OWN CALLS, AND ISN’T SOMETHING THIS PAGE CAN HONESTLY SHOW IN THE ABSTRACT
Not one fixed report.
A set of questions you put to it.
The same underlying calls get filtered differently depending on what you’re actually trying to find out — whether lunch produces more price questions than dinner, or whether a specific unavailable item keeps coming up. A time range — today, this week, or a stretch you pick. Ordering calls against non-order calls, and which kind of non-order question. A specific item, size, or modifier that keeps showing up as asked-and-missing. Fulfillment type — pickup, delivery, or scheduled.
INPUTS, NOT A CHART OF RESULTS — WHAT COMES BACK DEPENDS ENTIRELY ON WHAT YOU ASK; THERE’S NO SINGLE DEFAULT VIEW PRESENTED AS THE RESULT
Same calls, two lenses.
The day’s totals — sales, order counts, how calls split between the ones that became orders and the ones that didn’t — live on console, tied to that day’s close. This page doesn’t duplicate any of that; it’s the layer underneath, organized around what was asked rather than what was billed.
Nothing here forecasts what’s coming. It reports what already happened on real calls — no projection of next week’s volume, no comparison to a benchmark restaurant, no claim about what a pattern does next. If a specific request keeps showing up, that’s a fact about calls that already happened, not a prediction about the ones that haven’t.
A specific, checkable list —
not an abstract score.
An owner wants to know whether a specific unavailable topping is a one-off or an actual pattern. They search for the item by name, set the range to the last month, and filter to ordering calls only. What comes back is every call where that exact item was asked for and wasn’t on the menu at the time, each one linked back to the actual call it came from — not a single headline figure standing in for all of them, and not a percentage measured against total call volume, since neither one exists to show honestly. What the owner has afterward is a specific, checkable list: how many times, and which calls, not an abstract score with nothing underneath it.
What people ask before they trust a pattern
Does this predict next week's demand?
No. Every figure here describes calls that already happened, never a projection of what’s coming.
Can I see what a specific caller asked?
Yes — tied back to the actual call, under the same role-based access as everything else on this side of the screen.
What counts as “missing” if the request was garbled?
A request too unclear for the system to actually resolve isn’t silently counted as a specific miss. Only a genuinely determined “not on the menu” gets kept as one.
How is this different from just reading transcripts?
A transcript is one call’s own record, read one at a time. This is the same calls looked at together, filtered by what was actually asked.
Does looking at a pattern here change anything on the menu?
No. This page only reads what already happened on real calls. Changing what’s actually on the menu happens on the menu page itself, not here.
No forecasting. No comparison to other restaurants — what shows here is built entirely from this restaurant’s own calls. No specific number is shown on this page in the abstract, because there isn’t one honest to publish without your own call volume behind it — which this page doesn’t have and won’t guess at. And none of this replaces reading an actual transcript when something needs a closer look — it’s a way to notice a pattern worth checking, not a substitute for checking it.
RELATED READING
Owner console
The dashboard: tonight at a glance, analytics, menu, team, closeout.
OPEN →PLATE Nº 009Questions
Hours, parking, gluten-free — answered from what you actually published, never guessed.
OPEN →PLATE Nº 034Demand visibility
Every ring is demand data — see the curve, staff the curve.
OPEN →Find out what your own line has been asked.
Request access to start asking questions of your own calls.