Bandwidth. A traditional telephone call is narrowband: 8 kHz sampling, roughly 300 Hz to 3.4 kHz of usable audio, compressed by a codec designed in the 1970s. Recognition accuracy measured on studio-quality audio does not survive the trip. If the system will answer phone calls, evaluate it on phone-quality audio from the first week, not on clean recordings from a laptop microphone.
Packet loss and jitter. Real calls drop packets. A jitter buffer smooths that out and costs latency to do it, which is a direct trade against the budget above. Deep buffers sound robust and feel slow; shallow ones feel responsive and stutter on a bad connection. There is no setting that is right for every route.
The rest of the telephony stack. DTMF tones for the cases where speech is the wrong input — card numbers, menu selections. Warm transfer that carries context to the human rather than making the caller start again. Call recording with its own consent and retention rules. Hold, conference and disconnection semantics. None of this is AI work, and it is usually where the integration time goes.
Accents, noise and vocabulary. Recognition quality is not uniform across speakers, and published research has repeatedly found accuracy gaps between accent and dialect groups. Treat that as a design input rather than an unfortunate footnote: build the evaluation set from your actual callers, including the accents and the background noise your service really encounters, and check performance per group rather than in aggregate. Domain vocabulary — product names, drug names, reference formats — is worth handling explicitly with biasing lists or a post-recognition correction step, because these are precisely the tokens a general model has never seen and the caller most needs to be got right.