24/7 phone monitoring for restaurants is a per-call record, not a tally

The instrumentation gap

A typical “phone monitoring” dashboard for a restaurant shows three counters and one chart. Calls in. Calls answered. Calls missed. A 24-hour timeline with little spikes at lunch and dinner. The owner glances at it once a day, sees the missed-call counter, and forms a vague impression that things are okay or not okay. Almost nothing about a real shift can be recovered from that screen.

The gap is not bandwidth, it is fidelity. The dashboard is counting events. To run a phone line, an operator needs to look at events. Per call, they need to know who called, what they asked for, in what words, whether the system understood, what modifier slots were filled, and what landed on the kitchen printer. None of that is visible from a counter, because none of that is in a counter.

The honest framing: counting calls is to monitoring what counting receipts is to running a restaurant. It tells you something happened. It does not tell you what.

The smallest useful per-call record

Five fields. None of them is optional, because each one compensates for what is missing in the others.

• Channel separated audio. The caller on one channel, the agent on the other, recorded as stereo. Mono recordings drop the moment of overlap, which is the most common single point of failure on a restaurant call.
• A per-channel amplitude envelope. Sampled at 60 Hz, smoothed with separate attack and release constants so a phrase ends visibly. Lets the operator see silence, speech, and overlap without listening to the audio.
• Word level timestamps. Multichannel speech-to-text, grouped into captions on pause and punctuation boundaries (the current thresholds are 3.2 s max segment, 0.55 s pause gap, 75 character max line).
• Ontology-mapped intent. The matched POS item ID, modifier slots filled, and free-form additions normalized to canonical modifier names. This is the single field that turns a transcript into something a restaurant can act on.
• POS commit or transfer reason. Either the kitchen ticket fired (with total and prep time) or the call was handed to a manager with a reason attached (catering, complaint, novel item, payment failure).

Skip any one of those and the record stops being auditable. Drop channel separation and overlap is invisible. Drop the envelope and you have to listen to find a 9 second silence. Drop word timestamps and you cannot reconcile the captions with the kitchen ticket. Drop ontology mapping and you have a transcript that does not say which dish the caller asked for. Drop the POS commit and you cannot tell whether the order actually shipped.

The data shape, as it exists in this repo

The reference call shipped with this site, used to render the live waveform on the home page, is the same record shape PieLine writes for production calls. It is a single TypeScript file. The excerpt below is real, with the envelope arrays elided for length.

Every field on that record is observable from outside the call. The 60 Hz sample rate is a deliberate choice: high enough to show pauses and overlap, low enough that 102 seconds of stereo produces about 12 KB of envelope data per call. Thespeakerfield is not a guess, it is the channel index from the original stereo wav: customer is channel 0, agent is channel 1.

The pipeline, end to end

Audio comes in on two channels. A single hub on PieLine's side is doing all of the work that follows: recording the stereo wav, calling Deepgram multichannel for word level timestamps, walking the raw samples for the 60 Hz envelope, mapping the extracted intent against the restaurant's menu ontology, and committing the resulting ticket to the POS or routing to a human. The artifacts on the right are written as the call is happening, not after.

There is no second “monitoring agent” on the line. The audio is already there because the agent needs it to hear the caller. The transcription is already there because the dialogue manager needs the words. The ontology lookup is already there because the POS commit needs an item ID. Keeping those artifacts and indexing them is what turns the call into a monitorable event.

What it looks like when the script runs

The build script that produced the reference record is committed to the repo at scripts/build-voice-activity-data.py. It is 118 lines of Python: HTTP POST to Deepgram, two passes over the wav for the envelope, group the words into captions on punctuation boundaries, write the TypeScript file. Running it on the Denny's reference call produces the log below. The same call into a production restaurant produces the same artifacts.

Generic call tracking versus an answering-system record

A restaurant operator evaluating a “phone monitoring” product is usually being shown one of two things: a call tracking dashboard (CallRail, CallScaler, Imagicle, et al.) or an answering service that publishes the same dashboard with answer-rate added. Both leave most of the per-call record unwritten. The table below compares what each layer can see.

The two columns are not graded on the same axis. Call tracking is a strong product for marketing attribution. It is not the right product for a restaurant phone line, because the marketing source of an inbound order is roughly irrelevant compared to what the caller asked for and whether the kitchen got it. The record that matters lives one layer below the carrier, in the system the caller is talking to.

The 24/7 part is non-trivial because the leak hides at 03:14

For an independent restaurant taking phone orders, the bucket that quietly bleeds revenue is not lunch. Lunch is loud and visible: missed calls during the rush get noticed. The bucket that bleeds is everything outside business hours and everything during shift changes. The 21:30 caller on a Sunday who hits voicemail and never calls back. The 14:45 caller during the between-shifts gap when one cashier left and the next has not clocked in. The 03:14 caller, which sounds absurd until you build a 24-hour phone product and find out how many of those there are on a delivery menu.

Continuous coverage means there is no “outside business hours” in the data. Every ring at every hour produces the same record, written to the same file, with the same captions and the same envelope. After-hours calls either become orders (the kitchen sees them in the queue when it opens) or transfers with a reason attached (caller asked for catering, novel item, etc.). The point is that they stop disappearing. The bucket gets bottomed out because the bucket has bottom-and-sides made of data.

What the operator does with it on a Monday morning

Three concrete uses, in order of frequency.

Audit a single call. A customer says they ordered a half-and-half and got a plain. The operator opens the record by phone number and timestamp, reads the captions, sees the modifier slots that were filled (and not filled), and knows within thirty seconds whether the caller said the wrong thing, the agent heard the wrong thing, or the kitchen made the wrong thing. All three are recoverable outcomes; no record means none of them are.

Find anomalous calls without listening. The envelope is a 60 Hz time series; long runs of near-zero on both channels mean dead air, which usually means an unhappy caller. The operator filters the day's calls by “mean dead-air over five seconds” and gets a short list to review. They never had to scrub through a 102 second recording to find the silent six seconds in the middle.

Reconcile captions with kitchen tickets. Captions show the spoken item names. The POS commit shows the line items. They line up by timestamp. When they disagree (caller said one thing, ticket says another) the disagreement is the bug, and the bug is now a thing you can hand to the menu configurator instead of a vague “our AI sometimes mishears.”