Spanish-speaking customers — bilingual coverage that doesn't lose the call

Coggleby Team··5 min read

Spanish-speaking customers — bilingual coverage that doesn't lose the call

Independent auto-repair shops in much of the US handle a meaningful share of inbound calls from Spanish-speaking customers — particularly in California, Texas, Florida, Arizona, the Carolinas, and a growing list of metros where Spanish-first households are a substantial portion of the population (TODO(confirm): https://www.census.gov/library/stories/2024/06/spanish-spoken-at-home.html). For a shop that doesn't have a bilingual service advisor on every shift, the inbound experience for those callers is often where the relationship breaks.

This post is about the small design choices in a phone-intake flow that determine whether a Spanish-speaking caller stays on the line, and what an AI front desk can do that an IVR ("press 1 for English") usually can't.

Why "press 1 for English" fails

The standard bilingual phone menu starts with a language gate: a recording in English or Spanish that asks the caller to press a digit for their language. The intent is reasonable. The execution loses calls for three reasons:

  • Caller fatigue. A frustrated caller who has already tried two other shops does not want to listen to a menu. They hang up.
  • Language assumption. The recording usually plays in English first. A Spanish-first caller has to wait through a sentence they don't understand before getting to the part that's for them.
  • No graceful fallback. If the caller presses 2 for Spanish and there's no Spanish-speaking advisor available, they're either routed back to English or dropped into voicemail. Both confirm that they're not the customer the shop is designed for.

The result is a quietly higher hang-up rate for Spanish-speaking callers than for English-speaking ones — a gap that doesn't show up in standard call-volume metrics because the callers who hung up never identified themselves.

What language detection does instead

An AI front desk skips the menu. When the call connects, the agent says a short bilingual greeting — something like "Hi, gracias por llamar a [shop name], how can I help you today?" — and then listens to the first thing the caller says. The model identifies the language of the first complete utterance and continues the conversation in that language for the rest of the call.

This works because language detection on a complete spoken phrase is reliable enough for practical use — multi-language speech-to-text models handle the common case (a caller speaking one consistent language) well, and the intake script is structured so that the language choice is locked in after the first response.

Capturing the right fields in Spanish

The intake fields don't change based on language. The phrasing does. A literal translation of an English intake script ("What is the year of your vehicle?") sounds robotic in Spanish. The intake should use natural conversational Spanish — "¿De qué año es el carro?" — and accept regional variations (carro, coche, auto).

Numbers are the trickiest field. Spanish-speaking callers will sometimes give a year as a four-digit number ("dos mil diecisiete") and sometimes as a two-digit shorthand ("diecisiete"). The model handles both, but the intake transcript stored for the advisor should always be the four-digit canonical form so the AutoLeap RO is clean.

What "bilingual" doesn't mean

Bilingual phone coverage doesn't substitute for a bilingual service advisor. A Spanish-speaking caller will eventually need to talk to a human — to confirm the estimate, schedule the appointment, hand off the car. The intake's job is to capture enough structured data that the callback can be productive even if the service advisor and the customer speak different first languages.

The structured intake transcript is the bridge. The advisor sees the request in English (or whatever the shop's working language is) with the original Spanish utterances preserved as quoted notes. The callback might still happen through a bilingual technician or a translation app, but the shop is no longer flying blind into the call.

A note on regional Spanish

US Spanish is not monolithic. Mexican, Caribbean, Central American, and South American varieties differ in vocabulary, particularly for vehicle terms. "Llantas" vs "neumáticos" for tires. "Cofre" vs "capó" for the hood. The intake script doesn't need to handle every variation, but it should accept the most common ones without forcing the caller to rephrase.

The practical heuristic: build the intake against the variety most common in the shop's metro area, and accept the most common alternates. A shop in San Antonio sees different patterns than a shop in Miami.

What this changes for the shop

The compound effect of removing the language gate is straightforward — more Spanish-speaking callers stay on the line long enough to provide intake data. The shop's pipeline expands without any marketing change. The service advisor sees more inbound estimate requests, of which some convert to ROs, of which the existing close rates apply.

The shop's reputation in the Spanish-speaking customer base also shifts. Word of mouth in close-knit communities is fast, and "they answered in Spanish without making me press a number" is a small but specific reputation point that pulls in more of the same callers.


Coggleby answers calls in English or Spanish without an IVR menu. Start your shop at coggleby.com.

Keep reading