Dónde debe detenerse tu agente: la lección del soporte técnico de Gumroad

Por Nate from Nate's Substack · 26 de julio de 2026.

Nate arranca esta "executive briefing" con una anécdota de su propia empresa: en un par de semanas cerraron 51 de 52 incidencias de soporte al cliente, un 98% de resolución que al principio le pareció un buen resultado. Pero al reclasificar los tickets según la causa real del problema (no según el asunto que les habían puesto), descubrió que 39 de esos 52 casos eran, en realidad, el mismo problema de siempre: fallos de acceso a Slack. Es decir, habían arreglado 39 veces la misma vía de entrada rota a su comunidad y lo habían celebrado como una semana excelente.

A partir de ahí plantea la idea central del artículo: el soporte al cliente es, según él, el mejor punto de partida para introducir agentes de IA en una empresa, sea esta grande, pequeña o un negocio unipersonal. La razón es que el trabajo es concreto, el propio cliente te avisa cuando la respuesta está mal, y todo el historial ya vive en una bandeja de entrada. Nate menciona que su paso por Amazon le dejó una obsesión permanente por el cliente, y traslada esa lógica a cualquier situación cotidiana: la persona que espera un informe interno, el compañero que se queda fuera de un sistema, el cliente que persigue un documento que nadie le envió. Todos viven, dice, en la brecha entre lo que se prometió y lo que realmente ocurrió.

El hecho de ver juntos los 39 casos de Slack le cambió la pregunta que se estaba haciendo: ya no era cómo podía un agente ayudarles a responder más rápido, sino por qué estaban obligando a tanta gente a pedir ayuda por el mismo motivo una y otra vez. De ahí extrae tres beneficios que, según él, solo se consiguen atacando este único flujo de trabajo: el cliente recibe una respuesta más rápida, el equipo deja de repetir la misma "caza del tesoro" investigativa, y el producto mejora con el tiempo. Afirma no encontrar otro tipo de tarea para agentes que combine estos tres resultados a la vez.

Nate señala que este mismo patrón —resolver síntomas repetidos de un problema raíz sin atacar la causa— aparece también en finanzas, en accesos a software, en investigación de ventas y en bugs de producto, y promete retomarlo más adelante, insistiendo en que un caso de estudio del que no se pueda extraer una acción concreta es solo una anécdota sobre su propia empresa.

El correo adelanta la estructura del artículo completo (alojado en su Substack), organizada en cuatro bloques:

Primero, "dónde se va el tiempo": cronometraron cada paso de un ticket de soporte y descubrieron que redactar la respuesta era la parte barata del proceso, mientras que reconstruir el contexto del cliente repartido entre media docena de sistemas distintos era la parte realmente costosa.

Segundo, qué aspecto tiene un agente que asume el ciclo completo de una incidencia: cita como ejemplo que el agente de soporte de Gumroad encontró un error en una gráfica ("charting bug"), escribió el test correspondiente, desplegó la corrección, y aun así terminó equivocándose en un detalle de diseño que solo el propio cliente pudo detectar.

Tercero, cómo ese mismo patrón de trabajo se repite fuera de la bandeja de soporte: facturas sin orden de compra asociada, solicitudes de acceso a software, reconstrucción de historial de cuentas, o diez personas distintas reportando el mismo bug de producto.

Cuarto, cómo aplicar esto a los últimos 50 tickets propios: un prompt que ordena las incidencias por causa raíz en lugar de por el asunto que les puso el cliente, más un kit de cinco prompts y una guía complementaria para pasar de detectar un problema molesto a montar un piloto verificable.

El correo cierra con una llamada a la acción hacia los suscriptores de pago ("Executive Circle"), que tienen acceso a estas briefings dominicales adicionales y a un servidor MCP propio de Nate, con un enlace para cambiar de plan.