Ertas + OpenClaw para Soporte al Cliente

Los equipos de soporte que usan OpenClaw para clasificar tickets, redactar respuestas y gestionar escalaciones obtienen resultados mediocres con modelos genéricos en la nube. Un modelo ajustado con tus propios tickets aprende tu producto, tu taxonomía y tu tono, y ejecutarlo en local elimina la factura de API por token.

The Challenge

OpenClaw encaja de forma natural en la automatización del soporte al cliente: puede monitorear canales de soporte (correo electrónico, Slack, plataformas de mensajería), clasificar los tickets entrantes por categoría y urgencia, redactar respuestas, escalar problemas complejos y generar resúmenes de cambio de turno. Los equipos de soporte que lo despliegan ven ganancias de productividad inmediatas.

Esas ganancias se estancan pronto con modelos genéricos en la nube, porque el soporte al cliente depende mucho del dominio. La diferencia entre una "consulta de facturación" y una "solicitud de gestión de suscripción" depende de la arquitectura de facturación de tu producto. La diferencia entre un "reporte de error" y una "solicitud de funcionalidad" depende de lo que tu producto hace realmente y de lo que los usuarios esperan que haga. Un GPT-4o o un Claude genérico hace suposiciones razonables a partir de su comprensión general del lenguaje, y esas suposiciones dejan mal clasificada una parte considerable de los tickets.

Los tickets mal clasificados generan problemas en cadena: asignación al equipo equivocado, prioridad incorrecta, respuestas automáticas inadecuadas y clientes frustrados que tienen que repetir su problema al equipo correcto. Parte del tiempo que ahorra la automatización se va en corregir tickets mal enrutados.

El problema de costo agrava el de precisión. Cada ticket que procesa OpenClaw genera tokens de API: el mensaje entrante, el prompt de clasificación, la generación de la respuesta y la comprobación de escalación. Un equipo que procesa 200 tickets al día acumula un gasto de API considerable, y para empresas SaaS con márgenes ajustados ese gasto puede comerse buena parte del ahorro en mano de obra que aporta la automatización.

The Solution

Ertas ataca a la vez el problema de precisión y el de costo. Ajusta un modelo en Ertas Studio con tu historial real de tickets de soporte: tu taxonomía, la terminología de tu producto, tus patrones de resolución y tu estilo de comunicación. Expórtalo desde Hub en GGUF, ejecútalo en local con Ollama y apunta OpenClaw al endpoint local.

Un modelo ajustado con unos pocos miles de tickets categorizados de tu sistema aprende los límites concretos entre tus categorías, límites difíciles de transmitir por completo en un prompt de sistema. Los borradores de respuesta mejoran porque el modelo ha visto muchos ejemplos de buenas respuestas para cada tipo de ticket. Mide la mejora con tus propios datos: reserva un conjunto de tickets categorizados recientemente, compara el modelo ajustado con tu configuración actual y revisa dónde falla cada uno.

La inferencia corre en hardware que tú controlas, así que no hay factura de API por token. El costo de operación es el hardware que dimensionas para tu volumen de tickets, más tu plan de Ertas Studio para entrenar. Eso hace que OpenClaw sea económicamente viable para operaciones de soporte de alto volumen donde los costos de API serían prohibitivos.

Key Features

Studio

Clasificación Específica por Taxonomía

Studio ajusta con tu taxonomía exacta de tickets: categorías, subcategorías, reglas de prioridad y criterios de escalación que son específicos de tu producto y estructura de soporte. El modelo aprende los límites entre categorías similares que los modelos genéricos confunden consistentemente.

Studio

Entrenamiento de Plantillas de Respuesta

Ajusta con tus mejores respuestas de soporte: el tono, nivel de detalle, pasos de resolución de problemas y patrones de resolución que tu equipo ha desarrollado a lo largo del tiempo. El modelo genera borradores que coinciden con tu guía de estilo de soporte sin prompts de sistema extensos.

Hub

Soporte Multi-Producto

Entrena en Studio un modelo distinto para cada producto o marca, cada uno con su propia taxonomía, estilo de respuesta y reglas de escalación. Cada modelo aparece en Hub para exportarlo, y cada agente de OpenClaw apunta al modelo de su producto.

Studio

Monitoreo de Calidad

Sigue en los informes de tu propio helpdesk la precisión de clasificación, la frecuencia con que los agentes aceptan borradores sin editarlos y los patrones de escalación. Localiza las categorías donde el modelo rinde peor, añade ejemplos específicos en Data Craft y compara en Studio la nueva ejecución con el modelo actual antes de sustituirlo.

Example Workflow

Una empresa SaaS B2B con 3,000 clientes activos despliega OpenClaw para reforzar a su equipo de soporte de 8 personas. El equipo atiende hoy 180 tickets al día entre correo electrónico y Slack, con un tiempo medio de primera respuesta de 2.4 horas y una tasa de resolución en Nivel 1 del 45%. La empresa exporta 15,000 tickets resueltos de los últimos 12 meses, cada uno con su categoría, su prioridad y los mensajes de resolución que lo cerraron, elimina los nombres y datos de contacto de los clientes y sube el dataset a Ertas Studio, donde ajusta Llama 3.1 8B con LoRA. El equipo reserva 1,000 tickets recientes y compara las clasificaciones y los borradores del modelo ajustado con los de GPT-4o con prompt engineering sobre la misma taxonomía, revisando las categorías en las que falla cada modelo. El modelo se exporta en GGUF y corre en un Mac Mini M4 Pro con Ollama, y el agente de OpenClaw monitorea los canales de soporte por correo y Slack. Clasifica cada ticket entrante, asigna la prioridad, redacta una respuesta y la envía automáticamente (en las categorías que el equipo ha aprobado para automatizar) o la deja en cola para revisión de un agente. El equipo de soporte mide el tiempo de primera respuesta y la resolución en Nivel 1 frente a su punto de partida, y dedica más tiempo a los problemas complejos de Nivel 2 y Nivel 3 que requieren criterio humano. El costo mensual de operación es el plan de Ertas Studio más el hardware, sin factura de API por token aunque crezca el volumen.

Compliance & Security

Con inferencia local, los datos de clientes de los tickets en curso (conversaciones de soporte, datos de cuenta, patrones de uso) se procesan en el hardware de la propia empresa, y ningún proveedor externo de IA los ve cuando el modelo responde. El entrenamiento funciona de otra manera: el historial de tickets usado para el ajuste se sube a las GPU en la nube de Ertas, así que elimina o enmascara antes los identificadores de clientes y borra el dataset de Studio cuando ya no lo necesites. Las revisiones de seguridad de tu IA de soporte siguen siendo trabajo tuyo; ejecutar el modelo internamente deja menos flujos de datos que revisar.