Arquitectura de una recepcionista IA para mecánicos en Rosario: triaje sin diagnosticar

#ai #voiceai #architecture #saas

Cuando una recepcionista IA atiende llamadas para un taller mecánico, el reto no es "sonar inteligente". El reto es clasificar bien la intención, capturar datos útiles y no inventar diagnósticos.

Tomé como referencia la página local de VoiceFleet para mecánicos en Rosario y la convertí en una versión más técnica para Dev.to. La fuente interna usada para esa página es un merge local de directorio del 2026-06-25: 63 registros de mecánicos en Rosario, con 30 registros con teléfono y 12 con sitio web. No uso esos datos como promesa comercial; sirven para diseñar un flujo local, no genérico.

1. El problema de producto

En un taller mecánico, una llamada perdida puede ser:

un turno para mantenimiento,
una consulta por repuestos,
un auto que no arranca,
una urgencia de traslado,
una persona preguntando horarios,
o alguien que necesita hablar con un mecánico antes de decidir.

El sistema no debería contestar todo como si fuera FAQ. Tampoco debería diagnosticar por teléfono. El objetivo correcto es más simple: crear una cola priorizada para que el equipo humano responda con contexto.

2. Modelo de intención mínimo

Un flujo seguro empieza con pocas categorías:

{
  "intent": "booking | fault_description | parts | pricing_question | opening_hours | callback | unknown",
  "urgency": "emergency | same_day | this_week | routine",
  "vehicle_can_move": true,
  "needs_human_confirmation": true
}

La parte importante no es el JSON. Es aceptar que la IA no necesita resolver toda la llamada. Necesita reducir la ambigüedad para el humano.

3. Preguntas que sí conviene hacer

Para mecánicos en Rosario, el flujo que mejor funciona es algo así:

Saludar como el taller local, no como un call center.
Preguntar en una frase abierta: "¿En qué podemos ayudarte?"
Capturar modelo del vehículo, síntoma, ubicación y si el auto puede circular.
Preguntar si la persona busca turno, diagnóstico, repuesto o devolución de llamada.
Marcar urgencia: emergencia, mismo día, esta semana o rutina.
Enviar resumen al canal interno del negocio.

La IA puede hacer esto de forma consistente sin prometer precios, disponibilidad exacta ni diagnósticos.

4. Guardrails: lo que la IA no debe hacer

Este tipo de vertical necesita límites explícitos:

No diagnosticar fallas mecánicas.
No prometer que una reparación es posible.
No confirmar precio final.
No decir que un repuesto está disponible si no hay integración real con inventario.
No reemplazar instrucciones de seguridad si el vehículo está en una situación peligrosa.

En esos casos, el resultado correcto no es una respuesta "creativa". Es una escalación clara.

5. Resumen útil para el taller

El output debería ser corto y operativo:

{
  "caller_name": "...",
  "phone": "...",
  "vehicle": "...",
  "symptom": "...",
  "location_or_area": "...",
  "can_vehicle_move": "yes | no | unknown",
  "requested_action": "booking | diagnosis | parts | callback",
  "urgency": "same_day",
  "recommended_next_step": "Call back with available inspection slots"
}

Esto evita que el equipo tenga que escuchar una grabación completa antes de decidir qué llamada devolver primero.

6. Por qué el contexto local importa

Un flujo para Rosario no debería ser sólo una plantilla traducida. El contexto local cambia las preguntas: zona, disponibilidad, cercanía, horarios, si el vehículo puede circular, y si la consulta viene de alguien comparando talleres desde el mapa.

La IA no necesita saber "todo sobre Rosario". Necesita saber lo suficiente para no sonar como una demo genérica y para capturar los datos que el taller realmente usa.