Una supervisora cambia una pregunta de calidad de «¿Se ayudó al cliente?» a «¿La respuesta incluyó todas las acciones que debía realizar el cliente?». La siguiente ejecución produce una puntuación muy distinta. Eso no demuestra que el servicio haya empeorado. Cambió la regla.
La forma segura de probar criterios de calidad en Dynamics 365 es mantener el criterio nuevo como borrador, ejecutarlo sobre casos reales variados y comparar cada predicción con una referencia humana independiente. Corrige una ambigüedad cada vez y repite la misma prueba. Publica solo cuando la regla responda bien ante registros normales y difíciles.
Empieza con una sola decisión
No empieces por la puntuación deseada. Empieza por una decisión que una persona pueda defender usando el registro.
Si la pregunta evalúa si se explicó el siguiente paso, define qué mensaje contiene la evidencia, qué necesita una explicación completa, qué debe ignorarse y qué respuesta corresponde cuando falta información. «¿Se gestionó bien el caso?» obliga al evaluador a inventar su propio estándar. «¿La respuesta final indica la acción, el responsable y el plazo esperado?» sí se puede probar.
La guía de Microsoft sobre criterios de evaluación recomienda preguntas específicas, respuestas directas, exclusiones explícitas y fuentes de evidencia concretas. También permite marcar una pregunta como crítica para que cierta respuesta haga fallar la evaluación. Una pregunta crítica vaga convierte la incertidumbre en un fallo automático.
Quien dirige el modelo de soporte debe definir qué puede observar y controlar el representante.
Crea una muestra que exponga la regla
Una muestra llena de casos limpios y exitosos demuestra muy poco. Incluye registros que obliguen a la regla a mostrar sus límites.
Microsoft permite simular criterios en borrador o publicados con casos o conversaciones reales. Las condiciones seleccionan los registros y la ejecución predeterminada toma los 25 más recientes que coinciden. Registra por qué está cada caso. Los archivos adjuntos no entran en la simulación, así que no dependas de evidencia que el evaluador no recibirá.
| Registro de prueba | Motivo para incluirlo | Comportamiento esperado | Bloqueo de publicación |
|---|---|---|---|
| Caso rutinario completo | Confirma la regla básica | Respuesta clara respaldada por evidencia | Respuesta incorrecta ante evidencia visible |
| Campo o mensaje ausente | Prueba el límite de datos | Desconocido o alternativa definida | Inferencia segura desde datos ausentes |
| Transferencia | Prueba la responsabilidad | Usa solo la fuente indicada | Culpa al representante equivocado |
| Redacción ambigua | Encuentra huecos en la instrucción | Misma interpretación razonable | Desacuerdo razonable entre revisores |
| Fallo crítico | Prueba la condición de parada | Falla solo con la evidencia requerida | Falso fallo crítico |
Toma la evidencia del lugar que usará la evaluación real. Si las conversaciones pasan por una bandeja compartida, conserva el orden de mensajes, el cambio de responsable y la respuesta del cliente.
Compara con una referencia humana
Antes de simular, pide a dos revisores expertos que clasifiquen los registros por separado con la regla escrita. Así crean una referencia independiente.
Compara con esa referencia la respuesta prevista, el razonamiento y el resultado crítico. Separa tres problemas. Puede faltar evidencia, la instrucción puede permitir varias lecturas razonables o la predicción puede contradecir evidencia clara.
Cada causa requiere una solución distinta. Añadir instrucciones no recupera datos y cambiar el peso no corrige una pregunta ambigua. El registro de discrepancias muestra dónde falla la regla.
Si un flujo con IA utiliza el resultado para recomendar formación o escalado, prueba también esa decisión. Una evaluación correcta todavía puede activar una acción mal diseñada.
Cambia una cosa y repite
Corrige la causa más pequeña. Reescribe una pregunta, adelanta la exclusión, separa una pregunta doble o añade una respuesta para información ausente.
No cambies a la vez la regla, la muestra, los pesos y las respuestas esperadas. No sabrás qué mejoró el resultado.
Dynamics 365 mantiene activo el criterio publicado mientras guarda cambios como borrador. El historial registra cada edición y permite restaurar una versión anterior. La simulación no cambia los registros de clientes ni las métricas, pero cada ejecución consume créditos de Copilot. Mantén la muestra pequeña para repetirla y amplia para detectar fallos importantes.
Define la puerta de publicación y la retirada
No existe un porcentaje universal seguro. Ajusta la puerta al riesgo. La formación admite más incertidumbre que el cumplimiento o una decisión de acceso.
Exige como mínimo que no haya fallos críticos sin explicar, respuestas seguras sin evidencia requerida, discrepancias sin resolver ni una versión sin responsable de retirada. Al publicar, conserva la muestra, las respuestas de referencia, la fecha de simulación y las limitaciones conocidas.
Las evaluaciones nuevas usan la versión publicada más reciente. Tras el lanzamiento, vigila cambios en discrepancias, respuestas desconocidas y fallos críticos. Conserva la versión previa y define la señal que activa la retirada.
El modelo de seguridad debe controlar quién edita criterios, simula, revisa y publica. La guía de Microsoft para gestionar la evaluación separa los roles de administrador, responsable y evaluador de calidad, e indica requisitos de conexiones, créditos, agentes de IA y movimiento de datos. Superar una simulación no sustituye esos controles.
Mantén el caso junto a la puntuación
Conserva con el resultado el registro del cliente, la evidencia revisada, la versión y la acción realizada. Así una persona puede explicar y corregir la puntuación.
Si el proceso combina mensajería, IA y revisión humana, dibuja esos límites antes de automatizar más decisiones. Una demostración de DripTell puede ayudar al equipo a revisar cómo se mueven el contexto, la responsabilidad y la evidencia de transferencia por el flujo completo. La regla de evaluación debe seguir siendo comprensible fuera de cualquier plataforma.
Preguntas frecuentes
¿Puedo simular un borrador sin cambiar las puntuaciones reales?
Sí. Microsoft indica que funciona con criterios en borrador o publicados y no afecta a registros de clientes ni métricas de calidad. Comprueba antes el flujo y los créditos.
¿Cuántos casos debo probar?
Usa suficientes para cubrir trabajo rutinario, evidencia ausente, transferencias, ambigüedad y fallos críticos. La cobertura del riesgo importa más que una cifra universal.
¿Debo probar de otra forma una pregunta crítica?
Sí. Incluye un aprobado claro, un fallo claro y evidencia incompleta. La regla crítica solo debe fallar cuando la evidencia necesaria respalde esa decisión.
¿Qué debe detener la publicación?
Deténla si los revisores no aplican la regla de forma consistente, falta la evidencia necesaria, aparecen falsos fallos críticos o nadie se responsabiliza de retirar y corregir la versión.
¿Te ayudamos a aplicar esta guía?Pregunta al equipo de DripTell
De la lectura a la acción
¿Quieres aplicar estas ideas en tu negocio?
Déjanos tus datos. Tendremos en cuenta el artículo que estás leyendo y empezaremos con una respuesta útil para tu equipo.
DripTell Editorial
Guías prácticas revisadas por el equipo de producto y flujos de cliente de DripTell.
Consulta cómo DripTell verifica el producto, utiliza fuentes primarias y corrige errores.
Política editorial y de fuentes
