Skill de Nexus Workflows, emails y landings

La skill Nexus Sales Automations crea workflows propios del CRM disponible en nexus.atendium.com. También crea emails reutilizables y landings editables con los componentes del producto, y diseña su conexión con formularios, campañas y seguimiento. Su foco es que cada oportunidad tenga responsable y próxima acción.

Descargar Nexus Workflows .zip

Cuándo usarla

Asignar leads y responsables.
Calificar contactos y actualizar lifecycle o score.
Crear y mover deals.
Crear tareas, llamadas, emails y próximas actividades.
Diseñar cadencias cancelables por respuesta.
Recuperar oportunidades estancadas.
Reaccionar a formularios, mensajes, campañas o eventos CRM.
Revisar o simular una automatización existente.
Redactar y construir emails, landings y campañas conectadas al proceso comercial.

Puede coordinarse con las skills de agentes de Atendium y usar acciones como una plantilla WhatsApp desde Nexus, pero el proceso se ejecuta en el CRM.

Recibir contexto desde Atendium

Las skills de Agentes Legacy y Atendium Workflows pueden entregar un prompt de continuidad comercial listo para copiar. Nexus Workflows conserva las decisiones ya resueltas, distingue eventos inferidos por IA de ramas determinísticas y pregunta mediante choices únicamente por datos pendientes como pipeline, owner, SLA o cadencia.

Ese prompt no activa nada ni autoriza efectos reales. Si Atendium ya creó el contacto, deal, etiqueta o actividad, la automatización de Nexus debe evitar duplicarlo.

Invocación

$nexus-sales-automations <comando> <objetivo o archivo>

Comandos generales

Comando	Para qué sirve
`shape`	Indaga el proceso comercial y entrega arquitectura sin JSON final.
`build`	Genera workflow `draft`, escenarios mock y validación.
`edit`	Modifica conservando keys, IDs y comportamiento no solicitado.
`critique`	Evalúa seguimiento, conversión, ownership y próxima actividad.
`audit`	Revisa esquema, seguridad, ramas, duplicación e idempotencia.
`simulate`	Recorre condiciones, respuestas, timeouts y acciones con mocks.
`validate`	Comprueba contratos, corrige errores y declara pruebas pendientes.
`harden`	Añade dedupe, límites, fallbacks, aprobación y recuperación.
`optimize`	Reduce runs innecesarios y acciones duplicadas.
`explain`	Explica lo que ocurre con contacto, deal y actividad en cada ruta.

Comandos comerciales

Comando	Para qué sirve
`cadence`	Seguimiento multintento que termina por respuesta, opt-out, conversión o límite.
`rescue`	Recuperación de leads fríos, actividades vencidas o deals fuera de SLA.
`funnel`	Recorrido completo desde entrada hasta `won`, `lost` o nurture.

Emails, landings y campañas

Comando	Entrega
`email`	Asunto, preheader, contenido, CTA, JSON importable y HTML con variables y footer administrado.
`landing`	Página editable, JSON de guardado, HTML y vista previa; formulario y conexión comercial definidos.
`campaign`	Audiencia, pieza, secuencia o workflow necesario y plan de medición. No realiza envíos por generar el borrador.

Antes de diseñar, pregunta por audiencia, oferta, objetivo, marca, CTA, destinos, fuentes y restricciones. Puede avanzar en el email o landing aunque todavía estén pendientes pipeline, owner o cadencia; señala por separado la conexión comercial que falta.

Reutiliza el builder de Nexus: 35 tipos de bloque, con 18 disponibles en email y 25 en página. Incluye texto, imágenes, botones, columnas, secciones de email, hero, navegación, formularios, video, beneficios, precios, FAQ y otros componentes. Cada pieza usa los bloques adecuados; los testimonios, precios y métricas requieren datos aprobados.

Un email reutilizable, una campaña, una landing y un formulario son recursos distintos. La acción create_marketing_draft_bundle crea borradores relacionados; no equivale a crear un email reutilizable ni garantiza que el formulario esté insertado en la página. La skill prepara y verifica ese enlace.

Con el checkout de Nexus y sus dependencias instaladas, el helper usa las funciones nativas:

node scripts/build_marketing_asset.cjs --repo /ruta/nexus_crm \
  --spec fixtures/email-spec.json --out /tmp/email-demo

Para una landing, usá fixtures/landing-spec.json o un spec propio. Genera payload.json, builder-template.json, preview.html y report.json. Comprueba serialización y conservación de los bloques editables. Los ejemplos contienen datos o conexiones pendientes y no deben publicarse sin adaptarlos.

La entrega revisa escritorio y móvil, copy, enlaces, variables, baja, estados del formulario y próximo paso comercial. La vista previa HTML no certifica compatibilidad con todos los clientes de correo ni prueba envío o captura real.

Ejemplos

$nexus-sales-automations shape seguimiento de leads de WhatsApp
$nexus-sales-automations build asignar nuevos leads por round-robin
$nexus-sales-automations cadence tres intentos si el lead no responde
$nexus-sales-automations rescue deals estancados en propuesta
$nexus-sales-automations funnel contacto nuevo hasta venta
$nexus-sales-automations simulate workflow.json
$nexus-sales-automations email bienvenida a quienes solicitan una demo
$nexus-sales-automations landing captura de consultas para nuestro servicio

Descubrimiento guiado

La skill pregunta en lenguaje comercial y presenta choices. Puede indagar trigger, canal, identidad, calificación, pipeline, owner, SLA, cadencia, cierre y KPI.

¿Las conversaciones deben tratarse igual en todos los canales?

A. Todos los canales siguen la misma lógica.
B. Cada canal tiene seguimiento o cadencias diferentes.
C. Sólo WhatsApp tiene tratamiento especial.
D. Otro — describilo con tus palabras.

No pregunta qué nodos desea el usuario: traduce el proceso a triggers, condiciones y acciones de Nexus.

Capacidades cubiertas

La skill conoce los nodos estructurales de trigger, acción, condición, espera, espera por evento, IA, fuente de datos, HTTP, código, variables, aprobación humana y fin.

También conoce los triggers de contactos, deals, actividades, Inbox, marketing, tickets, agenda y webhooks; además de acciones para ownership, lifecycle, scoring, pipeline, actividades, comunicación, secuencias, marketing e integraciones.

Principios comerciales

Resolver identidad y duplicados antes de crear registros.
Crear un deal cuando exista potencial económico, no ante cada interacción.
Toda oportunidad abierta debe tener owner y próximo paso.
Mover de etapa sólo por evidencia comercial.
Detener cadencias ante respuesta, opt-out, conversión o cierre.
Usar IA para clasificar o proponer, con guardas y aprobación para efectos sensibles.
Medir respuesta, contacto efectivo, conversión, aging, SLA, ciclo y win rate.

Validación funcional con mocks

python3 scripts/validate_and_simulate.py workflow.json \
  --scenarios scenarios.json \
  --report report.json

El validador comprueba nodos, triggers, acciones, campos obligatorios, condiciones, ramas, referencias, ciclos, alcanzabilidad, secretos e invariantes comerciales. Después recorre caminos con decisiones aportadas explícitamente por el escenario, por ejemplo:

lead responde o alcanza timeout;
rama con condición coincidente o fallback default;
WhatsApp enviado o fallback;
aprobación o rechazo;
owner disponible o ausente;
evento repetido;
deal en etapa incompatible;
detención por respuesta, opt-out o cierre.

Todas las acciones quedan registradas como efectos simulados y no modifican Nexus. Los escenarios pueden afirmar acciones prohibidas y cantidades exactas. No ejecutan predicados, modelos, expresiones ni deduplicación persistente.

Agregá --repo /ruta/nexus_crm --require-native para comprobar también el DTO y los validadores nativos de acciones y triggers. El reporte distingue estas comprobaciones de una prueba del servicio completo.

La skill respeta las condiciones guardadas en cada rama, el fallback default y las salidas event_received/timeout de una espera. Una espera por respuesta no demuestra cancelación ante compra, baja o cierre: se comprueba la salida correspondiente y el estado antes de cada intento.

Resultado de `build`

Objetivo y KPI.
Supuestos y decisiones tomadas mediante choices.
Workflow nativo en draft.
IDs pendientes del tenant.
Escenarios mock y reporte.
Riesgos y estrategia de dry-run.

Límites

La simulación no puede confirmar que un pipeline, etapa, usuario, agente o template exista; tampoco valida credenciales, permisos o entrega del proveedor. La prueba del endpoint del producto distingue dry_run y live. Incluso preview o dry-run pueden ejecutar IA/HTTP y registrar información: se revisan sus efectos antes de utilizarlos. La publicación y los envíos se realizan sólo dentro del alcance autorizado.

Lecturas relacionadas

Revisión de contratos: 22 de septiembre de 2026. Cobertura del workflow: 12 tipos de nodo, 30 triggers y 24 acciones.