Arquitectura de una recepcionista IA para restaurantes en Mendoza: intake, urgencia y handoff

Cuando un restaurante en Mendoza pierde una llamada, el problema técnico no es “poner un bot”. El problema real es diseñar un flujo que capture intención, urgencia y contexto sin prometer nada que el equipo humano todavía no confirmó.

Ese matiz importa. Una recepcionista IA para restaurantes no debería comportarse como un IVR rígido ni como un vendedor demasiado seguro. Tiene que hacer pocas cosas, hacerlas bien y dejar un rastro claro para que la persona correcta pueda responder.

Este es el enfoque de arquitectura que usamos en VoiceFleet para un flujo local como restaurantes en Mendoza.

1. Separar “contestar” de “resolver”

La tentación al diseñar agentes de voz es intentar resolver todo en la llamada:

• tomar reservas finales,
• cambiar horarios,
• confirmar disponibilidad,
• responder sobre precios,
• derivar pedidos complejos,
• manejar reclamos.

En producción, ese enfoque se rompe rápido porque muchos restaurantes tienen reglas cambiantes: mesas bloqueadas, eventos privados, horarios especiales, capacidad distinta por turno o decisiones que dependen del encargado.

La arquitectura más segura es separar dos responsabilidades:

IA = capturar intención + contexto + urgencia
Equipo humano = confirmar, decidir y cerrar

La IA no necesita saber todo. Necesita entregar un resumen accionable.

2. Modelo de datos mínimo para una llamada

Para restaurantes, el objeto de salida debería ser simple y estable. Algo así:

{
  "caller_name": "string | null",
  "phone": "string",
  "intent": "reservation | change | cancellation | takeaway | hours | other",
  "party_size": "number | null",
  "preferred_date": "string | null",
  "preferred_time": "string | null",
  "area_or_branch": "string | null",
  "dietary_notes": "string | null",
  "urgency": "same_day | this_week | routine | unknown",
  "needs_human_confirmation": true,
  "summary": "string"
}

Lo importante no es que el esquema sea grande. Lo importante es que sea confiable. Un resumen largo sin campos estructurados es difícil de ordenar. Un esquema demasiado ambicioso termina inventando precisión.

3. Clasificar intención antes de preguntar demasiado

Una mala llamada automatizada parece un formulario hablado. Una buena llamada empieza abierta y recién después reduce el espacio de búsqueda.

Ejemplo:

“Hola, te atiende el asistente del restaurante. ¿En qué podemos ayudarte?”

Después de esa respuesta, el agente decide si está frente a una reserva, una modificación, una consulta de horarios, un pedido para llevar o algo que necesita derivación.

Eso cambia las preguntas siguientes. Para una reserva, tiene sentido pedir fecha, hora y cantidad de personas. Para una consulta general, quizá alcanza con nombre, teléfono y motivo.

4. No tratar todas las llamadas igual

Un flujo útil marca prioridad. No por dramatismo, sino para que el equipo humano pueda devolver llamadas en orden.

Una clasificación sencilla suele alcanzar:

• same_day: algo para hoy o en una ventana muy cercana.
• this_week: reserva o cambio con margen.
• routine: consulta sin presión inmediata.
• unknown: falta información o hay ambigüedad.

En restaurantes, “mismo día” merece aparecer arriba en la cola. Pero la IA no debería prometer mesa disponible si no está conectada a una fuente confiable de disponibilidad.

5. Diseñar handoff, no sólo conversación

El handoff es el producto. Si el equipo recibe un texto vago como “cliente llamó por reserva”, el sistema no ayuda mucho.

Un buen handoff debería verse así:

Nueva llamada no atendida
Motivo: reserva
Nombre: Sofía
Teléfono: +54 ...
Fecha solicitada: viernes
Horario: cerca de las 21:00
Personas: 4
Notas: una persona vegetariana
Urgencia: esta semana
Acción sugerida: confirmar disponibilidad y devolver llamada

Ese resumen puede ir por email, CRM, panel interno o un canal operativo. La integración exacta importa menos que la consistencia del formato.

6. Poner límites explícitos al agente

Para este tipo de flujo, las reglas de seguridad son tan importantes como el prompt.

Ejemplos de límites sanos:

• No confirmar reservas si no hay integración con disponibilidad real.
• No inventar precios, promociones ni horarios especiales.
• No discutir reclamos complejos; derivarlos.
• No capturar datos innecesarios.
• No hacerse pasar por una persona humana.
• Siempre dejar claro cuándo alguien del equipo debe confirmar.

Esto reduce el riesgo operativo y mejora la confianza del negocio.

7. Localizar sin sobrecomplicar

Un restaurante en Mendoza no necesita el mismo flujo que una clínica dental o un estudio contable. Tampoco necesita un agente “global” que ignore contexto local.

La localización práctica no es llenar el prompt de datos. Es ajustar ejemplos, vocabulario y campos esperados:

• reservas por fecha y horario,
• cantidad de personas,
• zona o sede,
• notas alimentarias,
• llamadas de último momento,
• derivación a encargado cuando haga falta.

Eso hace que el agente suene menos genérico y que el resumen sea más útil.

Conclusión

La mejor recepcionista IA para restaurantes no es la que habla más. Es la que contesta cuando nadie pudo atender, entiende lo suficiente, no promete de más y entrega un handoff claro.

Para un mercado local como Mendoza, el diseño ganador es bastante sobrio:

contestar rápido → entender intención → capturar campos clave → marcar urgencia → derivar con contexto

Esa arquitectura deja al equipo humano en control, pero elimina el peor caso: una llamada valiosa que desaparece sin registro.