Alcance estrecho
Uno o dos motivos de llamada con resultado verificable.
Plan de implantación
Cómo implementar una recepcionista IA
Para implementar una recepcionista IA, empieza por una tarea concreta, conecta solo las herramientas necesarias y comprueba el resultado antes de abrir todas las llamadas. Este plan incluye un ejemplo de taller, casos de prueba y un cálculo para decidir si el piloto compensa.
Salida humana
Transferencia o devolución cuando el flujo no encaja.
Métricas antes
Éxito, errores y criterios de pausa definidos antes del tráfico real.
01Definir alcance y límites
→
02Probar un piloto reversible
→
03Operar, medir y ampliar
Paso 1
Mapea llamadas, datos y responsables
Registra motivos, horarios, resultados y llamadas perdidas. Elige un flujo frecuente y estable. Identifica qué datos son necesarios, de dónde proceden, dónde se escriben y quién responde cuando falta información.
Define lo que la IA no puede hacer. Incluye consejo profesional, excepciones de precio, reclamaciones, urgencias y cualquier dato que no deba recogerse por teléfono. La ruta humana forma parte del diseño, no es un parche.
Por ejemplo, un taller puede empezar recogiendo solicitudes de revisión fuera de horario, sin presupuestar reparaciones ni reservar una duración desconocida. La ficha de cada solicitud contendría nombre, teléfono, motivo y franja preferida. El encargado decidiría la cita al abrir. Ese alcance permite comprobar la recepción de mensajes sin depender todavía de una agenda automática.
Propietario del proceso
Decide reglas y valida cambios.
Responsable técnico
Gestiona telefonía, integraciones y accesos.
Revisor
Escucha muestras y clasifica fallos.
Destino humano
Recibe transferencias o devoluciones.
Paso 2
Construye el flujo y sus fallos seguros
Redacta instrucciones por objetivos: bienvenida, intención, datos, confirmación, acción, límites y cierre. Configura herramientas con respuestas explícitas de éxito y error. No permitas que una frase de confirmación se ejecute si el sistema externo no devolvió un resultado válido.
Usa permisos mínimos y datos de prueba. Añade horarios, zonas, destinos y mensajes de transferencia. Comprueba qué se guarda en transcripciones y registros antes de utilizar información real.
Distingue tres resultados en la ficha: solicitud recibida, cita confirmada y atención pendiente del equipo. En el ejemplo del taller, todas las llamadas del primer piloto terminan en solicitud recibida. Si después añades reservas, exige un identificador de cita devuelto por la agenda antes de usar la palabra confirmada. Un resumen de conversación no sustituye ese registro.
Éxito
La acción existe y la confirmación coincide.
Sin disponibilidad
Ofrece opciones o una devolución sin inventar huecos.
Error de herramienta
No confirma; registra y escala.
Petición fuera de alcance
Explica el límite y ofrece la salida correcta.
Paso 3
Prueba conversaciones normales y difíciles
Crea un conjunto fijo de llamadas y repítelo después de cada cambio importante. Incluye acentos, interrupciones, correcciones, ruido moderado, silencio, una herramienta lenta y una petición no prevista. Revisa la acción final y los datos almacenados.
Clasifica los fallos por causa: reconocimiento, instrucciones, herramienta, datos, telefonía o diseño del proceso. Corregir la causa equivocada puede hacer la conversación más larga sin resolver el problema.
Caso habitual
La ruta prevista completa la acción.
Cambio de idea
El contexto se actualiza sin duplicar acciones.
Transferencia
Destino disponible, contexto y comportamiento al fallar.
Privacidad
Se recoge y conserva solo lo definido.
Paso 4
Lanza por etapas y conserva una salida rápida
Empieza con horario, número o porcentaje limitado. Revisa diariamente al principio y reduce la frecuencia solo cuando los fallos críticos desaparecen. Mantén una forma de desviar llamadas sin reconstruir todo el sistema.
Amplía un flujo cada vez. Cada nueva integración o motivo añade estados y fallos posibles. La implantación termina cuando existe una rutina de operación, no cuando la primera llamada funciona.
Acuerda por escrito los motivos para detener el piloto: una cita que no existe, un mensaje enviado al destino equivocado o una transferencia que deja al cliente sin salida. Son criterios operativos propuestos para este plan, no umbrales universales de calidad. Una voz poco natural puede requerir ajuste; una acción incorrecta exige resolver el fallo antes de seguir usando ese recorrido.
Decisión práctica
Qué debe quedar listo al terminar cada etapa
Al acabar el diseño, deberías tener un mapa de motivos de llamada, una lista de datos necesarios y el nombre de quien decide cada excepción. Al acabar la configuración, necesitas un guion, acceso limitado a las herramientas y una ruta de devolución comprobable. Un calendario conectado sin reglas de reserva no completa esa etapa.
Antes del piloto, repite las mismas llamadas con datos ficticios y registra el resultado esperado y el obtenido. Incluye al menos un error de herramienta y un destino que no responde. Comprueba que el equipo sabe reconocer una solicitud pendiente y que no la confunde con una cita confirmada.
Para ampliar, revisa errores por motivo, minutos consumidos y tiempo de corrección humana. El responsable del negocio debe decidir qué problemas impiden continuar. Mantén documentado cómo dirigir las llamadas de nuevo al equipo; esa salida debe poder usarse aunque la integración con la agenda esté caída.
Lista de comprobación
Seis casos que conviene resolver antes de abrir el piloto
Usa datos ficticios y apunta el resultado en el sistema de destino, además de escuchar la conversación. Para cada caso, anota la entrada, el resultado esperado, el resultado obtenido y quién corregirá el fallo. Repite el caso después del cambio; una respuesta verbal convincente no demuestra que la acción haya terminado bien.
Esta lista es un punto de partida para un servicio de recepción sencillo. Añade las excepciones reales de tu negocio y no presentes seis llamadas correctas como prueba de fiabilidad estadística. Si el flujo admite cambios de cita, cancelaciones o varios locales, esos recorridos también necesitan sus propios casos.
Solicitud normal
Pide un servicio permitido y comprueba que existe una sola ficha con el teléfono y el motivo correctos.
Dato corregido
Cambia un dígito del teléfono y una franja horaria. La ficha final debe contener la corrección, sin conservar dos solicitudes activas.
Servicio no ofrecido
Solicita algo fuera del catálogo. El agente debe explicar el límite y recoger un mensaje si esa es la salida prevista.
Agenda sin respuesta
Simula el fallo en un entorno de prueba. La conversación no debe anunciar una reserva confirmada si no existe en la agenda.
Destino cerrado
Comprueba qué ocurre cuando nadie acepta la transferencia: mensaje, devolución u otra ruta acordada, con un cierre comprensible.
Llamada interrumpida
Corta antes de confirmar los datos. El equipo debe distinguir una ficha incompleta de una solicitud lista para tramitar.
Presupuesto
Calcula el coste completo del piloto, incluida la revisión humana
No compares únicamente la cuota del agente. Suma telefonía, consumo adicional, conexiones de pago, configuración y tiempo de supervisión. Pide que la propuesta identifique qué costes son únicos y cuáles se repiten cada mes. Separa impuestos y utiliza la misma moneda y periodo para todas las opciones.
Ejemplo hipotético, no tarifa de un proveedor: 120 € de cuota mensual, 30 € de telefonía y consumo, más dos horas de revisión valoradas en 25 €/hora, suman 200 € al mes. Si la configuración cuesta 300 € y repartes ese importe entre seis meses, el coste de comparación asciende a 250 € mensuales durante ese periodo. El desembolso del primer mes sería de 500 €; repartir un coste para comparar no cambia cuándo se paga.
Si ese mes se completan 80 solicitudes válidas, el coste comparable sería 250 ÷ 80 = 3,13 € por solicitud, redondeado a céntimos. No equivale a coste por venta: una solicitud puede no convertirse en cliente. Compáralo con el tiempo que necesita tu equipo para obtener el mismo resultado y con las correcciones que sigue haciendo.
Poco volumen o proceso inestable
Empieza con recepción de mensajes y devolución humana. Automatizar reservas complejas puede añadir más configuración que trabajo resuelto.
Motivos repetidos y datos fiables
Un piloto de citas o clasificación puede tener sentido si cada resultado queda registrado y hay una persona disponible para las excepciones.
Fuentes primarias
Documentación utilizada
Los datos comerciales y técnicos pueden cambiar. Comprueba siempre las condiciones vigentes en el destino.
Preguntas frecuentes
Lo esencial antes de decidir
¿Cuánto tarda una implantación?+
Una demostración puede configurarse rápido; un piloto fiable exige mapear procesos, integrar, probar, revisar datos y preparar operación. El plazo depende del alcance.
¿Debo empezar con todas las llamadas?+
No. Empieza con un flujo frecuente, estable y reversible. Amplía cuando cumpla métricas y límites.
¿Qué hago si la IA se equivoca?+
Clasifica el fallo, revisa configuración y datos, repite la prueba y pausa el flujo si supera el umbral definido.