Sistema de Gestión de Incidencias con Make

Antes de empezar

Lo que necesitas para completar este tutorial

Lo que conseguiras al terminar

Si sigues estos pasos, en 45-60 minutos tendras:

✓ Escenario Make funcional con webhook, IA y notificaciones
✓ Matriz de escalado y plantillas de mensajes listas para usar
✓ Indicadores SLA y reglas de priorización documentadas

Antes de empezar, asegurate de tener lo siguiente:

Cuenta Make con permisos para crear escenarios Acceso a un plan que permita webhooks, módulos HTTP y conexiones a API externas.

Fuente de incidentes accesible Acceso a la API o canales (ticketing, correo, monitorización) desde los que recibir incidencias.

Clave de API para modelo IA Clave de OpenAI u otro proveedor para usar módulos de generación de texto desde Make.

Canales de notificación integrados Cuentas de Slack, Microsoft Teams o un SMTP para enviar alertas y plantillas.

Transferencia internacional de datos: Make procesa datos en servidores externos. Sin acuerdo de procesamiento de datos (DPA) firmado, no introduzcas datos personales, financieros confidenciales ni datos especialmente protegidos. Verifica con tu departamento legal o IT antes de usar datos reales de tu empresa.

El caso

LogiTrans Iberia S.A., sector logística y transporte — el problema real

Operaciones sufre picos de incidencias de rutas y entregas fuera de horario; los gestores no siguen criterios homogéneos y hay demora en escalar problemas críticos. La falta de trazabilidad genera pérdidas y reclamaciones.

Con Make y el prompt de este tutorial, puede resolver este reto en 45-60 minutos — sin conocimientos tecnicos previos.

Situacion real
Datos + contexto

→

Make
Prompt estructurado

→

Output ejecutivo
Listo para usar

Por que funciona: Make conecta múltiples fuentes con lógica visual y módulos de terceros, lo que permite automatizar el enrutamiento sin desarrollos pesados. La integración con modelos de IA mejora la clasificación y reduce la necesidad de intervención humana para decisiones repetitivas.

Contexto

Cuando usar este tutorial

✓ Usalo cuando...	× No lo uses cuando...
Cuando hay múltiples fuentes de incidencias (tickets, monitorización, llamadas) que requieren normalización Cuando se necesita trazar responsabilidades y tiempos SLA automáticamente Cuando se desea reducir ruido operativo y priorizar problemas de forma consistente	Cuando sólo hay una fuente interna con flujo manual muy sencillo Cuando los SLA y la responsabilidad son siempre informales y no se prevé automatizarlos Cuando la organización requiere revisión humana para cada incidente por cumplimiento normativo

Paso 01

Mapear fuentes, prioridades y responsables

Antes de construir en Make, documente las fuentes de incidencia, los criterios de prioridad y la matriz de responsables. Esto evita decisiones arbitrarias y facilita las reglas automáticas.

1
Identificar fuentes de entrada Liste todos los canales que generan incidencias: sistema de tickets, formularios web, correo, monitorización telemática y llamadas. Para cada fuente indique el formato de los datos y propietario técnico.
2
Definir criterios de prioridad Establezca niveles de prioridad (ej. Crítico, Alta, Media, Baja) con ejemplos concretos y métricas asociadas (impacto clientes, volumen, riesgo operativo).
3
Asignar responsables y SLAs Mapee roles responsables por tipo de incidencia y establezca SLAs objetivos (p. ej. respuesta inicial: 15 min para críticos, 4 h para alta).

Checkpoint: Documento con fuentes, esquema de prioridades y matriz de responsables listo para implementar en Make.

Paso 02

Construir el escenario Make básico

Cree un escenario en Make que reciba incidencias, normalice el payload y aplique un router con filtros para priorizar y enrutar. Añada módulos de prueba y logs para validar cada etapa.

1
Crear webhook de entrada Genere un webhook en Make para centralizar todas las fuentes. Configure pruebas con ejemplos reales de payloads para asegurar que los campos clave llegan correctamente.
2
Normalizar datos Use módulos de ‘Transform’ o JavaScript en Make para homogenizar campos (cliente, ubicación, timestamp, descripción) antes de aplicar reglas.
3
Configurar router y filtros Implemente un router con ramas para Crítico/Alta/Media/Baja usando filtros basados en palabras clave, campos de monitorización y reglas de negocio definidas en Paso 1.

Checkpoint: Escenario que recibe un webhook de prueba y enruta al menos tres tipos de prioridad a ramas diferenciadas.

Paso 03

Ejecutar el prompt principal

Este es el prompt central del tutorial. Cópialo completo, rellena las variables entre corchetes con los datos de tu empresa o situación, y envíalo.

1
Copia el prompt completo Selecciona todo el texto del prompt y cópialo. No modifiques la estructuración — está diseñado para obtener el output más útil posible.
2
Rellena las variables entre corchetes Sustituye cada [VARIABLE] con información real de tu empresa. Cuanto más específico seas, mejor será el output.
3
Envía el prompt y espera la respuesta Pega el prompt en el chat y envíalo. El modelo puede tardar entre 10 y 60 segundos dependiendo de la complejidad.

Variables del prompt — sustituye cada [VARIABLE] con datos reales

[NOMBRE_EMPRESA]Nombre de la empresa u organización (p. ej. LogiTrans Iberia S.A.)

[PRIORITY_TIERS]Definición corta de niveles de prioridad (p. ej. Crítico/Alta/Media/Baja)

[CHANNELS]Listado de canales que generan incidencias, separados por comas (p. ej. ticketing, webhook monitorización, correo)

Prompt principal — Incidencias con escalado inteligente Eres un asistente experto en operaciones y diseño de automatizaciones. Tu tarea es generar una guía operativa y técnica para implementar un sistema de gestión de incidencias con escalado inteligente en Make. Produces: 1) resumen ejecutivo de máximo tres párrafos dirigido a la dirección con riesgos y beneficios; 2) esquema de clasificación de incidencias (etiquetas, ejemplos, criterios determinantes); 3) matriz de prioridades con SLAs sugeridos y umbrales técnicos; 4) árbol de escalado detallado con responsables por nivel y canales de notificación; 5) plantillas de mensaje para alertas y actualizaciones (Slack, email, SMS) en formato final listo para copiar; 6) matriz de routing para Make que indique módulos, filtros y condiciones (por ejemplo: Webhook -> Normalizar -> Router (Crítico si [palabras clave] o [métricas] > umbral) -> Notificar a [ROL]); 7) pasos de prueba y casos de prueba con tres incidencias ejemplo y la respuesta esperada en cada caso; 8) lista de métricas a monitorizar y alertas de degradación del proceso. Contexto: empresa [NOMBRE_EMPRESA], sectores afectados [SECTORES], prioridad por cliente estratégico definida como [PRIORITY_TIERS]. Fuentes de incidencias: [CHANNELS]. SLA propuesto base: [SLA_DEADLINES]. Incidencia ejemplo para analizar: [INCIDENT_EXAMPLE]. Entrega la respuesta en formato estructurado con títulos y listas numeradas, y termina con un bloque de instrucciones para copiar y pegar en Make (módulos y campos clave). Evita lenguaje técnico innecesario; prioriza decisiones operativas claras, acciones concretas y plantillas utilizables por equipos de operaciones y soporte. Si hay supuestos, indícalos al final en una sección 'Supuestos'.

Checkpoint: El modelo ha respondido con un output estructurado que incluye las secciones solicitadas en el prompt.

Paso 04

Iterar y afinar reglas y notificaciones

Tras la primera ejecución, recabe métricas y feedback operativo para ajustar filtros, umbrales y plantillas. Itere hasta reducir falsos positivos y garantizar que los responsables reciben información accionable.

1
Analizar primeros 50 incidencias Revise clasificación y escalado en los primeros 50 registros para identificar patrones de error y ajustar reglas o prompts de IA.
2
Ajustar plantillas y SLAs Refine los mensajes y los plazos en base a aceptación operativa; documente cambios para gobernanza.

Checkpoint: Reducción visible de falsos positivos y aceptación operativa de las plantillas y tiempos de respuesta.

Iteracion

Prompts para refinar el output

Estos son los ajustes mas frecuentes que se piden despues del primer output. Copialos directamente en el chat:

Hacer el output más específico

cuando el output es demasiado genérico. "Toma el output anterior y adapta cada regla de escalado al contexto de [NOMBRE_EMPRESA]. Para cada prioridad, añade 2 ejemplos reales tomados de historiales de incidencias y ajusta umbrales numéricos. Mantén formato y secciones originales."

Cambiar el nivel de detalle

cuando necesitas más o menos profundidad. "Reescribe la sección 'Matriz de routing para Make' en versión concisa de una página o en versión extendida con pseudocódigo para cada módulo según indique [MODO=conciso|extenso]."

Adaptar el tono

cuando el tono no es el adecuado para tu audiencia. "Convierte todo el documento a un tono ejecutivo y directo adecuado para Comité de Dirección, resumiendo beneficios y riesgos en máximo 300 palabras y destacando KPI clave."

Versión ejecutiva resumida

para compartir con el Comité de Dirección. "Genera un resumen ejecutivo de máximo 250 palabras que incluya: objetivo del sistema, impacto esperado (reducción de TTR y costes), inversión estimada y principales riesgos con mitigación."

Resultado

Que vas a obtener

Este es el tipo de output que genera Make con el prompt de este tutorial. El contenido varia segun tu empresa y situacion, pero la estructura es siempre esta:

Ejemplo de output — LogiTrans Iberia S.A., sector logística y transporte

Estructura del output

El prompt genera un documento estructurado: resumen ejecutivo, esquema de clasificación, matriz de prioridades con SLAs, árbol de escalado, plantillas de comunicación, matriz de routing para Make, casos de prueba, métricas y supuestos. Cada sección debe ser clara y accionable.

Senales de un buen output

El output incluye plantillas listas para copiar en canales operativos
La matriz de routing especifica módulos y condiciones concretas para Make
Se entregan casos de prueba con resultados esperados
Los SLAs y roles aparecen alineados y cuantificados

Senal de que el output es bueno: Plantillas y matriz de routing pueden copiarse directamente a Make sin ambigüedad

Costes

Inversion y retorno

29$ Make Business / mes

2-5 minutos por incidencia (ejecución automática promedio) Por ejecucion del tutorial

∞ Reutilizaciones del prompt

ROI: El ROI se materializa por reducción de tiempo medio de resolución (TTR) y menor sobrecarga en equipos de soporte; una reducción del 20-30% en TTR suele compensar el coste de la plataforma en semanas para empresas medianas. Además reduce pérdidas por incumplimiento de SLA y mejora NPS operativo.

Errores frecuentes

Que hacer cuando algo no funciona

Sintoma	Causa probable	Solucion exacta
Webhook no recibe incidencias	URL de webhook mal copiada o restricción de IP/Firewall	Verificar la URL en Make, probar con curl desde una IP externa y ajustar reglas de firewall o whitelist de IPs del proveedor.
Incidencias mal clasificadas	Modelo IA entrenado con ejemplos insuficientes o reglas de filtrado conflictivas	Añadir 50-100 ejemplos etiquetados en el prompt de entrenamiento o ajustar filtros de texto/umbral en el router para priorizar campos estructurados.
Notificaciones duplicadas	Ramas de router solapadas o módulos reintentos sin control	Revisar condiciones de filtros, añadir un campo 'processed=true' tras la primera notificación y controlar reintentos con un módulo de deduplicación.
Límites de tasa alcanzados	Alto volumen de incidencias y uso intensivo del módulo IA	Batching de llamadas IA, aumentar plan o implementar un prefiltrado que solo envíe a IA las incidencias ambiguas.
Campo clave vacío en payload	Entrada desde origen con formato distinto o fallos en normalización	Implementar validaciones en el webhook y un módulo de fallback que solicite al origen datos faltantes o incluya valores por defecto.

Modo avanzado

Como hacer este tutorial con Make en modo avanzado

En modo agente, Make puede actuar de forma autónoma ejecutando secuencias (ej. confirmar recepción, crear ticket, notificar escalado) según reglas y decisiones del modelo. Esto permite respuestas proactivas y mitigación inmediata sin intervención humana en casos estándar.

Modo avanzado

Flujo de trabajo avanzado

1
Configurar un escenario persistente que escuche webhooks y mantenga estado por incidente
2
Integrar módulo de IA que decida acción ('escalar','resolver con plantilla','pedir info') y devuelva instrucciones en JSON
3
Programar módulos que ejecuten la instrucción: crear ticket, enviar plantilla, o asignar responsable automáticamente
4
Implementar logs y un panel de supervisión para revisar acciones automáticas y revertir si es necesario

Actúa como agente operativo encargado de gestionar incidencias en Make para [NOMBRE_EMPRESA]. Para cada incidencia entrante analiza el payload, clasifícala según [PRIORITY_TIERS], decide una acción entre: 'escalar a rol X', 'enviar plantilla Y por [CANAL]', 'resolver con nota Z' o 'pedir información adicional'. Devuelve un JSON con: {"action": "", "target_role": "", "message_template": "", "metadata": {"priority": "", "sla": ""}}. Incluye reglas de seguridad: no escalar fuera de horario salvo Crítico, registrar cada acción en log con timestamp, y marcar incidente como 'esperando confirmación' si se pide información. Variables: [NOMBRE_EMPRESA], [PRIORITY_TIERS], [CANAL_PRIMARIO].

Cuando usar el modo avanzado en este tutorial: Particularmente valioso cuando hay alto volumen de incidencias repetitivas que pueden resolverse con plantillas o reglas claras; reduce latencia y carga operativa.

Siguiente paso

Que hacer ahora?

Ahora que has completado este tutorial, hay dos caminos naturales:

Tutorial relacionado · Make

Explorar mas tutoriales de Make

Descubre otros casos de uso de Make para directivos en diferentes funciones y sectores.

Biblioteca completa

Ver todos los tutoriales

Explora los tutoriales del programa organizados por herramienta, funcion y nivel de dificultad.

Para sacarle mas partido: Después de poner en marcha, implemente un panel de control con indicadores en tiempo real (TTR, tasa de escalado, falsos positivos) y realice revisiones quincenales de reglas y prompts para adaptar el sistema a cambios operativos.

Alternativa segura

Puedo hacer esto sin que mis datos salgan de la empresa?

Si. Este caso de uso trabaja con datos que, por su naturaleza confidencial, estrategica o regulada, son candidatos optimos para ejecutarse con un modelo de lenguaje open source desplegado en infraestructura propia (on-premises o nube privada). Con esta configuracion, ningun dato abandona nunca los servidores de tu organizacion y el modelo no puede ser entrenado con tu informacion.

Modelos recomendados

Llama 3.3 70B — Ideal para analisis de documentos largos y generacion de texto estructurado (contexto 128K tokens).

Mistral Large 2 — Excelente para extraccion de informacion y clasificacion con alta precision.

Qwen 2.5 72B — Especialmente potente para analisis de datos tabulares y financieros.

Plataformas de despliegue

Ollama — Para equipos pequenos o uso individual en hardware propio.

vLLM — Para entornos de produccion con multiples usuarios simultaneos.

LM Studio — Para pruebas y uso individual sin configuracion de servidor.

Infraestructura minima

Para un modelo de 70B parametros en produccion:

GPU: 2x NVIDIA A100 40GB o 4x RTX 4090.

RAM: 128GB minimo.

Alternativa cloud privada: AWS Private Cloud, Azure Government o Google Cloud Confidential Computing.

Garantia de privacidad: Con un modelo on-premises correctamente configurado, los datos nunca salen de tu red corporativa, el modelo no se entrena con tu informacion, no hay transferencia internacional de datos y el cumplimiento normativo es total incluso para datos del art. 9 RGPD.

Necesitas implementar esta solucion en tu organizacion?

La configuracion de modelos open source on-premises requiere un proveedor tecnico especializado. Agere puede ayudarte a desplegar esta solucion en tu infraestructura de forma segura, con garantias legales y sin que tus datos salgan nunca de tu organizacion.

Contactar con Agere Conocer Agere