Lo que aprendimos con un agente de voz en una inmobiliaria de remates en CDMX.

Una versión anterior de nuestro sistema la usó, durante unos tres meses de 2026, el equipo de una inmobiliaria de remates bancarios. Esto es lo que falló, lo que aprendimos y las reglas que llevamos a la plataforma nueva. Sin métricas de negocio: todavía no las tenemos.

Este texto reemplaza una versión anterior que presentaba el proyecto como un caso de éxito, con métricas y testimonios. Esa versión no tenía el respaldo que debía tener. La retiramos. Lo que queda es lo que sí podemos sostener: qué construimos, qué falló y qué cambiamos.

Una aclaración: no nombramos al cliente, no publicamos cifras de su operación ni citamos a su gente. Es una historia sobre nuestro trabajo, no sobre su negocio.

Qué fue, en concreto.

El equipo de una inmobiliaria de remates bancarios en CDMX usó una versión anterior de nuestro sistema durante unos tres meses de 2026. Era un CRM web con un agente de voz. Estaba hecho a la medida de ese cliente: sus textos, sus catálogos, sus reglas.

Ese último punto importa. Por eso no ofrecemos esa versión a clientes nuevos. Estamos construyendo una plataforma desde cero, para varios clientes, y llevándole las reglas que aprendimos y algunas piezas ya probadas.

Lo que no te vamos a contar.

No tenemos cifras de conversión, de tiempos de respuesta ni de cierres que podamos defender en público. En esos tres meses el equipo del cliente usó el sistema, encontró fallas y ahí aprendimos mucho. Pero aprender no es medir. Si alguien te muestra números de esa operación, no vienen de nosotros.

Lo que aprendimos del agente de voz.

Estos cinco errores nos costaron muchas iteraciones. Son específicos, y por eso creemos que sirven más que un testimonio.

№ 01 — Las transiciones que decide el modelo fallan.

En el flujo de la llamada, la mayoría de los pasos de una etapa a otra los decidía el propio modelo de lenguaje ("¿ya tengo el dato? ¿paso a lo siguiente?"). En decisiones binarias, eso falla: a veces avanza antes de tiempo y a veces se queda atorado. Lo que sí funcionó fue sustituir esos juicios por condiciones explícitas y por textos fijos en los momentos críticos. En nuestras pruebas internas con llamantes simulados (al menos 18 tandas de 35), la tasa de aprobación pasó de 40% a 87%. Ojo: son simulaciones nuestras, no clientes reales, no son una muestra aleatoria ni una métrica de negocio, y la última versión seguía fallando en cerca de 40% de los casos en la confirmación del horario.

№ 02 — Los campos se pierden en silencio.

El agente capturaba un dato, pero en el camino al sistema alguna capa lo descartaba sin avisar: una lista de campos permitidos que no incluía el nuevo, una respuesta de herramienta que apuntaba a un campo que no existía. Incluso una preferencia de "no me contacten" se perdió así. Lo aprendido: cada campo se prueba de punta a punta, y un dato que no se pudo guardar tiene que fallar con ruido, no en silencio.

№ 03 — La agenda con horarios fijos no es una agenda.

La reserva por voz ofrecía una tabla fija de horarios y, si algo no cuadraba, asignaba a un asesor por defecto. La verificación de que el horario estuviera libre llegaba después de que el agente ya había confirmado la cita. Un agente que confirma antes de revisar es un agente que le miente al cliente. Lo aprendido: la disponibilidad real se consulta dentro de la llamada, antes de confirmar, y la confirmación al cliente es parte de agendar, no un extra.

№ 04 — Cada salto de herramienta suma latencia.

Una pausa de un par de segundos en una llamada se siente muy larga. Cada vez que el agente consulta una herramienta (inventario, agenda, CRM) agrega tiempo, y varias seguidas se notan. Lo aprendido: menos saltos por turno, medir los percentiles altos y no solo el promedio, y decidir qué se puede resolver sin consultar nada.

№ 05 — Las líneas se quedaban abiertas después de la despedida.

El agente se despedía, pero la llamada seguía abierta y a veces volvía a hablar. Lo aprendido: la despedida y el cierre son texto fijo y una condición explícita de fin de llamada, no una frase generada.

Lo que aprendimos de los mensajes y de los permisos.

  • Los mensajes automáticos se duplican si no los cuidas. Es un error clásico: varios procesos programan el mismo envío y cada recordatorio sale varias veces. Lo encontramos en una revisión interna y fue error nuestro. Regla para la plataforma nueva: cada envío es idempotente.
  • La confirmación al agendar por voz era una tarea pendiente. Había recordatorios a 24 y 1 hora, pero el cliente no recibía confirmación al instante. Es el tipo de hueco que un cliente nota primero, y por eso la confirmación es parte de agendar en la plataforma nueva.
  • Un error de permisos es un error de confianza. Vimos que un usuario con rol de asesor podía ver todos los leads. De ahí salió una regla: cada quien ve lo suyo y los datos de contacto se ocultan hasta que el lead está asignado.
  • La retroalimentación de quien usa la herramienta fue la mejor fuente de requisitos. Nueve ajustes concretos en pocos días, de gente que la usaba cada día. Ningún estudio de mercado nos habría dado eso.

Lo que llevamos a la plataforma nueva.

No el código tal cual. Las reglas:

  1. La IA siempre se identifica como IA, avisa si la llamada se graba y pasa la conversación a una persona. Con texto fijo, no generado.
  2. Rango de presupuesto declarado por la persona, nunca pre-aprobación. Solo después de su consentimiento expreso, el agente pregunta y registra lo que la persona declara. No evalúa, no promete crédito y no sustituye ningún trámite oficial.
  3. Un lead, un registro. El teléfono es la llave para unir llamada, WhatsApp y formulario en una sola historia.
  4. Agenda con los horarios reales del equipo, revisados antes de confirmar.
  5. Consentimiento explícito antes de preguntar por datos financieros y una lista de "no contactar" que de verdad se guarda.
  6. El agente contacta a quien pidió que lo contactaran. Nada de llamadas en frío.
  7. Pruebas con llamantes simulados y por campo, antes de poner un agente delante de un cliente.

Qué sigue: medir en pilotos.

Lo que vamos a probar en el piloto de 30 días: una página de consentimiento y un QR para un proyecto, un asistente de voz en español de México que se identifica como IA y está diseñado para responder solo con una ficha de datos que el cliente verifica y firma, un rango de presupuesto declarado por la persona (solo con su consentimiento expreso), agenda de visitas en los horarios del propio equipo, confirmación por correo (y por WhatsApp cuando Meta apruebe nuestro número), un tablero en vivo con un registro de cada paso, un reporte semanal y uno final contra la línea base del cliente, y traspaso a una persona. El canal es una llamada web desde la página de consentimiento; la llamada telefónica, solo a quien la pidió y marcó una casilla de consentimiento explícito, se habilita cuando un abogado de privacidad en México apruebe el texto.

Medimos resultados con pilotos. Publicaremos números solo cuando existan, y solo con el consentimiento por escrito del cliente. Hasta entonces, desconfía de cualquier cifra nuestra que no tenga una fuente.

PILOTO DE 30 DÍAS

¿Quieres ser parte de lo que medimos?

Un piloto por proyecto o desarrollo: MXN 10,000 + IVA, con factura. Medimos contra tu propia línea base de 60 a 90 días y tú decides si seguimos. Solo publicaremos algo con tu permiso por escrito. Si no encajamos, te lo decimos.

Ver el piloto →