Enriquecimiento B2B y Enrutamiento de Leads VIP

¿Qué hace este flujo y qué problema resuelve?

Resumen ejecutivo: Este flujo automatiza la captura, enriquecimiento y enrutamiento de leads B2B entrantes para priorizar cuentas estratégicas (VIP) y reducir el tiempo hasta el primer contacto. Resuelve dos problemas concretos: desperdicio de esfuerzo comercial en cuentas no cualificadas y demora en la atención de cuentas estratégicas que generan alto valor.

Problema detallado: En equipos de ventas con recursos limitados, los leads entrantes se tratan con la misma prioridad independientemente de su potencial. Como resultado, los comerciales pierden tiempo en oportunidades de bajo valor y las cuentas de alto valor esperan horas o días para ser contactadas. El coste de oportunidad se traduce en tasas de conversión más bajas y pérdidas de ingresos evitables.

Solución técnica y operativa: Implementar un flujo en n8n que haga lo siguiente de forma automática y auditable:

• Capturar el lead desde el formulario web mediante un nodo Webhook.
• Extraer el dominio del correo corporativo y validar formato y existencia.
• Consultar un proveedor de enriquecimiento (Apollo.io por defecto, con alternativa Clearbit) para obtener tamaño de empresa, facturación estimada, sector y datos de contacto corporativo.
• Aplicar reglas de negocio definidas por Dirección Comercial para determinar si el lead es VIP.
• Enrutar el lead VIP de forma inmediata al comercial asignado y generar alertas por Slack o SMS; crear o actualizar el registro en el CRM.

Flujo simplificado: Webhook formulario web -> Extracción dominio -> Enriquecimiento Apollo -> Switch VIP/General -> CRM + Alerta urgente.

Impacto esperado: Leads VIP contactados en menos de 5 minutos, reducción de tiempo perdido en leads no cualificados, mejora en tasa de conversión para cuentas de alto valor y trazabilidad completa del proceso.

Ejemplo concreto: La empresa ficticia Innovar Logistics S.L. recibe un formulario con email 'ana.rios@innovarlogistics.com'. El flujo detecta que la empresa supera los umbrales de facturación y empleados definidos por Dirección Comercial, la marca como VIP, asigna el lead al ejecutivo 'María López' y envía un SMS con plantilla que incluye nombre, empresa y datos clave.

Cuándo usar este flujo

Prerrequisitos

Requisitos técnicos y de negocio previos al despliegue:

• Cuenta n8n hospedada o en la nube con acceso a ejecutar Workflows y nodos HTTP Request, Webhook, Function, Switch, Set, y nodos específicos para CRM y comunicación (HubSpot/Salesforce/Slack/Twilio).
• Credenciales y llaves API: Apollo.io (o Clearbit), CRM (API user con permisos de escritura y búsqueda), Slack webhook o token, Twilio para SMS si se usará SMS.
• Formulario web configurado con campo de email corporativo obligatorio y validación básica. Campos mínimos recomendados: nombre contacto, email corporativo, teléfono, país, producto/interés, fuente.
• Política de privacidad y consentimiento: incluir aviso de tratamiento de datos y aceptación explícita para llamadas comerciales si aplica a jurisdicciones como la UE. Mantener registro del consentimiento en el CRM.
• Lista inicial de criterios VIP definida por Dirección Comercial: umbral de facturación, empleados, sectores prioritarios, lista de cuentas excluidas y asignaciones por equipo/comercial.
• Plan de pruebas y entorno sandbox: preparar pruebas con registros ficticios y dominios de prueba para validar flujo sin impactar datos reales.
• Mecanismo de rate limiting y caching: conocer límites de API de proveedor de enriquecimiento y definir cache (p. ej. Google Sheets, Redis o Airtable) para evitar consultas duplicadas a dominios ya enriquecidos.

Configuración n8n recomendada:

• Nodo Webhook: método POST, responseMode 'onReceived', path '/webhook/lead-inbound'.
• Nodo HTTP Request para Apollo: credencial guardada como 'ApolloAPI' en n8n, cabecera 'Authorization: Bearer [APOLLO_API_KEY]'.
• Credenciales CRM: usuario API con ámbito mínimo necesario para crear/actualizar contactos y cuentas.
• Configuración de alertas: Slack App con permiso de chat.write o cuenta Twilio con número verificado.

Ejemplo de cuentas y permisos ficticios:

• n8n hospedado en 'platform-ops.local' con workflow 'vip-enrichment'.
• Credencial Apollo guardada como 'Apollo_Cred'.
• CRM: HubSpot API key 'hs_test_abc123' con usuario 'revops_automation'.

Checklist previo al primer despliegue:

1. Registrar endpoints de prueba en formulario web y verificar entrega a webhook.
2. Confirmar acceso API y realizar una llamada de prueba a Apollo in sandbox.
3. Validar creación de lead en CRM en entorno de pruebas.
4. Definir runbook para errores críticos y responsables operativos.

Definición de criterios VIP

Explicación detallada del paso: La definición de criterios VIP es la base del enrutamiento. Dirección Comercial debe traducir la estrategia de cuentas a reglas cuantificables que se puedan aplicar de forma automática. Estas reglas normalmente combinan dimensiones como facturación estimada, número de empleados, sector industrial, presencia geográfica y señales de intención (p. ej. interés en producto enterprise).

Elementos de la regla VIP:

• Umbral de facturación: valor mínimo anual estimado. Ejemplo: >= 10 000 000 EUR.
• Empleados: umbral mínimo, p. ej. >= 200 empleados.
• Sectores prioritarios: lista de NAICS/SIC o etiquetas internas, p. ej. 'manufactura', 'logística', 'ecommerce enterprise'.
• Cuenta en lista blanca/negra: lista manual de cuentas de alto valor o cuentas prohibidas.
• Señales de intención: descarga de whitepaper enterprise, campo 'interés' marcado como 'implementación global'.

Configuración específica de nodos n8n:

1. Nodo 'Set' inicial: añadir variables de referencia que provienen de la configuración de negocio. Campos sugeridos en 'Set': 'vip_revenue_min' = 10000000, 'vip_employees_min' = 200, 'vip_sectors' = ['manufacturing','logistics','transport']. Este nodo sirve para centralizar parámetros y facilitar cambios sin tocar código.
2. Nodo 'Function' o 'IF' para evaluación: crear un nodo 'Function' con lógica JS que reciba el resultado de enriquecimiento y devuelva campo 'isVIP' booleano. Ejemplo de código en nodo Function (copiable):

   const data = items[0].json; const revenue = data.enrichment?.annual_revenue || 0; const employees = data.enrichment?.employee_count || 0; const sector = (data.enrichment?.industry || '').toLowerCase(); const vipRevenue = $json['vip_revenue_min']; const vipEmployees = $json['vip_employees_min']; const vipSectors = $json['vip_sectors']; const inSector = vipSectors.includes(sector); const isVIP = (revenue >= vipRevenue && employees >= vipEmployees) || inSector; return [{ json: {...data, isVIP}}];

3. Nodo 'Switch' para control operativo: use un 'Switch' en n8n para separar camino VIP y General.

Consideraciones técnicas y de negocio:

• Precisión de datos: los proveedores de enriquecimiento estiman facturación; defina tolerancias para evitar false positives.
• Umbrales dinámicos: permita ajustes por temporada o segmento. Mantenga los valores en una fuente editable (Google Sheet, Airtable) y lea desde n8n en lugar de hardcodearlos.
• Fallbacks: si no hay datos de enriquecimiento, definir política: tratar como General o poner en cola de revisión manual.
• Auditoría: registre la decisión VIP en el CRM y en un log central con metadatos de la consulta a proveedor y confianza del dato.

Ejemplo concreto:

Dirección Comercial de la empresa ficticia InnovaTech S.A. define: vip_revenue_min = 15000000 EUR, vip_employees_min = 300, vip_sectors = ['manufacturing','healthcare']. Un lead con enriquecimiento que muestra revenue = 18 000 000 EUR y employees = 420, sector 'manufacturing' será marcado como isVIP = true. El flujo asignará este lead al ejecutivo 'Carlos Ruiz' según reglas de asignación de VIPs.

Captura del lead y extracción del dominio

Explicación detallada del paso: La captura inicial del lead se realiza mediante un nodo Webhook que recibe el POST desde el formulario web. El objetivo clave en este paso es validar el email, extraer el dominio corporativo y prevenir entradas inválidas o spam antes de hacer llamadas a proveedores de enriquecimiento.

Configuración específica de nodos n8n:

1. Nodo 'Webhook': configurar método POST, path '/webhook/lead-inbound', responseMode 'onReceived' para devolver un 200 inmediato al formulario. Mapear los campos entrantes: name, email, phone, company, country, interest.
2. Nodo 'Set' post-webhook: normalizar campos (trim, lowercase en email), añadir timestamp 'received_at' = new Date().toISOString().
3. Nodo 'Function' para extracción de dominio: usar una función JS con regex robusta que maneje subdominios y alias. Ejemplo de código para nodo Function (copiable):

   const email = items[0].json.email || ''; const match = email.toLowerCase().trim().match(/@([a-z0-9.-]+)$/i); const domain = match ? match[1].replace(/^www\./,'') : null; return [{ json: {...items[0].json, domain }}];

4. Nodo 'HTTP Request' opcional para validación DNS/MX: realizar consulta a un servicio de verificación (p. ej. mailgun validation API) para comprobar que el dominio acepta correo. Esto reduce consultas innecesarias a proveedores de enriquecimiento.
5. Nodo 'IF' para deduplicación: buscar en CRM si ya existe contacto con mismo email o dominio usando nodo de búsqueda del CRM; si existe, actualizar en lugar de crear. Evite duplicados que consumen llamadas de API.

Consideraciones técnicas y de negocio:

• Formularios: obligar campo 'email corporativo' y aplicar validación en frontend para evitar correos genéricos como gmail o hotmail. Sin embargo, algunos leads de empresas usan correos genéricos; defina política sobre cómo tratarlos (por defecto, considerar General o poner en revisión manual).
• Seguridad y privacidad: cifre el transporte con HTTPS, registre solo lo necesario y mantenga el consentimiento. No enviar datos confidenciales a proveedores sin revisar cláusulas de procesamiento de datos.
• Manejo de subdominios: dominios como 'sales.uk.example.com' deben normalizarse a 'example.com'. Use una lista pública de dominios de nivel superior cuando sea necesario.
• Rendimiento: realizar la extracción y validación localmente antes de la llamada a Apollo para minimizar latencia y costes por llamada de API.

Ejemplo concreto:

Lead entrante de la empresa ficticia 'Acuarela Logistics' llega con email 'juan.perez@ops.acuarela-logistics.com'. El nodo Function extrae y normaliza dominio a 'acuarela-logistics.com'. El nodo de validación DNS confirma registros MX activos. El flujo continúa a enriquecimiento. Si el dominio fuese 'juan.perez@gmail.com', el nodo IF marcaría el lead como 'mail_public' y lo pondría en ruta General o en revisión manual según la política.

Enriquecimiento de datos con Apollo.io

Explicación detallada del paso: El enriquecimiento aporta contexto empresarial necesario para decidir si un lead es VIP. Apollo.io ofrece datos como employee_count, estimated_revenue, industry, linkedin_url y cargos relevantes. El flujo debe gestionar fallbacks, caché y límites de API.

Configuración específica de nodos n8n:

1. Nodo 'HTTP Request' para Apollo: método POST o GET según el endpoint. Usar credencial guardada 'Apollo_Cred' en n8n. Cabeceras recomendadas en el nodo: 'Authorization' = 'Bearer [APOLLO_API_KEY]'; 'Content-Type' = 'application/json'. Request body ejemplo (copiable):

   { 'query': { 'domain': '[DOMAIN]' }, 'fields': ['employee_count','estimated_revenue','industry','headquarters'] }

2. Nodo 'Function' para normalización: mapear la respuesta JSON de Apollo a campos estándar del proceso: enrichment.employee_count, enrichment.annual_revenue, enrichment.industry, enrichment.source = 'apollo'. Convertir strings numéricas a números y manejar nulos.
3. Caching: nodo 'Google Sheets' o 'Redis' para consultar si ya existe un registro enriquecido para ese dominio en las últimas 30 días. Si existe, utilizar el cache en lugar de llamar a Apollo.
4. Manejo de errores y retry: En caso de 429 o 5xx, implementar reintentos exponenciales con nodo 'Wait' y registro en log de incidentes.

Consideraciones técnicas y de negocio:

• Rate limits: conocer límites de la cuenta Apollo y establecer límites en n8n para no superar el throughput. Agrupar llamadas y usar caching para dominios recurrentes.
• Calidad de datos: Apollo devuelve estimaciones; registrar nivel de confianza y la fecha del dato en CRM para auditoría.
• Fallbacks: si Apollo no devuelve datos, intentar una petición a Clearbit o a un servicio interno de datos; si todo falla, marcar lead como 'Enriquecimiento fallido' y derivar a revisión manual.
• Costes: cada llamada tiene coste; priorice llamadas únicamente a dominios que superen validaciones previas (p. ej. dominios corporativos no públicos).

Ejemplo concreto y mapeo de respuesta:

Solicitud con domain = 'acuarela-logistics.com'. Apollo responde con employee_count = 320, estimated_revenue = 22000000, industry = 'Logistics and Supply Chain', headquarters = 'ES'. El nodo Function normaliza y produce:

{ 'enrichment': { 'employee_count': 320, 'annual_revenue': 22000000, 'industry': 'logistics', 'hq_country': 'ES', 'source': 'apollo', 'retrieved_at': '2026-07-15T10:12:00Z' } }

Este objeto se envía al nodo de decisión VIP. Registre también el raw_response en un almacén de logs para auditoría.

Enrutamiento y creación en CRM

Explicación detallada del paso: Una vez decidido 'isVIP', el flujo debe ejecutar acciones diferenciadas: ruta VIP con respuesta inmediata y asignación a comercial específico; ruta General con creación en CRM y workflow de nutrición automatizada.

Configuración específica de nodos n8n para ruta VIP:

1. Nodo 'Switch': condición isVIP == true dirige al camino VIP.
2. Nodo 'Function' para asignación de propietario: lógica que puede ser estática (mapa sector -> comercial), por carga (round-robin) o por territorio. Ejemplo de función para asignación estática (copiable):

   const sector = (items[0].json.enrichment.industry || '').toLowerCase(); const assignments = { 'logistics':'carlos.ruiz', 'manufacturing':'maria.lopez' }; const owner = assignments[sector] || 'default_owner'; return [{ json: {...items[0].json, owner } }];

3. Nodo 'CRM - Create/Update Contact' (HubSpot/Salesforce): buscar contacto por email; si existe actualizar con campos de enriquecimiento y añadir nota 'VIP - Enrutado automáticamente'; si no existe crear contacto, cuenta y asociación. Campos clave a escribir: owner, lead_status = 'new', lead_source = 'web_form', enrichment_metadata.
4. Nodo 'Alert' (Slack or Twilio): enviar mensaje urgente al comercial asignado. Plantillas copiables:

Plantilla Slack (copiable):

Nuevo lead VIP: [NOMBRE_CONTACTO] - [EMPRESA] ([DOMINIO]) Datos clave: empleados=[EMPLOYEES], facturación=[REVENUE] Owner asignado: [OWNER]. Contactar en < 5 min.

Plantilla SMS (copiable):

VIP Lead: [NOMBRE_CONTACTO] - [EMPRESA]. Empleados=[EMPLOYEES] Facturación=[REVENUE]. Contactar ya. Detalles en CRM: [CRM_LINK]

Configuración específica para ruta General:

• Crear/actualizar lead en CRM con etiqueta 'general' y asignación a pool general.
• Disparar una automatización de nutrición por email en el CRM y crear tarea de seguimiento con prioridad baja.

Consideraciones técnicas y de negocio:

• Disponibilidad del CRM: comprobar límites de API y latencia; usar operaciones 'upsert' para evitar duplicados.
• Asignación inteligente: si el comercial asignado está de vacaciones, integrar con calendario corporativo o un estado en una hoja de control para fallback automático.
• Pruebas: crear reglas de test para forzar la ruta VIP y validar alertas en Slack/Twilio sin alertar a comerciales reales (usar entorno de pruebas o usuarios de test).

Ejemplo concreto:

Lead VIP de 'InnovaTech S.A.' con owner = 'maria.lopez'. El nodo CRM crea cuenta 'InnovaTech S.A.' y contacto 'Ana Rios', asigna owner 'maria.lopez' y añade nota: 'VIP - Enriquetado vía Apollo 2026-07-15'. El nodo Slack envía mensaje al canal privado de María con la plantilla con variables sustituidas. Si el intento de creación en CRM falla por 409 conflict, el flujo registra error y reintenta según política.

Output esperado del flujo

Resultado operativo esperado: Para cada lead entrante, el workflow debe producir una de las salidas siguientes con trazabilidad completa:

• Lead VIP en CRM creado/actualizado, owner asignado, alerta enviada al comercial en menos de 5 minutos.
• Lead General en CRM creado/actualizado y encolado en automatización de nutrición.
• Logs de enriquecimiento con raw_response y score de confianza almacenados para auditoría.

Métricas clave de output:

• Tiempo medio hasta alerta comercial para VIPs: < 5 minutos.
• Porcentaje de leads enriquecidos con datos válidos: objetivo > 85%.
• Tasa de error en llamadas a proveedor: objetivo < 2% tras reintentos.
• Tasa de duplicados detectados y evitados: objetivo > 95%.

Ejemplo concreto de output JSON que se registra en sistema de logs y se asocia al lead en CRM (ficticio):

{ 'lead_id': 'tmp-12345', 'name': 'Ana Rios', 'email': 'ana.rios@innovatech.com', 'domain': 'innovatech.com', 'isVIP': true, 'enrichment': { 'employee_count': 420, 'annual_revenue': 18000000, 'industry': 'manufacturing', 'hq_country': 'ES', 'source': 'apollo', 'retrieved_at': '2026-07-15T10:12:00Z' }, 'assigned_owner': 'maria.lopez', 'crm_record': { 'crm_system': 'hubspot', 'contact_id': 'hs_98765', 'company_id': 'hs_c_54321' }, 'alerts_sent': { 'slack': true, 'sms': true }, 'timestamps': { 'received_at': '2026-07-15T10:11:45Z', 'enriched_at': '2026-07-15T10:12:00Z', 'assigned_at': '2026-07-15T10:12:10Z' } }

Qué registrar en CRM como campos mínimos:

• Owner asignado
• isVIP boolean
• employee_count y annual_revenue
• enrichment_source y enrichment_retrieved_at
• lead_source original y fecha de recepción

Auditoría y reporting: Exportar diariamente un reporte con número de VIPs detectados, tiempos de atención y conversiones por bucket para evaluar impacto comercial.

Problemas frecuentes y cómo resolverlos

Resumen: A continuación se listan errores frecuentes, síntoma, causa habitual y pasos de resolución.

• Error 1 - Webhook no recibe formularios
  • Síntoma: No llegan registros al workflow; formulario muestra 200 OK pero n8n no recibe datos.
  • Causa: Ruta de webhook mal configurada, firewall o CORS bloqueando, o formulario apuntando a endpoint anterior.
  • Solución: Verificar path exacto del nodo Webhook en n8n, revisar logs del servidor, probar con curl POST al endpoint, comprobar reglas de firewall y que la URL pública esté actualizada en el formulario.
• Error 2 - Apollo responde 401 o credenciales rechazadas
  • Síntoma: HTTP Request devuelve 401 Unauthorized o 403 Forbidden.
  • Causa: API key caducada, rol de la cuenta limitado o header Authorization mal formado.
  • Solución: Validar la API key en el portal de Apollo, renovar credenciales si es necesario y actualizar la credencial en n8n; comprobar que la cabecera Authorization use formato 'Bearer [API_KEY]'.
• Error 3 - Dominio no encontrado o datos absent
  • Síntoma: Enriquecimiento devuelve nulls o sin employee_count/revenue.
  • Causa: Dominio demasiado nuevo, uso de alias, correo personal o proveedor sin datos para ese dominio.
  • Solución: Implementar fallback a búsqueda por empresa o LinkedIn, marcar lead para revisión manual o ponerlo en ruta General. Añadir cache de dominios fallidos para evitar repetición.
• Error 4 - Rate limit 429 en proveedor de enriquecimiento
  • Síntoma: Múltiples respuestas 429 y llamadas fallidas.
  • Causa: Exceso de llamadas concurrentes que superan cuota de la cuenta.
  • Solución: Implementar cola con backoff exponencial en n8n (nodo 'Wait' + reintentos), establecer caching para dominios ya consultados y negociar límites con proveedor si la demanda es legítima.
• Error 5 - Duplicados en CRM o conflicto 409
  • Síntoma: Creación de registros duplicados o respuesta 409 Conflict del CRM.
  • Causa: Búsqueda insuficiente antes de crear, claves de deduplicación mal definidas (email vs dominio).
  • Solución: Antes de crear, hacer búsqueda por email y por dominio; en caso de conflicto usar operación upsert si el CRM lo soporta; mantener una clave única en CRM (email o external_id) y registrar en logs los intentos y resoluciones.

Runbook operativo rápido:

1. Prioridad alta: errores de webhook o credenciales - revisar y corregir en menos de 1 hora.
2. Prioridad media: enriquecimiento con baja calidad - analizar tasa y activar fallback manual.
3. Prioridad baja: ajustes de parámetros VIP - planificar cambios y pruebas en entorno staging antes de producción.

Ejemplo práctico: Si 'Acuarela Logistics' no obtiene datos en Apollo, revisar el dominio, intentar Clearbit y si ambos fallan marcar isVIP = false temporalmente y crear tarea en CRM para que un SDR realice verificación manual al día siguiente.

Adaptaciones del flujo para otros contextos

Este flujo puede adaptarse a distintos modelos comerciales y requisitos regulatorios. A continuación se proponen variantes concretas y su configuración sugerida.

• Ruta multiregión y compliance local: Cuando opera en varios países, enriada y enrutar según país de la sede. Añadir en n8n un nodo 'Function' que mapee hq_country a equipo regional y aplicar reglas de privacidad para UE (p. ej. conservar menos campos, marcar consentimiento). Integrar verificación de consentimiento y anotar la base legal en CRM.
• Uso de Clearbit como alternativa: Cambiar el nodo 'HTTP Request' para apuntar al endpoint de Clearbit, con cabecera 'Authorization: Bearer [CLEARBIT_KEY]'. Mantener la capa de normalización para que el campo enrichment tenga la misma estructura, de forma que el resto del workflow no cambie.
• Batch enrichment nocturno: Para empresas con muchas entradas diarias, hacer enriquecimiento prioritario solo para dominios nuevos en tiempo real y ejecutar un batch nocturno para el resto. Implementación: guardar leads en Google Sheets y ejecutar un workflow cron que procese filas pendientes con límites controlados.
• Integración con ABM y cuentas objetivo: Si existe una lista de cuentas objetivo (ABM), priorizar automáticamente cualquier lead cuyo dominio coincida con esa lista aunque no cumpla umbrales. Mantener la lista en Airtable y consultar antes del enriquecimiento.
• Telefonía inmediata para VIPs: Añadir integración con el sistema de telefonía (p. ej. Aircall) para crear una llamada saliente automática o generar popup en el teléfono del comercial cuando llegue VIP. Requiere nodo HTTP hacia la API de telefonía y programación de IVR si procede.

Ejemplo de adaptación para PYMES B2B:

La empresa ficticia 'Soluciones PyME S.A.' vende a pymes y quiere priorizar leads por señal de intención más que por tamaño. Ajuste: sustituir criterios de employee_count y revenue por campos conductuales como 'request_demo' y 'budget_estimated > 20000'. El resto del flujo permanece, pero el nodo Function que decide isVIP cambia las condiciones.

¿Qué hacer ahora?

Plan de pasos inmediatos para puesta en marcha:

1. Reunión de una hora entre Dirección Comercial y RevOps para definir y acordar los criterios VIP y la lista inicial de asignaciones por sector/territorio.
2. Provisionar credenciales: crear y validar API keys en Apollo (o Clearbit), CRM y Twilio/Slack. Guardar como credenciales en n8n.
3. Implementación en staging: desplegar workflow en entorno de pruebas y validar con 10 casos ficticios que cubran VIP, General, dominio público y errores.
4. Pruebas de carga y límites: simular ráfagas de leads para verificar rate limiting y comportamiento en cola.
5. Despliegue controlado en producción y monitorización durante las primeras 72 horas con alerta a RevOps para intervenciones manuales.
6. Definir KPIs y tablero: tiempo hasta primer contacto VIP, tasa de conversión VIP vs General, coste por llamada de enriquecimiento. Revisiones semanales las primeras 4 semanas y luego mensual.

Checklist final antes de producción:

• Webhook operativo y SSL en orden
• Credenciales validadas y almacenadas
• Pruebas de enriquecimiento satisfactorias
• Definida política de fallback para enriquecimiento fallido
• Runbook y responsables asignados

Ejemplo de primer hito: Para la empresa ficticia Innovar Corp., objetivo inicial identificar y contactar 50 VIPs en 30 días y reducir tiempo medio de contacto de 12 horas a < 5 minutos para ese segmento.