- 1. Resumen Ejecutivo
- 2. Inventario General
- 3. Clasificación por Categoría
- 4. Problema #1 — Fragmentación de Asignación de Agentes
- 5. Problema #2 — Fragmentación de Embudos por Etapa
- 6. Lo que SÍ funciona bien
- 7. Problema #3 — Naming y Nomenclatura
- 8. Chatbot — Estado de Desarrollo
- 9. Score de Redundancia Final
- 10. Plan de Acción Recomendado
1. Resumen Ejecutivo
Se realizó una auditoría exhaustiva de los 191 flujos de automatización (Workflows) configurados en TellBid/GoHighLevel. El análisis revela un problema estructural crítico: fragmentación extrema. El CRM tiene aproximadamente 119 flujos redundantes que podrían consolidarse, lo que representa una reducción posible del 62%.
🔴 Hallazgo Principal
En lugar de usar condicionales (If/Else o Switch) dentro de un flujo maestro, el equipo creó un flujo distinto para cada variación: un flujo por vendedor, un flujo por etapa del embudo, un flujo por sede. Esto genera un sistema insostenible que crece linealmente con cada nuevo empleado o producto.
2. Inventario General
| Indicador | Valor |
|---|---|
| Total de workflows | 191 |
| Activos (publicados) | 161 (84%) |
| Borradores / Inactivos | 30 (16%) |
| Redundantes (podrían consolidarse) | ~119 (62%) |
| Flujos óptimos estimados | ~72 |
3. Clasificación por Categoría
| Categoría | Cantidad | Activos | Severidad |
|---|---|---|---|
| Asignación de agentes | 37 | 31 | 🔴 Crítico — 35 son redundantes |
| Embudos de curso (etapas) | 104 | 100 | 🔴 Crítico — 84 son redundantes |
| Transferencia inter-departamental | 7 | 7 | ✅ Correcto |
| Soporte | 8 | 1 | 🟡 Mayormente borradores, en desarrollo |
| Chatbot / Autorespuesta | 6 | 1 | 🟡 En fase de pruebas |
| Campañas masivas | 8 | 7 | 🟠 Naming inconsistente |
| Limpieza de contactos | 4 | 3 | ✅ Funcional |
| Automatización miscelánea | 4 | 3 | 🟡 Podrían integrarse a embudos |
| Sin nombre / basura | 4 | 0 | 🟠 Eliminar |
| Otros | 9 | 4 | 🟡 Revisar individualmente |
4. Problema #1 — Fragmentación de Asignación de Agentes
4.1 El problema
Existen 37 flujos dedicados exclusivamente a asignar contactos a agentes. La mecánica es idéntica en todos:
- Se le pone una etiqueta al contacto (ej: «Osmary», «Barquisimeto», «Victor»)
- Un workflow individual detecta esa etiqueta
- Asigna al agente correspondiente como propietario del contacto
4.2 Lista de flujos individuales por agente
| Agente / Sede | Estado |
|---|---|
| Adrian Parra | ✅ Activo |
| Andrea Chacin | ✅ Activo |
| Ariadna | ✅ Activo |
| Briggite | ✅ Activo |
| Daniel Colmenarez | ✅ Activo |
| Dayana | ✅ Activo |
| Diany Rivero | ✅ Activo |
| Frederick | ✅ Activo |
| Genesis Forero | ✅ Activo (x2 duplicado) |
| Kerwin Torres | ✅ Activo |
| Luis Briceño | ✅ Activo |
| Maria Escalona | ✅ Activo |
| Maria Fermada Rivero | ✅ Activo |
| Mariangel | ✅ Activo |
| Maximino | ✅ Activo |
| Michelle Mosquera | ✅ Activo |
| Oglayis | ✅ Activo |
| Osmary / Osmary Alvarado | ✅ Activo (x2 duplicado) |
| Samir Acevedo | ✅ Activo |
| Victor | ✅ Activo |
| Barquisimeto | ✅ Activo |
| Caracas | ✅ Activo |
| Maracaibo | 📝 Borrador |
| Margarita | ✅ Activo |
| San Cristóbal | ✅ Activo |
| Valencia | ✅ Activo |
| «Todos» | ✅ Activo |
4.3 ¿Por qué es un problema?
- Escalabilidad cero: Cada nuevo vendedor = crear 1 flujo nuevo + 1 etiqueta nueva. Si contratan 5 vendedores, son 5 flujos más.
- Duplicados reales: Genesis Forero tiene 2 flujos (con mayúscula y minúscula). Osmary también tiene 2 (con y sin apellido).
- Imposible de auditar: Si quieres saber «¿qué agentes están activos?», tienes que revisar 37 flujos uno por uno.
- Naming caótico: Unos dicen «Asignacion» (sin acento, doble espacio), otros «Asignación» (con acento). Unos usan nombre, otros nombre + apellido.
4.4 Solución propuesta
💡 Flujo Maestro de Asignación
1 solo flujo con un Switch/Router interno que lea la etiqueta y asigne al agente correcto. Agregar un vendedor nuevo = agregar 1 rama al Switch. No se crea ningún flujo nuevo.
Opcionalmente: 2 flujos (uno para Ventas, otro para Soporte), cada uno con su propio Router.
5. Problema #2 — Fragmentación de Embudos por Etapa
5.1 El problema
Cada producto o servicio tiene un embudo (pipeline) con múltiples etapas (Nuevo Lead → Información → Especificaciones → Términos → Pedido → Pago → Cerrado). En lugar de tener 1 flujo por producto que reaccione al cambio de etapa, se creó 1 flujo POR CADA ETAPA.
5.2 Embudos identificados y su fragmentación
| Producto / Embudo | Flujos actuales | Flujos óptimos | Exceso |
|---|---|---|---|
| Serie 006 — Post Venta | 15 | 1 | 🔴 14 extra |
| Serie 010 — Recurrente | 11 | 1 | 🔴 10 extra |
| DDV — Despachador de Vuelo | 10 | 1 | 🔴 9 extra |
| Serie 008 — IDEA Tours | 10 | 1 | 🔴 9 extra |
| Serie 012 — (Producto sin identificar) | 9 | 1 | 🔴 8 extra |
| Serie 011 — (Producto sin identificar) | 8 | 1 | 🔴 7 extra |
| TDC — Tripulante de Cabina | 8 | 1 | 🔴 7 extra |
| Serie 007 — Gestión de Pedido | 7 | 1 | 🔴 6 extra |
| Serie 005 — Precios / DDV | 4 | 1 | 🟠 3 extra |
| Serie 003 — Seguimiento / Reclamos | 4 | 1 | 🟠 3 extra |
| Serie 001 — Info Básica / Leads | 3 | 1 | 🟠 2 extra |
| Serie 002 — Soporte / Especificaciones | 3 | 1 | 🟠 2 extra |
| Serie 004 — Términos / Empleo | 3 | 1 | 🟠 2 extra |
| TMA — Técnico de Mantenimiento | 2 | 1 | 🟡 1 extra |
| PPA — Piloto Privado (Serie 01-13) | 13 | 1 | 🔴 12 extra |
| IFR, ING, RPAS, otros | 3 | 3 | ✅ OK (1 cada uno) |
Total: 104 flujos de embudo → podrían ser ~20 (1 por producto). Eso son 84 flujos redundantes.
5.3 Ejemplo concreto: DDV (Despachador de Vuelo)
El DDV tiene 10 flujos activos, uno para cada etapa del embudo:
DDV-009-01-Información Básica ← Flujo #1
DDV-009-02-Recurrente ← Flujo #2
DDV-009-03-Especificaciones ← Flujo #3
DDV-009-04-Precios y Ofertas ← Flujo #4
DDV-009-05-Términos y condiciones ← Flujo #5
DDV-009-06-Registro y pedido ← Flujo #6
DDV-009-07-Gestión de pedido ← Flujo #7
DDV-009-08-Esperando pago ← Flujo #8
DDV-009-09-Cerrado Ganado ← Flujo #9
DDV - Despachador de vuelo ← Flujo #10 (¿el maestro?)
💡 Solución
1 solo flujo con trigger Pipeline Stage Changed y un Router/Switch interno que ejecute la acción correspondiente según la etapa a la que se mueve el contacto.
6. Lo que SÍ funciona bien
6.1 Transferencias inter-departamentales ✅
Los 7 flujos de transferencia están bien diseñados y son necesarios. Cada uno enruta al departamento correcto:
- ✅ Transferencia a la Aerotienda
- ✅ Transferencia a administración
- ✅ Transferencia a gestión de vuelo
- ✅ Transferencia a planificación
- ✅ Transferencia a diseño
- ✅ Transferencia a RR.HH
- ✅ Transferencia a ventas
6.2 Limpieza de contactos ✅
Los flujos de limpieza (cliente cerrado, contacto spam, contacto no útil) son correctos y necesarios para mantener higiene en la base de datos.
7. Problema #3 — Naming y Nomenclatura
| Tipo de error | Ejemplos | Cantidad |
|---|---|---|
| Dobles espacios | «Automatizacion de DDV», «TDC – 001 Tripulante – v20 – 2» | 18 |
| Sin nombre | «New Workflow : 1767043813614» | 4 |
| Copias sin renombrar | «Copy – Soporte de CIA (Desarrollo) 1» | 1 |
| Números sueltos al final | «TMA -001 Curso Regular 2», «RPAS (Drones) 2» | 15 |
| Mezcla mayúsculas/minúsculas | «genesis forero» vs «Genesis Forero» | Múltiples |
| Prefijo duplicado | «Osmary» y «Osmary Alvarado» son la misma persona | 2 |
8. Chatbot — Estado de Desarrollo
Se identificaron 6 flujos relacionados con chatbot/autorespuesta, de los cuales 5 están en borrador (en pruebas):
| Flujo | Estado | Observación |
|---|---|---|
| Recepcionista Virtual Instituto IDEA | 📝 Borrador | El flujo principal del chatbot |
| Responder Pregunta de Curso Aeronáutico | 📝 Borrador | FAQ automatizado de cursos |
| BOT DE AUTORESPUESTA – TEXTO – EJEMPLO 1 | 📝 Borrador | Plantilla de prueba |
| BOT DE AUTORESPUESTA – PLANTILLA DE OPCIONES | 📝 Borrador | Plantilla con menú de opciones |
| Respuestas automáticas | 📝 Borrador | Flujo genérico de autorespuesta |
| Hack de Instagram | ✅ Activo | Captación de leads por Instagram |
ℹ️ Nota
Esto confirma lo que indicó Pedro: el equipo de desarrollo está haciendo pruebas con el chatbot, activándolo y desactivándolo. No está listo para producción aún.
9. Score de Redundancia Final
| Categoría | Flujos actuales | Flujos óptimos | Reducción |
|---|---|---|---|
| Asignación de agentes | 37 | 2 | -35 (95%) |
| Embudos por etapa | 104 | 20 | -84 (81%) |
| Sin nombre (basura) | 4 | 0 | -4 (100%) |
| TOTAL | 145 | 22 | -123 flujos |
⚠️ Impacto operativo
Con 191 flujos, el panel de Workflows de TellBid es prácticamente innavegable. Encontrar un flujo específico requiere scroll extenso. Cualquier cambio de lógica (ej: «agregar un paso de confirmación») debe replicarse manualmente en cada flujo afectado, multiplicando el riesgo de error.
10. Plan de Acción Recomendado
| Prioridad | Acción | Impacto | Esfuerzo |
|---|---|---|---|
| 🔴 1 | Crear Flujo Maestro de Asignación de Agentes (reemplaza 37 flujos) | Máximo | Medio |
| 🔴 2 | Consolidar embudos: 1 flujo por producto con Router por etapa | Máximo | Alto |
| 🟠 3 | Eliminar los 4 flujos «New Workflow» sin nombre | Bajo | Mínimo |
| 🟠 4 | Estandarizar nomenclatura de todos los flujos | Medio | Bajo |
| 🟡 5 | Resolver duplicados (Genesis Forero x2, Osmary x2) | Medio | Bajo |
| 🟡 6 | Activar y consolidar flujos de Chatbot cuando esté listo | Alto | Medio |
Auditoría realizada por el equipo técnico de IDEA Aviation · Junio 2026
Datos obtenidos en tiempo real de la API de GoHighLevel (191 workflows analizados). Todos los flujos son verificables en el panel de Workflows de TellBid.
