Copilot Studio en Dynamics: el primer flujo y los 3 errores que no anticipé
El primer flujo que construí en Copilot Studio tenía un diseño conceptualmente simple: cuando un lead completaba el formulario de contacto, el agente procesaba la información, verificaba el perfil contra los criterios del ICP en el CRM, generaba un score de calificación inicial y creaba el registro con todos los campos completados de forma automática. Era el tipo de flujo que en la documentación de Microsoft tardaba menos de 2 horas en configurar. En mi implementación específica, con los datos reales de la organización y las integraciones específicas que necesitaba, tardó 3 semanas e incluyó 3 errores que no había anticipado.
El primer error fue de formato de datos entre el formulario web y el sistema de Copilot Studio. El campo de "nombre de empresa" en el formulario permitía caracteres especiales, acentos y formatos variados porque los formularios web rara vez validan el formato de los campos de texto libre. El agente recibía esos valores y los pasaba directamente al CRM, donde el campo de nombre de empresa tenía restricciones de caracteres que producían errores en algunos casos y truncamientos silenciosos en otros. El resultado era que el 14% de los registros creados por el agente tenían el nombre de empresa incorrecto o incompleto, sin que ningún mecanismo de alerta notificara el problema.
El segundo error fue de lógica de calificación. El algoritmo de scoring que había diseñado usaba el campo de "cargo" del formulario para asignar puntos de calificación. Lo que no había anticipado era la variedad de formas en que las personas describen su cargo en un formulario de texto libre: "Director Comercial", "Dir. Comercial", "Directora Comercial", "director comercial", "Dirección Comercial" eran 5 formas de describir el mismo cargo que el algoritmo trataba como cargos diferentes, asignando scores incorrectos a 3 de ellas porque no coincidían exactamente con los valores de la lista de referencia que había construido.
El tercer error fue de manejo de casos extremos. Había diseñado el flujo para el caso estándar: un prospecto completa el formulario con información completa y válida. No había diseñado el flujo para los casos atípicos que en la práctica representaban el 22% de los formularios: formularios con campos obligatorios completados con valores de marcador de posición como "N/A" o ".", formularios enviados múltiples veces por el mismo prospecto en la misma sesión, y formularios con emails que no tenían un formato válido pero que el sistema de formularios había aceptado por configuración incorrecta del validador de campo.
Los 3 errores fueron corregidos en la semana 4. La corrección del primero requirió un proceso de normalización de texto antes de la transferencia al CRM. La del segundo requirió un algoritmo de fuzzy matching que identificaba variantes del mismo cargo como equivalentes. La del tercero requirió una lógica de manejo de excepciones que enrutaba los formularios atípicos a revisión manual en lugar de procesarlos automáticamente con datos incorrectos. Cada corrección agregó complejidad al flujo. También hizo que el flujo fuera genuinamente robusto para las condiciones del mundo real, que nunca son tan limpias como las que el diseño inicial contempla.