¿Qué significa que una oportunidad no tiene próximo paso?

Significa que sigue abierta y dentro del alcance del piloto, pero no tiene una acción futura válida con tipo, fecha y responsable, o esa acción ya venció. La regla también debe comprobar etapa, última actividad, pausas y exclusiones antes de crear una alerta.

¿Cuándo conviene un agente y cuándo alcanza Power Automate?

Power Automate suele alcanzar cuando una fuente, una cadencia y reglas deterministas producen siempre la misma alerta. Un agente aporta valor cuando debe reunir contexto autorizado, explicar una prioridad, proponer un próximo paso y manejar excepciones, siempre dentro de permisos y controles explícitos.

¿El agente debe contactar al prospecto de forma autónoma?

No durante el piloto. El agente puede detectar, explicar, recomendar y preparar un recordatorio interno. Una persona elige el próximo paso y aprueba cualquier comunicación externa. La ejecución solo debería ampliarse para acciones repetibles con reglas de elegibilidad, volumen, parada y auditoría probadas.

Cómo hacer un agente de seguimiento de oportunidades

En 60 segundos: Definí “sin próximo paso” con campos que el sistema pueda comprobar: oportunidad abierta, etapa incluida, responsable activo, última actividad conocida y ausencia de una acción futura con tipo, fecha y dueño. Leé desde el CRM, el ERP o un export validado con responsable; una hoja suelta sin dueño no puede sostener el piloto. Empezá con el agente en modo recomendación: detecta, muestra evidencia, sugiere una acción y prepara un recordatorio interno, mientras una persona decide. Dale herramientas separadas para leer oportunidades, consultar disponibilidad en calendario o Teams y escribir el próximo paso aprobado. Durante dos semanas medí contactos recuperados, falsas alarmas y tiempo hasta la acción. Si faltan dueños, estados fiables o una política de seguimiento, corregí el proceso antes de automatizarlo.

Una alerta puede encontrar una oportunidad olvidada. Un agente tiene un trabajo más amplio: reúne el contexto permitido, explica por qué el caso merece atención, propone una acción compatible con la etapa y devuelve la decisión humana al registro oficial.

Ese alcance responde a una pregunta distinta de la guía sobre recuperar ventas olvidadas, que desarrolla por qué el seguimiento es un buen primer caso de uso. También parte del flujo Microsoft de oportunidades sin próximo paso con Power Automate y Teams. Acá construiremos el agente: objetivo, fuente de verdad, permisos, herramientas, flujo, excepciones y evaluación.

El agente no sustituye al CRM, no decide condiciones comerciales y no atribuye una venta a su propia intervención. Su salida es más modesta y verificable: una oportunidad abierta termina con un próximo paso válido, una excepción asignada o una resolución registrada.

Definí el objetivo como un cambio de estado

Usá una transición que pueda observarse en datos:

oportunidad elegible sin acción futura
  -> recomendación con evidencia
  -> decisión humana
  -> próximo paso o excepción registrada

Una oportunidad está “sin próximo paso” cuando cumple todas las condiciones de elegibilidad y falla la cobertura de acción. La definición mínima necesita estos campos:

Campo	Regla comprobable
`opportunity_id`	Identificador estable y único en la fuente de verdad
`status`	Sigue abierta; ganado, perdido y cancelado quedan fuera
`stage`	Pertenece a una etapa incluida en el piloto
`owner_id`	Corresponde a una identidad activa con permiso para actuar
`last_activity_at`	Proviene de una actividad registrada y tipificada
`next_step_type`	Describe una acción admitida por la política comercial
`next_step_at`	Tiene fecha futura y zona horaria definida
`next_step_owner_id`	Identifica quién debe realizar la acción
`snooze_until` y `snooze_reason`	Explican una pausa vigente, cuando exista

Marcá el caso cuando next_step_type, next_step_at o next_step_owner_id estén vacíos, o cuando la fecha haya vencido. Después aplicá el umbral acordado para su etapa y excluí pausas válidas, actividades recientes, oportunidades cerradas y segmentos fuera del piloto.

La “última actividad” también necesita una definición. Una llamada registrada, una reunión completada o una respuesta del prospecto pueden reiniciar el reloj. Abrir una ficha, editar una etiqueta o ejecutar una sincronización técnica no deberían hacerlo. Ventas debe aprobar el catálogo de eventos y los umbrales por etapa; el agente solo aplica esa política.

Conservá una fuente de verdad con responsable

El CRM suele ser la fuente principal porque conserva etapa, dueño, actividades y próximo paso. En algunas empresas el ERP controla la cotización y el estado comercial. Un export periódico también puede servir para un piloto si tiene esquema, hora de corte, validación y una persona responsable de corregirlo.

Fuente	Puede sostener el piloto cuando	Señal de bloqueo
CRM	Los estados, actividades y dueños se actualizan con una política común	Las etapas significan cosas distintas según la persona
ERP	Oportunidad, cotización y responsable tienen IDs estables y fechas fiables	El próximo paso vive solo en notas libres o fuera del sistema
Export validado	Tiene origen documentado, corte conocido, control de calidad y dueño	Nadie puede explicar ni corregir una fila
Excel operativo	Existe como tabla controlada, con IDs, permisos y responsable	Es una copia suelta, manual y sin dueño

Una hoja de Excel sin responsable no es una fuente de verdad. Puede ayudar a descubrir campos faltantes, pero el agente amplificaría sus retrasos, duplicados y estados obsoletos. Antes de automatizar, acordá qué sistema gana ante un conflicto y dónde se escribirá la resolución.

El agente recibe solo los campos necesarios. Teams no necesita mostrar teléfono, correo, conversación completa ni notas sensibles para avisar que la oportunidad OPP-1042 requiere revisión. El enlace al registro conserva el acceso bajo los permisos del sistema original.

Asigná control y permisos por acción

La guía de cinco niveles de control para agentes propone decidir la autonomía acción por acción. Para este piloto, una matriz razonable es:

Acción	Nivel inicial	Control requerido
Leer oportunidades del segmento	Lectura	Vista limitada por equipo, campos mínimos y registro de consultas
Marcar ausencia de próximo paso	Regla determinista	Versión de política, hora de corte y razón legible
Priorizar y sugerir una acción	Recomendación	Evidencia enlazada, confianza o limitación visible y opción de corregir
Preparar un recordatorio interno	Borrador	Destinatario autorizado, contenido mínimo y sin envío automático
Escribir el próximo paso	Ejecución aprobada	Payload exacto aprobado, relectura del estado y log del resultado
Contactar al prospecto	Fuera del piloto	Consentimiento, canal, plantilla, reglas de parada y aprobación aparte

Usá una identidad técnica propia con privilegio mínimo. Separá la lectura de la escritura y restringí esta última a los campos del próximo paso, la resolución de la alerta y la referencia de auditoría. El agente no necesita permiso para cambiar importes, descuentos, etapa, probabilidad o dueño de la oportunidad.

La aprobación debe quedar vinculada al payload exacto: oportunidad, tipo de acción, fecha, responsable y motivo. Si el registro cambia entre la propuesta y la ejecución, la herramienta relee la versión actual y pide otra decisión. Un botón de parada externo debe poder suspender nuevas escrituras sin depender del modelo.

Dale herramientas pequeñas y explícitas

Evitá una conexión genérica a la base de datos. Cada herramienta debe tener un esquema estrecho, permisos propios, timeout y respuesta estructurada.

list_follow_up_candidates(cutoff, segment, policy_version) consulta la vista autorizada y devuelve IDs, etapa, dueño, fechas, estado del próximo paso y referencias a evidencia. No entrega conversaciones completas.
get_opportunity_context(opportunity_id) relee una oportunidad antes de recomendar o escribir. Devuelve versión, estado, última actividad permitida, exclusiones y próximos pasos existentes.
get_owner_availability(owner_id, window) consulta disponibilidad laboral en calendario o presencia útil en Teams. Devuelve franjas o ausencia; no expone títulos, participantes ni contenido de reuniones.
prepare_internal_reminder(opportunity_id, owner_id, reason, proposed_step) crea un borrador o una tarjeta pendiente de aprobación. No envía comunicación externa.
write_next_step(opportunity_id, expected_version, step_type, due_at, owner_id, approval_id) valida campos, versión y autorización, escribe en el CRM o ERP y devuelve el registro canónico.
record_follow_up_outcome(alert_id, outcome, reason_code) cierra el ciclo con resultado, falsa alarma, pausa o excepción. Usa códigos definidos y admite una nota breve saneada.

La disponibilidad ayuda a proponer una fecha realista, pero no autoriza al agente a reservar tiempo ni revela el calendario de otra persona. Si Teams se usa para aprobar, la decisión debe volver mediante una API controlada; una reacción o un mensaje libre no bastan como autorización.

Construí el flujo feliz con una parada humana

El flujo puede ejecutarse al inicio de la jornada o con la cadencia acordada por ventas:

El programador fija hora de corte, segmento y versión de política.
La herramienta de lectura obtiene oportunidades abiertas dentro del alcance.
Las reglas excluyen casos cerrados, pausados, con actividad reciente o con próximo paso futuro válido.
El agente relee cada candidata, resume los hechos permitidos y propone una acción de un catálogo aprobado. Cada propuesta incluye el motivo de detección y los campos que la sostienen.
La disponibilidad del responsable limita las fechas sugeridas. Si no se puede consultar, la propuesta deja la fecha para revisión.
El sistema agrupa las propuestas por responsable y prepara un digest en Teams o una cola dentro del CRM.
La persona confirma, corrige, pausa, reasigna a la cola de gestión o descarta como falsa alarma.
La herramienta relee la oportunidad. Si la versión sigue vigente, escribe el próximo paso aprobado y registra la decisión; si cambió, detiene la escritura y muestra el conflicto.

La recomendación debe explicar su base con frases simples: “cotización enviada, seis días sin actividad registrada y sin acción futura”. No debe inferir que el prospecto perdió interés, prometer una fecha de entrega ni redactar una oferta fuera de la política.

Tratá las excepciones como resultados del flujo

Una excepción visible es mejor que una recomendación inventada. Cada caso necesita código de motivo, oportunidad, estado leído, acción requerida, responsable de resolver y hora de entrada.

Excepción	Respuesta del agente	Destino
Faltan etapa, última actividad o fecha fiable	No prioriza ni propone; enumera los campos faltantes	Responsable de calidad de datos
`owner_id` está vacío, inactivo o ausente	No envía un recordatorio personal ni reasigna por su cuenta	Cola del responsable comercial
La oportunidad ya está cerrada	Cancela la propuesta y registra un caso obsoleto	Reconciliación y ajuste de la consulta
Apareció actividad después del corte	Detiene la escritura y muestra la nueva versión	Responsable original, solo si aún requiere acción
Ya existe un próximo paso válido	Deduplica y cierra la alerta como resuelta	Registro de evaluación
Calendario o Teams no responde	Conserva la recomendación sin fecha automática	Cola operativa de integración
CRM o ERP rechaza la escritura	No simula éxito; guarda el error y la clave idempotente	Operador de la integración

Los reintentos sirven para timeouts después de comprobar si la escritura ocurrió. Un campo ausente, una identidad inactiva o un conflicto de versión necesitan una decisión, no otra llamada idéntica.

Evaluá reglas, recomendaciones y herramientas por separado

Prepará un conjunto de casos recientes saneados que incluya oportunidades con próximo paso válido, fechas vencidas, pausas, actividad tardía, responsables ausentes y cierres posteriores al corte. La evaluación debe comprobar tres capas:

la regla encuentra las candidatas correctas y excluye las que no corresponden;
la recomendación usa solo evidencia disponible y una acción admitida por la etapa;
las herramientas rechazan permisos, campos, versiones o aprobaciones inválidos.

Registrá falsos positivos y omisiones por motivo. Revisá también que las propuestas no copien PII a Teams, que un cambio posterior invalide la aprobación y que repetir la misma escritura no cree dos próximos pasos. Probá la parada global y el procedimiento para corregir un campo escrito por error.

Pilotá durante dos semanas

Elegí un equipo, una etapa y una política de seguimiento. Antes del primer día, tomá una línea base comparable y documentá cómo se cuentan las métricas. La guía de qué automatizar primero ayuda a mantener este alcance pequeño.

Durante la primera semana, usá modo sombra para comparar la cola del agente con la revisión del equipo. Cuando las reglas y los permisos funcionen, pasá a recomendación y escritura aprobada. La segunda semana sirve para observar el uso cotidiano, las correcciones y algunas excepciones reales; no para prometer una mejora comercial permanente.

Métrica	Definición para el piloto
Contactos recuperados	Oportunidades elegibles detectadas por el agente que terminan en un contacto registrado después de una aprobación humana
Cobertura de próximo paso	Proporción de oportunidades elegibles que terminan con tipo, fecha y responsable válidos
Falsas alarmas	Alertas descartadas porque había actividad, cierre, pausa o próximo paso que la consulta no representó bien
Tiempo hasta la acción	Tiempo entre detección y próximo paso registrado; separá aprobación de contacto efectivo
Correcciones humanas	Cambios de tipo, fecha, dueño o prioridad sobre la propuesta
Excepciones operativas	Casos bloqueados por datos, identidad, permisos, versiones o fallos de integración

Informá conteos y tasas con sus denominadores. Un contacto posterior no demuestra que el agente causó una venta, y una oportunidad cerrada no es un recovery rate atribuible. La decisión al final del piloto es si la cola es más fiable y accionable, qué reglas requieren ajuste y qué nivel de control debe mantenerse.

Diferenciá el agente de un flujo de Power Automate

Usá Power Automate cuando una consulta programada, un conjunto de condiciones y una plantilla producen una salida estable. Es una buena opción para leer una fuente Microsoft, aplicar umbrales por etapa, deduplicar y enviar un digest al responsable. La guía específica de Power Automate y alertas en Teams cubre esa ruta.

El agente se justifica cuando la salida requiere reunir contexto permitido de varias herramientas, explicar prioridades, elegir una recomendación de un catálogo y manejar información incompleta sin ocultarla. Las reglas de elegibilidad, permisos y escritura siguen siendo deterministas. El modelo trabaja sobre la parte ambigua; no reemplaza esas barreras.

Una arquitectura híbrida suele ser suficiente: Power Automate programa la revisión y entrega el digest; un servicio de agente prepara recomendaciones para la cola validada; el CRM conserva estado, aprobación y resultado. Si el flujo de reglas ya resuelve el problema, añadir un agente solo aumenta coste operativo y superficie de fallo.

Cuándo no construirlo

No empieces el piloto cuando nadie puede definir las etapas, no existe un dueño de los datos, las actividades no se registran o las oportunidades no tienen identificadores estables. Tampoco cuando el equipo no ha acordado qué cuenta como próximo paso o no puede atender la cola resultante.

Un volumen bajo y una revisión manual fiable pueden hacer innecesaria la integración. Una sola fuente con condiciones fijas probablemente necesita el flujo de Power Automate enlazado arriba. Si cada próximo paso exige negociar precio, disponibilidad o compromisos especiales, mantené la decisión y la comunicación en manos del responsable comercial.

Corregí primero la política, los campos y la propiedad. Después, el agente puede convertir una omisión medible en trabajo visible sin inventar contexto ni tomar una decisión comercial que no le corresponde.