¿Teams puede ser el sistema de registro de una aprobación comercial?

No. Teams puede mostrar la solicitud y recoger la respuesta, pero la cotización, la política aplicada, la decisión y el resultado de ejecución deben persistir en el CRM, ERP u otro registro controlado.

¿Conviene pedir aprobación para cada cotización?

No necesariamente. Los casos que cumplen una política explícita pueden seguir su ruta estándar. La revisión humana aporta más cuando existe una excepción de descuento, crédito, margen, plazo o autoridad.

¿Qué debería hacer Copilot dentro del flujo?

Puede redactar un resumen basado en campos autorizados. No debería decidir límites, elegir al aprobador, alterar importes ni escribir la aprobación final; esas acciones pertenecen a reglas deterministas y personas con autoridad.

Aprobaciones comerciales en Teams con Power Automate: cotizaciones, descuentos y crédito

En 60 segundos: Dispará el flujo desde un cambio real en el CRM o ERP, creá un ID único y evaluá una política versionada. Power Automate enruta la excepción y Teams muestra la decisión; ninguno reemplaza el sistema de registro. La tarjeta debe enseñar importe, moneda, condición solicitada, regla incumplida, efecto comercial, responsable y vencimiento. Un rechazo necesita motivo. Antes de ejecutar, volvé a validar que la cotización no cambió. Guardá decisión, aprobador, versión de política y resultado en el CRM o ERP. Empezá con una ruta durante una semana y medí tiempo a decisión, excepciones y correcciones manuales.

Una aprobación comercial falla mucho antes de que falle el conector. Falla cuando nadie sabe qué versión de la cotización se aprobó, cuando el gerente responde “dale” en un chat o cuando una decisión correcta no vuelve al sistema que libera el pedido.

El objetivo no es digitalizar el “sí”. Es construir una transición controlada entre una solicitud comercial y una acción en el sistema de registro. Teams puede hacer cómoda la intervención humana. Power Automate puede coordinar el recorrido. La política y la evidencia necesitan un hogar más estable.

El ciclo completo, sin saltos invisibles

Tomemos una cotización con descuento fuera de política. El flujo útil tiene cinco tramos:

Solicitud. El CRM crea una solicitud inmutable para una versión de la cotización y asigna un ID de correlación.
Enrutamiento. Una regla consulta monto, moneda, descuento, margen, riesgo de crédito, región y rol requerido. Los umbrales son los de la empresa, no valores propuestos por la automatización.
Decisión. La persona autorizada recibe el contexto en Teams y elige aprobar, rechazar o pedir información. La respuesta vence y queda ligada a esa versión.
Escritura. El flujo registra la decisión y, si corresponde, ejecuta el cambio permitido en CRM o ERP después de validar otra vez los datos.
Notificación. Solicitante, responsable comercial y dueño de excepciones reciben el resultado o el fallo, con un enlace al registro oficial.

No publiques primero la tarjeta y “completes los datos después”. Creá el registro pendiente antes de notificar. Así, una caída de Teams o una ejecución interrumpida deja un caso recuperable en vez de una conversación huérfana.

Un estado mínimo puede ser pendiente → aprobada/rechazada/vencida → aplicada/fallida. “Aprobada” y “aplicada” son estados distintos: una decisión humana válida no demuestra que el ERP aceptó la actualización.

Repartí bien las responsabilidades

Componente	Responsabilidad	Lo que no debería decidir
CRM o ERP	Cotización vigente, cliente, condiciones, estado y evidencia final	La presentación de la tarjeta
Regla de negocio	Umbrales, jerarquía, segregación, excepciones y vigencia	Texto libre generado por IA
Power Automate	Disparar, consultar, enrutar, esperar, revalidar, escribir y manejar fallos	Política comercial improvisada dentro de ramas opacas
Teams	Mostrar contexto y recoger una respuesta autenticada	Ser la única copia de la decisión
Copilot	Redactar un resumen de campos permitidos	Aprobar, modificar importes o elegir su propio nivel de autoridad

Una regla de descuento debe poder leerse y versionarse. Puede vivir en una tabla administrada, una configuración de Dataverse o el sistema comercial, según la arquitectura. Evitá enterrarla en el texto de un prompt o repetirla en diez condiciones del flujo.

Power Automate encaja cuando los conectores, el volumen y la complejidad del estado son manejables. Si la lógica crece, varias automatizaciones comparten una API o la reanudación necesita más control, revisá cuándo usar Power Automate, un conector o desarrollo a medida.

La tarjeta: lo mínimo para decidir bien

Una tarjeta no debería copiar la ficha completa del cliente. Debería presentar la diferencia que una persona necesita evaluar:

ID de solicitud y enlace al registro oficial
cliente o cuenta, sin datos personales innecesarios
tipo de operación: cotización, descuento, crédito o plazo
importe y moneda, con base comparable si la política la necesita
condición estándar y condición solicitada
regla o límite que activó la excepción
margen, exposición o efecto relevante, calculado por el sistema responsable
solicitante, propietario comercial y aprobador requerido
fecha y hora de vencimiento con zona horaria
versión de la cotización y de la política

Microsoft permite responder aprobaciones desde una tarjeta en Teams, Outlook o el centro de acciones de Power Automate. Si el proceso necesita una interfaz propia, Power Automate también puede publicar una adaptive card y esperar una respuesta. Probá la tarjeta en los clientes que realmente usa el equipo; una composición que funciona en escritorio puede exigir simplificación en móvil.

Usá acciones inequívocas: Aprobar, Rechazar y Pedir información. El rechazo debe exigir una razón breve y estructurada cuando sea posible. “Pedir información” no conserva la aprobación anterior: devuelve el caso al solicitante, registra la pregunta y exige una nueva versión si cambian los términos.

La tarjeta debe quedar cerrada o actualizada después de responder. Dos clics concurrentes no pueden producir dos ejecuciones: la primera transición válida gana y las siguientes reciben el estado actual.

Timeouts y escalado sin ejecuciones eternas

Definí el vencimiento como política operativa, no como un detalle del conector. El registro pendiente conserva vence_en, aprobador actual y nivel de escalado. Un flujo programado puede localizar casos vencidos, marcarlos y crear la siguiente tarea según la matriz acordada.

No conviertas el escalado en “mandar más avisos”. Debe responder preguntas concretas:

¿se delega a otra persona con la misma autoridad o sube de nivel?
¿la ausencia del aprobador pausa la operación o activa un reemplazo registrado?
¿un caso vencido se rechaza, se cancela o vuelve al solicitante?
¿qué canal recibe una alerta si el conector falla?

Microsoft recomienda almacenar la aprobación en Dataverse cuando un flujo puede durar más de 30 días. Para procesos largos, separá “crear y notificar” de “reanudar y ejecutar”. El estado pendiente sobrevive al run y una respuesta se procesa contra el registro vigente.

Antes del piloto, verificá en el tenant la licencia de conectores, el entorno donde se crean las aprobaciones, las políticas DLP, la disponibilidad de Teams Workflows, la versión compatible de adaptive cards y la retención de historial. Son condiciones de la instalación, no capacidades que conviene asumir desde una guía.

Qué debe quedar fuera del chat

El sistema de registro necesita suficiente evidencia para reconstruir un caso sin abrir Teams:

ID de solicitud y registro comercial afectado
versión o hash de la cotización aprobada
valores antes y después de la decisión
política, regla y ruta de aprobación aplicadas
identidad y rol del solicitante y del aprobador
respuesta, motivo y marcas de tiempo
resultado de la escritura, ID de transacción y error normalizado
intentos, escalados y relación con cualquier solicitud reemplazada

Guardá referencias y campos relevantes; no dupliques secretos, conversaciones completas ni datos personales que el control no necesita. La retención y el acceso deben seguir la política de la empresa.

Teams puede conservar una vista conveniente. No debe ser la prueba única. Una persona que no tenga acceso al canal debería poder auditar el registro autorizado en CRM, ERP, Dataverse o la plataforma definida por la empresa.

Controles antes de liberar una operación

Autoridad. Calculá los aprobadores desde roles o grupos administrados. No aceptes una dirección enviada por el solicitante como prueba de autoridad. Registrá quién tenía el rol al momento de responder.

Segregación de funciones. La persona que pide una excepción no debería aprobarla cuando la política exige separación. En crédito o condiciones sensibles, quien aprueba y quien aplica pueden ser identidades distintas. La cuenta del flujo recibe solo los permisos necesarios.

Revalidación. Justo antes de escribir, compará versión, importe, moneda, descuento, estado y aprobador requerido. Si cambió un campo material, invalidá la respuesta y generá una solicitud nueva. Aprobar una captura vieja no autoriza una cotización nueva.

Idempotencia y replay. Una clave única evita aplicar dos veces la misma decisión. “Reintentar” repite una operación que no confirmó resultado; “replay” reconstruye un caso desde evidencia guardada. Ambos deben respetar el estado actual y dejar un nuevo evento de auditoría. Nunca vuelvas a enviar todas las aprobaciones fallidas con un botón global sin alcance.

Operación. Definí un dueño para la cola de fallos, una forma de pausar nuevas solicitudes y un procedimiento manual para continuar ventas. Una aprobación humana es solo el nivel de ejecución aprobada; necesita permisos, límites, logs y recuperación alrededor.

Un piloto de una semana

Elegí una sola ruta, por ejemplo descuentos no estándar de una unidad comercial. No mezcles cotización, crédito y prórrogas en la primera prueba.

Antes de empezar: registrá cómo se decide hoy, qué campos son obligatorios, quién puede aprobar y cuántos casos quedan sin resolución. Congelá la matriz del piloto y prepará casos de prueba: duplicado, dato faltante, rechazo, vencimiento, cambio posterior y fallo al escribir.

Durante la semana: revisá a diario la cola y registrá, sin fijar una meta inventada:

tiempo desde solicitud válida hasta decisión, separado de la espera por datos
solicitudes por ruta, aprobador y resultado
excepciones por datos, permisos, timeout, concurrencia o conector
rechazos y pedidos de información con motivo
reescrituras manuales en CRM o ERP y su causa
decisiones aprobadas que no llegaron a aplicarse
reintentos y replay realizados por operación

Al cerrar: compará con la línea base y revisá casos individuales. Una mediana más baja no compensa decisiones mal registradas. Decidí si corregir datos, ajustar una regla, mejorar la tarjeta o sacar una parte a desarrollo a medida antes de ampliar el alcance.

Si la aprobación forma parte de un seguimiento por canales, conectala con el patrón de ventas entre WhatsApp y Teams: el CRM conserva la verdad, Teams maneja la excepción y el canal externo actúa solo después de una decisión válida.

Kiia puede mapear la matriz de autoridad, construir una ruta piloto y dejar la evidencia en el sistema que ya gobierna la operación. La meta es que una decisión comercial avance rápido sin volverse invisible.