A restaurant phone line is measured in person-minutes, not in calls. Calls offered in an hour times average handle time gives the minutes demanded; people able to pick up times sixty times their free share of the hour gives the minutes available. The gap between them is the lower bound of what cannot be answered at peak.
Why "calls per hour" is the wrong unit, and person-minutes is the right one
Ask an owner how many calls the restaurant can take and the answer comes back as a count. Check the same evening against the telephony export and the count turns out to describe nothing. Two calls arriving in the same minute do not need one faster person, they need two people. One enquiry about a wedding for forty guests eats what six table bookings would eat. A count treats all of that as equal, which is why it never matches what the shift felt.
The unit that does match is time held by a person.
Person-minutes — one person available for one minute. This is the unit in which phone capacity is measured, because two calls at once need two people, not one faster person.
Once the unit is minutes, both sides become measurable in the same currency: demand is minutes the callers ask for, supply is minutes your people can give. Subtracting one from the other is legal arithmetic only because both are minutes. Subtracting "calls" from "people" never was.
The count is an input, not an answer
Calls per hour still matters — as one of the two factors in demand. On its own it hides the second factor, and the second factor is the one that moves most between a Tuesday lunch and a Friday evening.
Three numbers to pull from your telephony: offered, answered, abandoned
Everything here is built from an export, not from memory. Three columns are enough to start.
Calls offered — every inbound call that reached the line, including those abandoned before pick-up. Taken from the telephony export, not from memory.
Abandoned call — a call offered and never answered because the caller hung up first.
The third number is calls answered: offered minus abandoned. Keep all three, because their ratio is the one measured fact on this page. Everything else is a calculation, and a calculation should be checked against a measurement whenever one exists.
| Number | Where it comes from | How often to refresh it |
|---|---|---|
| Calls offered per hour | Telephony or PBX export, hour by hour, not a daily total | Weekly, and after any change to the menu, the hours or the advertising |
| Calls answered per hour | Same export, same hour | Weekly |
| Abandoned calls per hour | Same export; if the column is missing, offered minus answered | Weekly |
| Average handle time | Same export, answered calls only | Monthly, and after any change to what the phone is used for |
| People able to pick up | The shift rota, not the payroll headcount | Per shift pattern |
| Free share of the hour | Shift observation, cross-checked against the point-of-sale timeline | Twice a year, and after any change to the service model |
If the export does not exist, that is the first task: an analytics setup is what turns a phone system into two usable columns. Once the columns exist, they belong where the shift can see them rather than in a monthly report — an operational dashboard is the difference between a number that changes behaviour and a number that decorates a slide. Which numbers an owner actually looks at has its own article.
Average handle time: how to measure it, and why a daily average lies
Average handle time is the mean length of an answered conversation, in minutes, over the calls you are modelling — not over the whole day.
The daily average lies in a predictable direction. A day contains long stretches where the phone rings twice an hour and the conversation wanders. It also contains the evening, where the same booking is taken in ninety seconds because the room is full and the caller can hear it. Averaging those together produces a number that describes neither.
Measure the peak hour with the peak hour's own calls
Take the hour you care about, on the days you care about, and average only those calls. If the export gives call duration but not wrap-up, add the wrap-up by observation: writing the booking into the book, walking to the pass, coming back. That time is held by the same person and belongs in the same number.
Split by call type before you average
A table for two, a delivery order, a supplier confirming a drop and a caller asking about parking have different lengths and different frequencies, and the mix changes by hour. Event enquiries are the extreme case: a wedding, a communion or a company table is the longest conversation of the peak hour and also the most valuable, which is why the queue of event enquiries deserves its own handling. If you can afford only one split, split events out and average the rest.
The demand formula: calls offered times average handle time
Demanded person-minutes per hour = Calls offered per hour × Average handle time (minutes per call)
Calls offered per hour— inbound calls that reached the line during that hour, answered or not, calls per hour;Average handle time— mean length of one handled conversation including wrap-up, minutes per call.
The units multiply out cleanly: calls per hour times minutes per call gives minutes per hour, which is person-minutes of demand.
Worked example — example numbers, not a published norm. Take a Friday between 18:00 and 19:00 with 34 calls offered and an average handle time of 2.4 minutes. Demand is 34 × 2.4 = 81.6 person-minutes for that hour.
Read that back: the callers asked for eighty-one and a half minutes of a person's attention inside sixty minutes of clock time. Nothing about staffing has been said yet, and the number already tells you the problem is not the handset.
The supply formula: how many person-minutes you actually have in that hour
Available person-minutes per hour = People able to pick up × 60 × Free share of the hour
People able to pick up— how many people physically can take a call during that hour, persons;60— minutes in an hour, minutes per hour;Free share of the hour— the fraction of that hour a person can really give to the phone, a dimensionless decimal between 0 and 1.
Persons times minutes per hour times a dimensionless share gives person-minutes per hour — the same unit as demand, which is the only reason the two can be subtracted.
Free share of the hour — the fraction of a working hour a person can actually spend on the phone, after seating guests, taking payment and answering the room.
The free share is where estimates go wrong, and they go wrong upward. The person by the phone is also the person seating a party of six, running a card terminal and answering the guest at the counter who is standing in front of them and therefore wins. How much of an hour is really left is the same question as how much a working hour of that person produces, which is what revenue per labour hour measures. Take the free share from an observed shift, not from a wish.
Worked example continued: two people able to pick up, observed free share 0.45. Supply is 2 × 60 × 0.45 = 54 person-minutes.
The gap — and why it is a LOWER bound, not the real loss
Lower bound of unanswerable share % = max(0; Demanded − Available) ÷ Demanded × 100
DemandedandAvailable— results of the two formulas above, for one and the same hour, person-minutes per hour;max(0; …)— the gap is never negative: a surplus of minutes is not a negative loss.
Person-minutes divided by person-minutes is dimensionless; times 100 it is a percentage.
That percentage is a floor. It is derived from an hour treated as one smooth block, and an hour is not smooth. Real calls arrive in clumps, and a clump loses calls that the hourly balance says should have been answered. The true share lost is therefore always greater than or equal to the calculated one, which is why "lower bound" stands in the name of the formula rather than in a footnote.
When the formula returns zero, that is not "nothing is lost"
If available minutes equal or exceed demanded minutes, the expression inside max goes negative and the answer is 0 %. Read it as "the hourly balance is not the binding constraint", not as "every call is answered". The next section is the reason for that wording.
Check the calculation against the measurement
Answered share % = Calls answered ÷ Calls offered × 100
Calls answered— calls that were picked up, calls per hour;Calls offered— all calls that reached the line, calls per hour.
Calls divided by calls is dimensionless; times 100 it is a percentage. This one is a measurement rather than a model — the telephony counts it for you — and its job here is to audit the estimate above.
If a measured loss ever comes out below the calculated floor, one of the inputs is wrong, and the free share is the usual suspect.
What the missed calls cost in money is deliberately not here. That is a separate formula and it lives in the article on the cost of missed calls. This page counts pieces and minutes; that one converts them into currency.
Concurrency: why the hour can balance and the phone still rings out
Concurrency — the number of calls arriving inside the same short interval. It is the reason an hour can balance on paper and still lose calls.
Change the example: three people able to pick up, free share 0.55. Supply is 3 × 60 × 0.55 = 99 person-minutes against the same demand of 81.6, so the hour balances with 17.4 minutes to spare and the gap formula returns 0 %.
Now zoom into a five-minute window inside that hour and let six calls land in it, which is entirely ordinary at 18:30. Those six ask for 6 × 2.4 = 14.4 person-minutes. Three people can give 3 × 5 × 0.55 = 8.25 person-minutes in five minutes, enough for 3.4 calls. At least two callers wait, and waiting callers become abandoned callers.
The lesson is not "use a smaller interval". It is that an hourly model cannot see clumping by construction, and a page that pretended otherwise would be selling false precision. A full queueing model would need assumptions about how calls are distributed in time, and a restaurant cannot produce those from an export. Inventing them would be inventing numbers.
What you can do without any of that: stop treating the phone as the only queue. Enquiries arrive on the phone, in messages, on the portals and at the counter at once, and the person answering serves all of them out of the same sixty minutes. Merging them into one queue instead of five does not shorten the conversations, but it stops one person switching between four inboxes during the exact hour they have least to spare.
The kitchen peak and the line peak are different hours — how to compare them
Almost every rota is built around the kitchen peak, because that is the peak everybody can see: tickets on the pass, the room full, the noise. The line peak is invisible, and it usually sits earlier — people call before they come.
Compare them with a table you fill from two exports rather than from an opinion. Put the share of the day's calls by hour in one column and the share of the day's covers by hour in the other. If both peak in the same hour, staffing the kitchen peak also staffs the line. If they peak an hour apart — the common case — then the hour you staff most heavily is not the hour the phone is busiest, and the gap calculated above is the arithmetic consequence.
Both columns move with the calendar: a match day, a school holiday, a long weekend and a communion season shift covers and calls at once. Building that side properly is a separate discipline and it belongs to demand forecasting. This page takes the calendar from there and does not build a second forecast of its own.
What to do with the gap: four levers, cheapest first
The gap is minutes. A lever either reduces the minutes demanded or increases the minutes available; nothing else is a lever.
| Lever | What it changes: demand or supply | What it does not solve |
|---|---|---|
| Shorten the handle time — a written answer to the five most repeated enquiries, the menu and the parking on the page | Demand: fewer minutes per call | Nothing, if the calls were never repetitive; measure the call mix first |
| Move part of the flow off the line — booking form, messages, confirmations | Demand: fewer calls offered in that hour | The caller who only ever uses the phone; that share is yours to measure, not to assume |
| Add a person to the hour, or protect the free share of the person already there | Supply: more person-minutes | Concurrency at the five-minute scale, if the addition is small |
| Answer in parallel with a system | Supply: person-minutes that are not a person's | Anything requiring judgement — price, contract, promise, conflict |
The order is deliberate: the first two are free or nearly free and reduce demand, and reducing demand is cheaper than buying supply. Adding a person is the honest expensive answer, and sometimes the right one.
Where a system helps, and where it is plain arithmetic
Everything above this line is arithmetic — two multiplications, a subtraction and a division, done on your own export. No model, no prediction and no artificial intelligence is involved in producing the gap, and any tool claiming to have "calculated your losses with AI" has done the same four operations.
A system genuinely changes the supply side only at the fourth lever. An AI receptionist adds capacity that is not a person's time, which is why it does not compete for the free share of the hour. What such a system can and cannot close is a question with a precise answer, and it belongs to the page on what a phone system answers and what a person must rather than to this one. The third lever has its own tools: automatic confirmations and reminders remove calls that would otherwise be made, and messenger channels move part of the flow into a form that need not be handled inside the same sixty minutes.
What this arithmetic does not show: the guest who never calls back
Every number here comes from calls that reached your line. The most expensive part of the peak hour never reaches it.
A caller who gets a busy tone, or eight rings and nothing, usually does not call back. They call the next restaurant, and your export records nothing at all — not an abandoned call, not an offered one. The silence is invisible to telephony by construction, and no formula here can recover it.
There is no official statistic to fall back on either, and that is not a guess. The public Eurostat dataset catalogue, read on 27.08.2026, carries nothing on inbound call volume, missed calls or answer time: the only telephony entries in it are internet telephony and video calls by users, fixed and mobile penetration rates, and affordability of a telephone in households. On the Polish side, the communications section of the national statistical office lists two publications — telecommunications for 2024 and an older one for 2015 — and both are operator statistics for the country, not a record of how many calls an individual business receives or misses. So there is no benchmark to compare yourself against, and the only honest number is the one you calculate from your own export.
Two things follow. Do not treat a small calculated gap as proof of health; treat it as proof that the hourly balance is not your binding problem. And when the gap is large, the case for acting is stronger than the arithmetic says, not weaker.
What one booking is worth by the channel it arrived through is the next question, and it has its own page and its own denominator. This page stops at pieces and minutes on purpose.
Frequently asked questions
Why is phone capacity measured in minutes and not in calls?
Because two calls arriving at the same moment need two people, and a count cannot express that. A count also treats a ninety-second table booking and a twelve-minute wedding enquiry as the same event. Minutes held by a person express both, and they let demand and supply be subtracted from each other, which counts never allowed.
Where do I get the number of calls offered?
From the telephony or PBX export, hour by hour. Calls offered must include the ones nobody picked up: if your export shows only answered calls, the number is not calls offered, and using it will make the gap look smaller than it is. If the system does not export at all, that is the first thing to fix, before any calculation here can be run.
How do I measure average handle time honestly?
Average only the answered calls, only from the hour you are modelling, and add the wrap-up time you can observe on the shift — writing the booking down, walking away, coming back. Then split event enquiries out and average them separately, because one of them can be longer than six ordinary bookings and a single one distorts a small sample.
Why is the calculated loss a lower bound and not the real number?
Because the formula treats an hour as one smooth block of minutes, and calls do not arrive smoothly. Any clump inside the hour loses callers that the hourly balance says could have been served. The real loss is therefore always greater than or equal to the calculated one, and a result of zero means the hourly balance is not your binding constraint, not that nothing is being lost.
My hour balances but we still miss calls — what is happening?
Concurrency. Zoom into a five-minute window and run the same two formulas on it: six calls at 2.4 minutes each ask for 14.4 person-minutes, while three people at a free share of 0.55 can give 8.25 in that window. The hour has spare minutes and the window does not, and the callers are in the window.
Is the phone peak the same hour as the kitchen peak?
Usually not, and usually the phone peaks earlier, because people call before they arrive. Put the share of calls by hour and the share of covers by hour side by side and read the two peaks off the table. If they sit an hour apart, a shift built around the kitchen peak is structurally understaffed for the line peak, and the calculated gap is the arithmetic consequence.
Which part of this is artificial intelligence and which is plain arithmetic?
The whole calculation is plain arithmetic on your own export: two multiplications, a subtraction and a division. Nothing here predicts anything and nothing here needs a model. A system enters only at the fourth lever, where it answers in parallel and adds capacity that is not a person's time. Any claim that the loss figure itself required artificial intelligence is a claim about marketing, not about the arithmetic.
Start with one week of telephony export and one column of average handle time — that is enough to calculate the gap for your own peak hour, and until it exists there is nothing to decide. The restaurant section collects the pages that use those two columns, and the overview of what can be automated in a restaurant is a reasonable next read if the phone turns out not to be your narrowest hour.