Me pidieron mirar la operación de tickets con ojo técnico y decirles qué está mal planteado de raíz. Esto es lo que veo desde afuera, antes de tocar el código.
Lo pongo tal cual para asegurarme de que entendí bien. Si algo está mal en este mapa, todo lo que viene después se corrige solo.
Lo que ya funciona y no hay que tocar: el portal ordena, el equipo lo usa y el paso 2 ya está automatizado. La skill que arma el contexto es buena señal: significa que el problema no es de disciplina, es de arquitectura.
El paso 5 es el síntoma. La causa está tres capas más abajo, y es una sola.
Si para cambiar el tono de un agente hay que generar una carpeta, descargarla, abrir Claude Code y aplicar cambios, es porque el comportamiento del agente es un artefacto de código que se edita y se vuelve a desplegar.
Eso convierte una petición de una línea, como "que responda más formal" o "agrega este PDF a su base de conocimiento", en una tarea que exige a una persona con IDE y criterio técnico.
El día que el prompt, el tono, las reglas y la base de conocimiento vivan en la base de datos, cambiarlos deja de ser un deploy y pasa a ser un UPDATE. Y un UPDATE lo puede hacer un formulario, operado por quien recibe el ticket.
Cada cambio de comportamiento pasa por un IDE. Es la causa de la mayor parte del trabajo manual.
264 tickets resueltos y cada uno se atacó como si fuera el primero. Las acciones repetidas no están extraídas ni parametrizadas.
Todo entra por la misma puerta y lo toma la misma persona. Nada distingue un cambio de tono de algo que toca un workflow.
Si los cambios se aplican a mano sobre archivos, nada garantiza que tocar al cliente A no rompa al B. Sin versionado ni rollback, cada cambio es un acto de fe.
La cuarta no es solo eficiencia, es seguridad. Con 35 clientes pagando, el aislamiento entre configuraciones es exactamente el mismo problema que ya está sobre la mesa para el CRM 2.0. No son dos proyectos: es la misma base.
Hoy casi todo se resuelve en el piso más caro. El trabajo consiste en bajar cada tipo de tarea uno o dos pisos, y dejar arriba solo lo que de verdad necesita criterio técnico.
Arquitectura, workflows nuevos, integraciones, backend. Aquí sí corresponde.
El sistema aplica la acción del catálogo, con aprobación humana antes de publicar.
Sin código y sin Claude Code. Aquí debería vivir el grueso del volumen.
Lo que ni siquiera debería llegar a ser un ticket.
| Tarea | Hoy | Debería |
|---|---|---|
| Ajustar el tono del agente | N3 · Claude Code | N1 · selector con preview |
| Cargar o corregir base de conocimiento | N3 · Claude Code | N0 · subir archivo, reindexado solo |
| Cambiar cómo responde ante un caso | N3 · Claude Code | N1 · editor de reglas con prueba en vivo |
| Mover contacto de etapa en GoHighLevel | N3 · Chrome a mano | N2 · acción del catálogo por API |
| Implementar cliente nuevo (IMP) | N3 completo | N1 con plantilla, N3 solo lo específico |
| Integración con sistema externo (INT) | N3 | N3 · aquí está bien |
El orden importa más que la velocidad. Automatizar antes de medir es la forma más cara de equivocarse.
Hoy el panel mide pendientes, en curso y terminadas. Eso dice cuánto trabajo hay, pero no de qué tipo, y sin eso no se sabe qué automatizar.
Es el cambio que elimina los pasos 3 y 4 para la mayoría de los tickets de tipo IA.
Convertir los tipos más frecuentes en acciones parametrizadas, con un botón detrás. "Claude en Chrome uno por uno" existe porque no hay una acción de API expuesta.
Aquí es donde su negocio se vuelve recursivo: usan agentes para vender agentes, pero la operación interna todavía es manual.
Vale tanto como lo anterior. Estos son los errores que veo caer seguido en este tipo de rediseño.
Automatizar el tipo de ticket equivocado es trabajo tirado a la basura, y encima da la sensación de avance.
Con 35 clientes pagando, un agente mal calibrado tocando configuraciones es un incidente esperando a ocurrir.
Se etiquetan con un pase de LLM y se archiva lo que no aporte. Nadie debería leer 264 tickets uno por uno.
HEAT Task funciona y el equipo lo usa. Se le agregan capas, no se reemplaza. Reescribir lo que ya opera es el error clásico.
Todo lo anterior es una hipótesis fundada, construida desde afuera. Con esto la confirmo o la corrijo en cuestión de días.
Lo digo de frente: nada de este documento es un diagnóstico. Es lo que veo desde afuera con la información que me dieron, y lo comparto antes de la reunión para que hablemos de algo concreto en vez de generalidades. Si al abrir el código resulta que la configuración ya está en base de datos, la mitad de esto sobra y se los digo el primer día.
Propongo las métricas desde ahora para que en el mes dos podamos mirar números y no impresiones.
| Métrica | Hoy | Hacia dónde |
|---|---|---|
| Tickets resueltos sin tocar código | Prácticamente ninguno | La mayoría |
| Tickets que escalan al nivel técnico | Casi todos | Menos del 10% |
| Tiempo medio de resolución | Dentro de las 72 h comprometidas | Horas, no días |
| Dedicación del equipo a la operación | Una persona a tiempo completo | Una fracción |
| Rollback ante un cambio malo | No existe | Un clic |
Lo que esto vale, en su propia moneda: una persona a tiempo completo son alrededor de 160 horas al mes. Si el catálogo cubre aunque sea la mitad del volumen, son unas 80 horas mensuales liberadas, más el tiempo de Piero que hoy se va en lo que escala. Y en una agencia cuyo diferenciador declarado es el acompañamiento, bajar el tiempo de respuesta impacta directo en lo que venden.
Las revisamos juntos el jueves, pero aquí les dejo un adelanto para que lleguen sabiendo dónde estamos de acuerdo y dónde hay que conversar. Sigo el mismo orden de su documento, de la A a la F.
Para que quede dicho: de todo lo que plantearon, tengo una sola diferencia de fondo (dónde vive la instalación de voz) y dos ajustes de redacción que protegen a ambos. Todo lo demás lo firmo como está. Lo escribo así de claro para que el jueves usemos el tiempo en lo que falta y no en repasar lo que ya está resuelto.