GHL ClickUp Task Builder
Transforma workflows de GHL en tareas estructuradas en ClickUp. Cada workflow se convierte en una tarea padre con contexto completo + subtareas atómicas donde cada subtarea = un nodo en el builder de GHL.
Modos de operación — verificación vs. from-scratch
La skill opera en dos modos según el contexto. Detectar el modo antes de empezar.
Modo A — Cliente existente / Adición a cuenta viva
Cuando se generan tareas para una cuenta GHL ya implementada y la tarea menciona pipelines, campos, asesores o calendarios que se asume que ya existen.
Pre-flight check obligatorio:
-
Leer references/ghl-api-capabilities.md
— saber qué se puede crear vía API/MCP y qué requiere implementación manual.
-
Pullear el snapshot vivo (ver
references/ghl-live-context-template.md
):
mcp__ghl__opportunities_get-pipelines
mcp__ghl__locations_get-custom-fields
mcp__ghl__locations_get-location
GET /users/?locationId=...
GET /calendars/?locationId=...
-
Validar cada referencia por nombre contra el snapshot. Si el input menciona "Pipeline Residencial" o "campo Tipo de Cliente" o "asignar a Carlos", confirmá que existe antes de escribir la subtarea. Si no existe:
- Avisar al usuario y ofrecer: (A) crear el recurso ahora, (B) corregir el nombre, (C) marcarlo como .
Modo B — Cliente nuevo / Implementación desde cero
Cuando se está armando un cliente desde cero, o cuando el usuario pasa un mapeo previo de implementación, o cuando explicita "es un cliente nuevo / desde cero / cliente testeo".
No hace falta validar que las cosas existan — se crean como parte de la implementación.
-
Sí leer references/ghl-api-capabilities.md
— para saber cuáles tareas son ejecutables vía API y cuáles son manuales (workflows, funnels, etc.).
-
No es necesario pullear el snapshot completo. Como mucho, leer el
para confirmar timezone si la implementación incluye calendarios o mensajería con horarios.
-
Pipelines, custom fields, calendarios, stages, tags se crean como parte de las tareas de implementación. Marcar con
las que se ejecutan vía API antes que el WF.
Cómo detectar el modo
| Señal | Modo |
|---|
| Usuario dice "cliente nuevo", "desde cero", "cliente testeo", "primera implementación", "snapshot inicial" | B |
| Usuario pasa un mapeo o roadmap pre-armado (ej: output de ) | B |
| Usuario menciona dependencias por nombre y asume que existen | A |
| Usuario dice "agregar al WF existente", "modificar X", "este cliente ya tiene Y" | A |
| Si hay duda → preguntar al usuario antes de empezar | — |
Clasificación de operaciones (en cualquier modo)
Por cada operación que la tarea propone:
- ✅ Automatizable vía API/MCP → puede ejecutarse desde la skill (ahora o en Fase 2)
- 🔧 SETUP previo → recursos a crear antes del WF (pipelines, fields, calendarios) — automatizables
- ⚠️ MANUAL → workflows, funnels, forms, configuraciones de Conversation AI, integraciones OAuth — el implementador lo arma a mano siguiendo la subtarea
Principio central: 1 subtarea = 1 acción atómica
El nombre de la subtarea ES la instrucción. La descripción tiene dos secciones fijas y obligatorias:
- → qué configurar exactamente (tabla de campos y valores). Esto es lo que el implementador ejecuta.
- → por qué existe ese nodo, cómo se conecta con otros workflows, qué pasa antes y después. Esto es referencia, no instrucción.
❌ MAL — subtarea agrupada o sin estructura:
Nombre: ⚡ Acciones
Descripción: ACCIÓN 1 - Update Canal... ACCIÓN 2 - Update Área... ACCIÓN 3 - If/Else...
Nombre: Guard IF: Fecha de primer contacto está vacía
Descripción: Nodo IF. Si está vacío continúa, si no salta.
(sin separar qué hacer de por qué hacerlo)
✅ BIEN — subtarea atómica con secciones:
Nombre: Guard IF: Fecha de primer contacto está vacía
## Acción en GHL
| Campo GHL | Valor |
|-----------------|-------------------------------|
| Action type | IF / Else |
| Condition object| Contact |
| Field | Fecha de primer contacto |
| Operator | is empty |
| Rama TRUE | Continúa → nodo siguiente |
| Rama FALSE | Salta al nodo Crear oportunidad|
## Contexto
Protege contra re-entradas. Si el contacto ya existe en el CRM y
vuelve a escribir, este Guard evita pisar su fecha original de primer
contacto. Sin este nodo, los reportes de tiempo de conversión quedan
contaminados con fechas incorrectas.
Regla sobre qué va en cada sección:
| ¿Qué tipo de contenido? | Sección |
|---|
| Tabla de configuración GHL (campos, valores, opciones) | |
| Paso a paso para encontrar el nodo en la UI | |
| Por qué existe este nodo | |
| Qué workflow lo precede o lo sigue | |
| Qué pasa si no se configura | |
| Relación con otros WF (SP01, WF08, etc.) | |
| Diagrama visual del flujo (rama TRUE/FALSE) | |
Flujo de trabajo
Paso 1: Recibir el input
- Output de , descripción manual, o tarea existente a reescribir
- Si hay ambigüedad, preguntar antes de crear
Paso 2: Confirmar List ID
Si no se conoce: "¿List ID de ClickUp? Es el número al final de la URL de la lista."
Paso 3: Construir la tarea padre
Descripción de la tarea padre con estas secciones:
Descripción — qué hace, por qué existe
Trigger — nombre exacto + canal/pipeline/etapa
Guards de entrada — IF de detención antes de cualquier acción (si aplica)
Lógica / Branches — resumen de If/Else (si aplica)
Dependencias — qué debe existir antes de activar
Orden de activación — si depende de otro WF activo primero
Paso 4: Descomponer en subtareas atómicas
Un nodo en GHL = una subtarea en ClickUp:
| Nodo GHL | → Subtarea |
|---|
| Trigger | Trigger: [nombre] ([canal/etapa])
|
| Guard IF de detención | Guard IF: [condición] → STOP
|
| Update Contact/Opportunity Field | Update Field: [campo] = [valor]
|
| If/Else con branches | IF: [condición] → [rama TRUE] / [rama FALSE]
|
| Send Message | Send [WhatsApp/SMS/Email]: "[primeras palabras del mensaje]"
|
| Wait | Wait: [duración] / Wait Until: [campo fecha]
|
| Add/Remove Tag | |
| Create Opportunity | Crear oportunidad → [etapa]
|
| Webhook → n8n | Webhook → n8n: [nombre_accion]
|
| Assign to User | Assign to User: [Round Robin / Owner / nombre]
|
| End Workflow | (solo si hay múltiples salidas) |
Guía de UI — Valores exactos por tipo de nodo
Interfaz de GHL en español. Usar estos términos exactos.
Update Contact Field
Tipo de acción: "Actualizar datos de campo"
→ Clickeá "Añadir Campo"
→ Dropdown campos: Standard Fields (arriba) / Custom fields (hacer scroll abajo)
→ Seleccionar: [nombre exacto del campo]
→ Valor:
Dropdown → seleccionar: [valor exacto]
Text → escribir: [valor]
Date → ícono 🏷️ → Contact Created At (para "now")
If / Else
→ Clickeá "Añadir filtros"
→ Tipo: Contacto / Oportunidad
→ Campo: [nombre]
→ Condición: está vacío / es igual a / contiene / no está vacío
→ Valor: [si aplica]
Branch SÍ = condición cumplida
Branch NONE = no cumplida (equivale al Else)
Crear oportunidad (nueva — NO la deprecada)
⚠️ "Crear O Actualizar Oportunidad" está DEPRECADA (banner naranja). Usar "Crear oportunidad".
→ IN SECUENCIA → [pipeline]
→ IN SECUENCIA PASO → [etapa exacta]
→ Nombre → ícono 🏷️ → First Name + Last Name
→ Fuente → texto libre: "Widget Web" / "WhatsApp" / "Instagram"
Send Message
→ Canal: WhatsApp / SMS / Email
→ Tipo: Template aprobado / Mensaje libre
→ Texto: [mensaje exacto]
→ Usar ícono 🏷️ para insertar nombre: First Name
Wait
Wait fijo: duración en días/horas desde ejecución del paso
Wait Until Date: ícono 🏷️ → campo de fecha → + offset si aplica
Add/Remove Tag
→ Tag: [nombre exacto, sensible a mayúsculas/minúsculas]
Webhook → n8n
→ Acción: Webhook
→ URL: Custom Value con la URL del webhook de n8n
→ Método: POST
→ Body: incluir {{contact.id}} + campos necesarios
Variables con ícono 🏷️
| Valor | Variable |
|---|
| Fecha/hora actual | |
| Nombre | |
| Apellido | |
| Teléfono | |
| Email | |
| UTM Source | (puede no existir en widget) |
| UTM Medium | |
| UTM Campaign | |
⚠️ Círculo naranja en un bloque = campos incompletos. El WF no se puede publicar hasta resolverlos.
Referencias GHL
Lectura obligatoria al inicio de cualquier sesión (Pre-flight Check):
references/ghl-api-capabilities.md
references/ghl-live-context-template.md
Lectura por tipo de tarea (capa workflow / UI builder):
| Si vas a generar... | Leer |
|---|
| Triggers (Contact Created, Opportunity Stage Changed, Customer Replied, etc.) | references/ghl-triggers-reference.md
|
| Acciones (Update Field, IF/Else, Send Message, Webhook, Wait, etc.) | references/ghl-actions-reference.md
|
| Tareas de Conversation AI / Aurora bot | references/ghl-conversation-ai-reference.md
|
| Limitaciones del builder (variables que no existen, aritmética, días hábiles, etc.) | references/ghl-limitations.md
|
Para workflows que mezclan triggers + acciones, leer ambos archivos de referencia antes de empezar.
Distinción importante entre los dos archivos de limitaciones:
- → "¿se puede hacer vía API/MCP?" (capa de automatización)
- → "¿GHL lo soporta en absoluto, ni siquiera manualmente?" (capa de producto)
Cuando una funcionalidad
no existe en GHL nativamente, usar el formato
de
.
Cuando una funcionalidad existe pero
no es automatizable vía API/MCP, usar
con la justificación de
.
Estructura visual en ClickUp
Tarea padre — formato de descripción
markdown
## Descripción
[Qué hace el workflow y la lógica de negocio central. 2-4 líneas.]
## Trigger
[Nombre exacto del trigger + pipeline/canal/etapa si aplica.]
## Pipelines involucrados (si el WF mueve entre pipelines)
|---|---|
| `Nombre pipeline` | Origen / Destino / Temporal |
## Dependencias
- [Qué debe existir creado antes de activar este WF]
- [Otros workflows que deben estar activos primero]
## Estructura de nodos
|---|---|---|
| 1 | Trigger | Trigger: ... |
| 2 | Guard IF | Guard IF: ... |
| 3 | Update Field | Update Field: ... |
Subtarea — formato de descripción
Cada subtarea tiene dos secciones fijas. Siempre en este orden:
markdown
## Acción en GHL
|---|---|
| Action type | [nombre exacto del nodo en GHL] |
| [campo 1] | [valor 1] |
| [campo 2] | [valor 2] |
| Rama TRUE | [qué pasa si se cumple] |
| Rama FALSE | [qué pasa si no se cumple] |
## Contexto
[Por qué existe este nodo. Qué workflow lo precede o lo sigue.
Qué pasa si no se configura. Relación con otros WFs. 2-5 líneas.]
Para nodos IF/Else con dos caminos, agregar diagrama visual al final del Contexto:
¿[condición]?
├── SÍ → [acción rama TRUE]
└── NO → [acción rama FALSE / STOP]
Ejemplo completo — [LS01] Widget Chat + UTM Capture
Tarea padre:
markdown
## Descripción
Captura contactos nuevos desde Widget Chat web. Extrae UTMs, clasifica
la fuente y crea la oportunidad inicial en el pipeline.
## Trigger
Contact Created. Sin filtros. Allow re-enrollment: OFF.
## Dependencias
- Pipeline Residencial B2C creado con etapa Contactos Recibidos
- Custom fields: Canal de primer contacto, Área de origen,
Fecha de primer contacto, UTMs, Tipo de cliente
## Estructura de nodos
|---|---|---|
| 1 | Trigger | Trigger: Contact Created |
| 2 | Update Fields | Update Fields: Canal + Área |
| 3 | Update Fields | Update Fields: UTM Source + Medium + Campaign + Content + Term |
| 4 | Guard IF | Guard IF: Fecha de primer contacto está vacía |
| 5 | Update Field | Update Field: Fecha de primer contacto = now (rama TRUE) |
| 6 | Create Opportunity | Crear oportunidad → Contactos Recibidos |
| 7 | Update Field | Update Field: Tipo de cliente = cliente_final |
| 8 | Assign | Assign to User: Round Robin asesores |
Subtareas (ejemplos con el formato correcto):
markdown
── Subtarea: Guard IF: Fecha de primer contacto está vacía
## Acción en GHL
|------------------|------------------------------------|
| Action type | IF / Else |
| Condition object | Contact |
| Field | Fecha de primer contacto |
| Operator | is empty |
| Rama TRUE | Continúa → nodo 5 (setear fecha) |
| Rama FALSE | Salta → nodo 6 (Crear oportunidad) |
## Contexto
Protege contra re-entradas. Si el contacto ya existe en el CRM y vuelve
a escribir por el widget, sin este Guard IF se pisaría la fecha original
de primer contacto con la del re-ingreso, contaminando los reportes de
tiempo de conversión.
markdown
── Subtarea: Update Field: Tipo de cliente = cliente_final
## Acción en GHL
|-------------|----------------|
| Action type | Actualizar datos de campo (Update Contact Field) |
| Field | Tipo de cliente |
| Value | cliente_final |
## Contexto
Este campo es el trigger de SP01. Cuando GHL detecta que Tipo de cliente
pasó de vacío a tener un valor, SP01 arranca y asigna el asesor. Sin
este nodo SP01 nunca dispara.
⚠️ **Tipo de cliente es un campo de Contacto**, no de Oportunidad.
Usar "Actualizar datos de campo" (Update Contact Field), no "Update Opportunity Field".