Definir si usar Claude para el enrutamiento de tickets

Aquí hay algunos indicadores clave de que deberías usar un LLM como Claude en lugar de enfoques tradicionales de ML para tu tarea de clasificación:
Los procesos tradicionales de ML requieren conjuntos de datos etiquetados masivos. El modelo preentrenado de Claude puede clasificar efectivamente tickets con solo unas pocas docenas de ejemplos etiquetados, reduciendo significativamente el tiempo de preparación de datos y los costos.
Una vez que se ha establecido un enfoque tradicional de ML, cambiarlo es una empresa laboriosa e intensiva en datos. Por otro lado, a medida que tu producto o las necesidades del cliente evolucionan, Claude puede adaptarse fácilmente a cambios en las definiciones de clases o nuevas clases sin un reetiquetado extensivo de datos de entrenamiento.
Los modelos tradicionales de ML a menudo luchan con datos no estructurados y requieren ingeniería de características extensa. La comprensión avanzada del lenguaje de Claude permite una clasificación precisa basada en contenido y contexto, en lugar de depender de estructuras ontológicas estrictas.
Los enfoques tradicionales de ML a menudo dependen de modelos de bolsa de palabras o coincidencia de patrones simple. Claude sobresale en entender y aplicar reglas subyacentes cuando las clases se definen por condiciones en lugar de ejemplos.
Muchos modelos tradicionales de ML proporcionan poca información sobre su proceso de toma de decisiones. Claude puede proporcionar explicaciones legibles por humanos para sus decisiones de clasificación, construyendo confianza en el sistema de automatización y facilitando la adaptación fácil si es necesario.
Los sistemas tradicionales de ML a menudo luchan con valores atípicos y entradas ambiguas, frecuentemente clasificándolos mal o por defecto a una categoría general. Las capacidades de procesamiento de lenguaje natural de Claude le permiten interpretar mejor el contexto y los matices en los tickets de soporte, potencialmente reduciendo el número de tickets mal enrutados o no clasificados que requieren intervención manual.
Los enfoques tradicionales de ML típicamente requieren modelos separados o procesos de traducción extensivos para cada idioma soportado. Las capacidades multilingües de Claude le permiten clasificar tickets en varios idiomas sin la necesidad de modelos separados o procesos de traducción extensivos, simplificando el soporte para bases de clientes globales.

Construir y desplegar tu flujo de trabajo de soporte LLM

Entender tu enfoque de soporte actual

Antes de sumergirte en la automatización, es crucial entender tu sistema de tickets existente. Comienza investigando cómo tu equipo de soporte maneja actualmente el enrutamiento de tickets. Considera preguntas como:
  • ¿Qué criterios se usan para determinar qué SLA/oferta de servicio se aplica?
  • ¿Se usa el enrutamiento de tickets para determinar a qué nivel de soporte o especialista de producto va un ticket?
  • ¿Hay alguna regla automatizada o flujos de trabajo ya en su lugar? ¿En qué casos fallan?
  • ¿Cómo se manejan los casos extremos o tickets ambiguos?
  • ¿Cómo prioriza el equipo los tickets?
Mientras más sepas sobre cómo los humanos manejan ciertos casos, mejor podrás trabajar con Claude para hacer la tarea.

Definir categorías de intención del usuario

Una lista bien definida de categorías de intención del usuario es crucial para la clasificación precisa de tickets de soporte con Claude. La capacidad de Claude para enrutar tickets efectivamente dentro de tu sistema es directamente proporcional a qué tan bien definidas están las categorías de tu sistema. Aquí hay algunas categorías de intención del usuario de ejemplo y subcategorías.
  • Problema de hardware
  • Error de software
  • Problema de compatibilidad
  • Problema de rendimiento
  • Restablecimiento de contraseña
  • Problemas de acceso a la cuenta
  • Consultas de facturación
  • Cambios de suscripción
  • Consultas de características
  • Preguntas de compatibilidad del producto
  • Información de precios
  • Consultas de disponibilidad
  • Preguntas de cómo hacer
  • Asistencia de uso de características
  • Consejos de mejores prácticas
  • Orientación de solución de problemas
  • Reportes de errores
  • Solicitudes de características
  • Retroalimentación general o sugerencias
  • Quejas
  • Consultas de estado de pedido
  • Información de envío
  • Devoluciones e intercambios
  • Modificaciones de pedido
  • Asistencia de instalación
  • Solicitudes de actualización
  • Programación de mantenimiento
  • Cancelación de servicio
  • Consultas de privacidad de datos
  • Reportes de actividad sospechosa
  • Asistencia de características de seguridad
  • Fallas críticas del sistema
  • Problemas urgentes de seguridad
  • Problemas sensibles al tiempo
  • Solicitudes de entrenamiento del producto
  • Consultas de documentación
  • Información de seminarios web o talleres
  • Asistencia de integración
  • Preguntas de uso de API
  • Consultas de compatibilidad de terceros
Además de la intención, el enrutamiento y priorización de tickets también puede estar influenciado por otros factores como urgencia, tipo de cliente, SLAs o idioma. Asegúrate de considerar otros criterios de enrutamiento al construir tu sistema de enrutamiento automatizado.

Establecer criterios de éxito

Trabaja con tu equipo de soporte para definir criterios de éxito claros con puntos de referencia medibles, umbrales y objetivos. Aquí hay algunos criterios estándar y puntos de referencia al usar LLMs para el enrutamiento de tickets de soporte:
Esta métrica evalúa qué tan consistentemente Claude clasifica tickets similares a lo largo del tiempo. Es crucial para mantener la confiabilidad del enrutamiento. Mide esto probando periódicamente el modelo con un conjunto de entradas estandarizadas y apuntando a una tasa de consistencia del 95% o superior.
Esto mide qué tan rápido Claude puede adaptarse a nuevas categorías o patrones de tickets cambiantes. Prueba esto introduciendo nuevos tipos de tickets y midiendo el tiempo que toma para que el modelo logre precisión satisfactoria (ej., >90%) en estas nuevas categorías. Apunta a la adaptación dentro de 50-100 tickets de muestra.
Esto evalúa la capacidad de Claude para enrutar precisamente tickets en múltiples idiomas. Mide la precisión de enrutamiento a través de diferentes idiomas, apuntando a no más de una caída del 5-10% en precisión para idiomas no primarios.
Esto evalúa el rendimiento de Claude en tickets inusuales o complejos. Crea un conjunto de prueba de casos extremos y mide la precisión de enrutamiento, apuntando a al menos 80% de precisión en estas entradas desafiantes.
Esto mide la equidad de Claude en el enrutamiento a través de diferentes demografías de clientes. Audita regularmente las decisiones de enrutamiento para sesgos potenciales, apuntando a precisión de enrutamiento consistente (dentro del 2-3%) a través de todos los grupos de clientes.
En situaciones donde minimizar el conteo de tokens es crucial, este criterio evalúa qué tan bien Claude se desempeña con contexto mínimo. Mide la precisión de enrutamiento con cantidades variables de contexto proporcionado, apuntando a 90%+ de precisión con solo el título del ticket y una breve descripción.
Esto evalúa la calidad y relevancia de las explicaciones de Claude para sus decisiones de enrutamiento. Los evaluadores humanos pueden puntuar las explicaciones en una escala (ej., 1-5), con el objetivo de lograr una puntuación promedio de 4 o superior.
Aquí hay algunos criterios de éxito comunes que pueden ser útiles independientemente de si se usa un LLM:
La precisión de enrutamiento mide qué tan a menudo los tickets son asignados correctamente al equipo o individuo apropiado en el primer intento. Esto típicamente se mide como un porcentaje de tickets enrutados correctamente del total de tickets. Los puntos de referencia de la industria a menudo apuntan a 90-95% de precisión, aunque esto puede variar basado en la complejidad de la estructura de soporte.
Esta métrica rastrea qué tan rápido se asignan los tickets después de ser enviados. Tiempos de asignación más rápidos generalmente llevan a resoluciones más rápidas y mejor satisfacción del cliente. Los sistemas de mejor clase a menudo logran tiempos promedio de asignación de menos de 5 minutos, con muchos apuntando a enrutamiento casi instantáneo (que es posible con implementaciones LLM).
La tasa de reenrutamiento indica qué tan a menudo los tickets necesitan ser reasignados después del enrutamiento inicial. Una tasa más baja sugiere enrutamiento inicial más preciso. Apunta a una tasa de reenrutamiento por debajo del 10%, con sistemas de mejor rendimiento logrando tasas tan bajas como 5% o menos.
Esto mide el porcentaje de tickets resueltos durante la primera interacción con el cliente. Tasas más altas indican enrutamiento eficiente y equipos de soporte bien preparados. Los puntos de referencia de la industria típicamente van del 70-75%, con los mejores ejecutantes logrando tasas del 80% o superior.
El tiempo promedio de manejo mide cuánto tiempo toma resolver un ticket de principio a fin. El enrutamiento eficiente puede reducir significativamente este tiempo. Los puntos de referencia varían ampliamente por industria y complejidad, pero muchas organizaciones apuntan a mantener el tiempo promedio de manejo bajo 24 horas para problemas no críticos.
A menudo medidas a través de encuestas post-interacción, estas puntuaciones reflejan la felicidad general del cliente con el proceso de soporte. El enrutamiento efectivo contribuye a mayor satisfacción. Apunta a puntuaciones CSAT del 90% o superior, con los mejores ejecutantes a menudo logrando tasas de satisfacción del 95%+.
Esto mide qué tan a menudo los tickets necesitan ser escalados a niveles superiores de soporte. Tasas de escalación más bajas a menudo indican enrutamiento inicial más preciso. Esfuérzate por una tasa de escalación por debajo del 20%, con sistemas de mejor clase logrando tasas del 10% o menos.
Esta métrica observa cuántos tickets los agentes pueden manejar efectivamente después de implementar la solución de enrutamiento. El enrutamiento mejorado debería aumentar la productividad. Mide esto rastreando tickets resueltos por agente por día u hora, apuntando a una mejora del 10-20% después de implementar un nuevo sistema de enrutamiento.
Esto mide el porcentaje de tickets potenciales resueltos a través de opciones de autoservicio antes de entrar al sistema de enrutamiento. Tasas más altas indican triaje pre-enrutamiento efectivo. Apunta a una tasa de deflexión del 20-30%, con los mejores ejecutantes logrando tasas del 40% o superior.
Esta métrica calcula el costo promedio para resolver cada ticket de soporte. El enrutamiento eficiente debería ayudar a reducir este costo a lo largo del tiempo. Mientras que los puntos de referencia varían ampliamente, muchas organizaciones apuntan a reducir el costo por ticket en 10-15% después de implementar un sistema de enrutamiento mejorado.

Elegir el modelo Claude correcto

La elección del modelo depende de las compensaciones entre costo, precisión y tiempo de respuesta. Muchos clientes han encontrado que claude-3-5-haiku-20241022 es un modelo ideal para el enrutamiento de tickets, ya que es el modelo más rápido y costo-efectivo en la familia Claude 3 mientras aún entrega excelentes resultados. Si tu problema de clasificación requiere experiencia profunda en la materia o un gran volumen de categorías de intención con razonamiento complejo, puedes optar por el modelo Sonnet más grande.

Construir un prompt sólido

El enrutamiento de tickets es un tipo de tarea de clasificación. Claude analiza el contenido de un ticket de soporte y lo clasifica en categorías predefinidas basadas en el tipo de problema, urgencia, experiencia requerida u otros factores relevantes. Escribamos un prompt de clasificación de tickets. Nuestro prompt inicial debería contener los contenidos de la solicitud del usuario y devolver tanto el razonamiento como la intención.
Prueba el generador de prompts en la Consola Claude para que Claude escriba un primer borrador para ti.
Aquí hay un ejemplo de prompt de clasificación de enrutamiento de tickets:
def classify_support_request(ticket_contents):
    # Define the prompt for the classification task
    classification_prompt = f"""Actuarás como un sistema de clasificación de tickets de soporte al cliente. Tu tarea es analizar solicitudes de soporte al cliente y generar la intención de clasificación apropiada para cada solicitud, junto con tu razonamiento.

        Aquí está la solicitud de soporte al cliente que necesitas clasificar:

        <request>{ticket_contents}</request>

        Por favor analiza cuidadosamente la solicitud anterior para determinar la intención central y necesidades del cliente. Considera lo que el cliente está pidiendo o tiene preocupaciones sobre.

        Primero, escribe tu razonamiento y análisis de cómo clasificar esta solicitud dentro de etiquetas <reasoning>.

        Luego, genera la etiqueta de clasificación apropiada para la solicitud dentro de una etiqueta <intent>. Las intenciones válidas son:
        <intents>
        <intent>Soporte, Retroalimentación, Queja</intent>
        <intent>Seguimiento de Pedido</intent>
        <intent>Reembolso/Intercambio</intent>
        </intents>

        Una solicitud puede tener SOLO UNA intención aplicable. Solo incluye la intención que es más aplicable a la solicitud.

        Como ejemplo, considera la siguiente solicitud:
        <request>¡Hola! Tuve internet de fibra de alta velocidad instalado el sábado y mi instalador, Kevin, fue absolutamente fantástico! ¿Dónde puedo enviar mi reseña positiva? ¡Gracias por tu ayuda!</request>

        Aquí hay un ejemplo de cómo debería estar formateada tu salida (para la solicitud de ejemplo anterior):
        <reasoning>El usuario busca información para dejar retroalimentación positiva.</reasoning>
        <intent>Soporte, Retroalimentación, Queja</intent>

        Aquí hay algunos ejemplos más:
        <examples>
        <example 2>
        Entrada del Ejemplo 2:
        <request>Quería escribir y agradecerte personalmente por la compasión que mostraste hacia mi familia durante el funeral de mi padre este fin de semana pasado. Tu personal fue tan considerado y útil durante todo este proceso; realmente nos quitó una carga de los hombros. Los folletos de velatorio fueron hermosos. Nunca olvidaremos la bondad que nos mostraste y estamos muy agradecidos por lo suavemente que transcurrieron los procedimientos. Gracias, de nuevo, Amarantha Hill en nombre de la Familia Hill.</request>

        Salida del Ejemplo 2:
        <reasoning>El usuario deja una reseña positiva de su experiencia.</reasoning>
        <intent>Soporte, Retroalimentación, Queja</intent>
        </example 2>
        <example 3>

        ...

        </example 8>
        <example 9>
        Entrada del Ejemplo 9:
        <request>Tu sitio web sigue enviando ventanas emergentes de anuncios que bloquean toda la pantalla. Me tomó veinte minutos finalmente encontrar el número de teléfono para llamar y quejarme. ¿Cómo puedo posiblemente acceder a la información de mi cuenta con todas estas ventanas emergentes? ¿Puedes acceder a mi cuenta por mí, ya que tu sitio web está roto? Necesito saber cuál es la dirección registrada.</request>

        Salida del Ejemplo 9:
        <reasoning>El usuario solicita ayuda para acceder a la información de su cuenta web.</reasoning>
        <intent>Soporte, Retroalimentación, Queja</intent>
        </example 9>

        Recuerda incluir siempre tu razonamiento de clasificación antes de tu salida de intención real. El razonamiento debería estar encerrado en etiquetas <reasoning> y la intención en etiquetas <intent>. Devuelve solo el razonamiento y la intención.
        """
Desglosemos los componentes clave de este prompt:
  • Usamos f-strings de Python para crear la plantilla del prompt, permitiendo que el ticket_contents sea insertado en las etiquetas <request>.
  • Le damos a Claude un rol claramente definido como un sistema de clasificación que analiza cuidadosamente el contenido del ticket para determinar la intención central y necesidades del cliente.
  • Instruimos a Claude sobre el formato de salida apropiado, en este caso para proporcionar su razonamiento y análisis dentro de etiquetas <reasoning>, seguido por la etiqueta de clasificación apropiada dentro de etiquetas <intent>.
  • Especificamos las categorías de intención válidas: “Soporte, Retroalimentación, Queja”, “Seguimiento de Pedido” y “Reembolso/Intercambio”.
  • Incluimos algunos ejemplos (también conocido como prompting de pocos ejemplos) para ilustrar cómo debería estar formateada la salida, lo que mejora la precisión y consistencia.
La razón por la que queremos que Claude divida su respuesta en varias secciones de etiquetas XML es para que podamos usar expresiones regulares para extraer por separado el razonamiento y la intención de la salida. Esto nos permite crear pasos siguientes dirigidos en el flujo de trabajo de enrutamiento de tickets, como usar solo la intención para decidir a qué persona enrutar el ticket.

Desplegar tu prompt

Es difícil saber qué tan bien funciona tu prompt sin desplegarlo en un entorno de producción de prueba y ejecutar evaluaciones. Construyamos la estructura de despliegue. Comienza definiendo la firma del método para envolver nuestra llamada a Claude. Tomaremos el método que ya hemos comenzado a escribir, que tiene ticket_contents como entrada, y ahora devolver una tupla de reasoning e intent como salida. Si tienes una automatización existente usando ML tradicional, querrás seguir esa firma de método en su lugar.
import anthropic
import re

# Create an instance of the Claude API client
client = anthropic.Anthropic()

# Set the default model
DEFAULT_MODEL="claude-3-5-haiku-20241022"

def classify_support_request(ticket_contents):
    # Define the prompt for the classification task
    classification_prompt = f"""Actuarás como un sistema de clasificación de tickets de soporte al cliente. 
        ...
        ... El razonamiento debería estar encerrado en etiquetas <reasoning> y la intención en etiquetas <intent>. Devuelve solo el razonamiento y la intención.
        """
    # Send the prompt to the API to classify the support request.
    message = client.messages.create(
        model=DEFAULT_MODEL,
        max_tokens=500,
        temperature=0,
        messages=[{"role": "user", "content": classification_prompt}],
        stream=False,
    )
    reasoning_and_intent = message.content[0].text

    # Use Python's regular expressions library to extract `reasoning`.
    reasoning_match = re.search(
        r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
    )
    reasoning = reasoning_match.group(1).strip() if reasoning_match else ""

    # Similarly, also extract the `intent`.
    intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
    intent = intent_match.group(1).strip() if intent_match else ""

    return reasoning, intent
Este código:
  • Importa la biblioteca Anthropic y crea una instancia del cliente usando tu clave API.
  • Define una función classify_support_request que toma una cadena ticket_contents.
  • Envía el ticket_contents a Claude para clasificación usando el classification_prompt
  • Devuelve el reasoning e intent del modelo extraídos de la respuesta.
Dado que necesitamos esperar a que se genere todo el texto de razonamiento e intención antes de analizarlo, establecemos stream=False (el predeterminado).

Evaluar tu prompt

El prompting a menudo requiere pruebas y optimización para que esté listo para producción. Para determinar la preparación de tu solución, evalúa el rendimiento basado en los criterios de éxito y umbrales que estableciste anteriormente. Para ejecutar tu evaluación, necesitarás casos de prueba para ejecutarla. El resto de esta guía asume que ya has desarrollado tus casos de prueba.

Construir una función de evaluación

Nuestra evaluación de ejemplo para esta guía mide el rendimiento de Claude a lo largo de tres métricas clave:
  • Precisión
  • Costo por clasificación
Puedes necesitar evaluar a Claude en otros ejes dependiendo de qué factores son importantes para ti. Para evaluar esto, primero tenemos que modificar el script que escribimos y agregar una función para comparar la intención predicha con la intención real y calcular el porcentaje de predicciones correctas. También tenemos que agregar funcionalidad de cálculo de costo y medición de tiempo.
import anthropic
import re

# Create an instance of the Claude API client
client = anthropic.Anthropic()

# Set the default model
DEFAULT_MODEL="claude-3-5-haiku-20241022"

def classify_support_request(request, actual_intent):
    # Define the prompt for the classification task
    classification_prompt = f"""Actuarás como un sistema de clasificación de tickets de soporte al cliente. 
        ...
        ...El razonamiento debería estar encerrado en etiquetas <reasoning> y la intención en etiquetas <intent>. Devuelve solo el razonamiento y la intención.
        """

    message = client.messages.create(
        model=DEFAULT_MODEL,
        max_tokens=500,
        temperature=0,
        messages=[{"role": "user", "content": classification_prompt}],
    )
    usage = message.usage  # Get the usage statistics for the API call for how many input and output tokens were used.
    reasoning_and_intent = message.content[0].text

    # Use Python's regular expressions library to extract `reasoning`.
    reasoning_match = re.search(
        r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
    )
    reasoning = reasoning_match.group(1).strip() if reasoning_match else ""

    # Similarly, also extract the `intent`.
    intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
    intent = intent_match.group(1).strip() if intent_match else ""

      # Check if the model's prediction is correct.
    correct = actual_intent.strip() == intent.strip()

    # Return the reasoning, intent, correct, and usage.
    return reasoning, intent, correct, usage
Desglosemos las ediciones que hemos hecho:
  • Agregamos el actual_intent de nuestros casos de prueba al método classify_support_request y configuramos una comparación para evaluar si la clasificación de intención de Claude coincide con nuestra clasificación de intención dorada.
  • Extrajimos estadísticas de uso para la llamada API para calcular el costo basado en tokens de entrada y salida usados

Ejecutar tu evaluación

Una evaluación apropiada requiere umbrales y puntos de referencia claros para determinar qué es un buen resultado. El script anterior nos dará los valores de tiempo de ejecución para precisión, tiempo de respuesta y costo por clasificación, pero aún necesitaríamos umbrales claramente establecidos. Por ejemplo:
  • Precisión: 95% (de 100 pruebas)
  • Costo por clasificación: 50% de reducción en promedio (a través de 100 pruebas) del método de enrutamiento actual
Tener estos umbrales te permite decir rápida y fácilmente a escala, y con empirismo imparcial, qué método es mejor para ti y qué cambios podrían necesitar hacerse para ajustarse mejor a tus requisitos.

Mejorar el rendimiento

En escenarios complejos, puede ser útil considerar estrategias adicionales para mejorar el rendimiento más allá de las técnicas estándar de ingeniería de prompts y estrategias de implementación de barreras de seguridad. Aquí hay algunos escenarios comunes:

Usar una jerarquía taxonómica para casos con 20+ categorías de intención

A medida que el número de clases crece, el número de ejemplos requeridos también se expande, potencialmente haciendo el prompt difícil de manejar. Como alternativa, puedes considerar implementar un sistema de clasificación jerárquico usando una mezcla de clasificadores.
  1. Organiza tus intenciones en una estructura de árbol taxonómico.
  2. Crea una serie de clasificadores en cada nivel del árbol, habilitando un enfoque de enrutamiento en cascada.
Por ejemplo, podrías tener un clasificador de nivel superior que categorice ampliamente los tickets en “Problemas Técnicos”, “Preguntas de Facturación” y “Consultas Generales”. Cada una de estas categorías puede entonces tener su propio sub-clasificador para refinar más la clasificación.
  • Pros - mayor matiz y precisión: Puedes crear diferentes prompts para cada ruta padre, permitiendo clasificación más dirigida y específica al contexto. Esto puede llevar a precisión mejorada y manejo más matizado de solicitudes de clientes.
  • Contras - latencia aumentada: Ten en cuenta que múltiples clasificadores pueden llevar a latencia aumentada, y recomendamos implementar este enfoque con nuestro modelo más rápido, Haiku.

Usar bases de datos vectoriales y búsqueda de similitud de recuperación para manejar tickets altamente variables

A pesar de que proporcionar ejemplos es la forma más efectiva de mejorar el rendimiento, si las solicitudes de soporte son altamente variables, puede ser difícil incluir suficientes ejemplos en un solo prompt. En este escenario, podrías emplear una base de datos vectorial para hacer búsquedas de similitud de un conjunto de datos de ejemplos y recuperar los ejemplos más relevantes para una consulta dada. Este enfoque, delineado en detalle en nuestra receta de clasificación, ha demostrado mejorar el rendimiento del 71% de precisión al 93% de precisión.

Considerar específicamente casos extremos esperados

Aquí hay algunos escenarios donde Claude puede clasificar mal los tickets (puede haber otros que son únicos a tu situación). En estos escenarios, considera proporcionar instrucciones explícitas o ejemplos en el prompt de cómo Claude debería manejar el caso extremo:
Los clientes a menudo expresan necesidades indirectamente. Por ejemplo, “He estado esperando mi paquete por más de dos semanas ahora” puede ser una solicitud indirecta de estado de pedido.
  • Solución: Proporciona a Claude algunos ejemplos reales de clientes de estos tipos de solicitudes, junto con cuál es la intención subyacente. Puedes obtener resultados aún mejores si incluyes una justificación de clasificación para intenciones de tickets particularmente matizadas, para que Claude pueda generalizar mejor la lógica a otros tickets.
Cuando los clientes expresan insatisfacción, Claude puede priorizar abordar la emoción sobre resolver el problema subyacente.
  • Solución: Proporciona a Claude direcciones sobre cuándo priorizar el sentimiento del cliente o no. Puede ser algo tan simple como “Ignora todas las emociones del cliente. Enfócate solo en analizar la intención de la solicitud del cliente y qué información el cliente podría estar pidiendo.”
Cuando los clientes presentan múltiples problemas en una sola interacción, Claude puede tener dificultad identificando la preocupación principal.
  • Solución: Clarifica la priorización de intenciones para que Claude pueda clasificar mejor las intenciones extraídas e identificar la preocupación principal.

Integrar Claude en tu flujo de trabajo de soporte mayor

La integración apropiada requiere que tomes algunas decisiones respecto a cómo tu script de enrutamiento de tickets basado en Claude encaja en la arquitectura de tu sistema de enrutamiento de tickets mayor. Hay dos formas en que podrías hacer esto:
  • Basado en push: El sistema de tickets de soporte que estás usando (ej. Zendesk) activa tu código enviando un evento webhook a tu servicio de enrutamiento, que luego clasifica la intención y la enruta.
    • Este enfoque es más escalable web, pero necesita que expongas un endpoint público.
  • Basado en pull: Tu código extrae los últimos tickets basado en un horario dado y los enruta en el momento de extracción.
    • Este enfoque es más fácil de implementar pero podría hacer llamadas innecesarias al sistema de tickets de soporte cuando la frecuencia de extracción es demasiado alta o podría ser excesivamente lento cuando la frecuencia de extracción es demasiado baja.
Para cualquiera de estos enfoques, necesitarás envolver tu script en un servicio. La elección del enfoque depende de qué APIs proporciona tu sistema de tickets de soporte.