CSX (Customer Service Excellence)

El servicio de CSX (Customer Service Excellence) facilita la atención a clientes, el registro y seguimiento de casos al permitir realizar una completa trazabilidad de las incidencias que ocurran en cualquier fase de la operación omnicanal.

La función principal del servicio radica en el módulo Helpdesk, donde se realiza la configuración, creación, registro y seguimiento de todos los tickets.

1. ¿Cómo configurar el módulo?

Para realizar la configuración inicial es necesario definir y configurar punto por punto lo siguiente:

1.A. Canales

Los Canales corresponden al medio, canal o área desde la cual ingresa el reclamo, por ejemplo podrían ser vía Call-Center, Formulario web, Defensa al consumidor, entre otros. Son principalmente una forma de segmentación para su posterior tratamiento estadístico.

1.B. Motivos

Los Motivos indican las causas por la cuál se quiere generar un ticket de helpdesk.Son formas de agrupamiento de incidencias que luego nos permitirán canalizar su atendimiento, segmentarlo y obtener estadísticas precisas sobre los tipos de causa principales. Ejemplos:

  • Reclamos
  • Felicitaciones
  • Sugerencias

1.C. Tipos de Motivos

Corresponden a los tipos de incidencia/motivos específicos (Cambio de color/talle,Producto en mal estado, Entrega fuera de hora), su SLA, Prioridad y Área a cargo.

Los Tipos de incidencia están vinculados a un Motivo, y al momento de la creación de un ticket -seleccionado el motivo- se segmentan las opciones disponibles para ese tipo de incidencia.

Ejemplo:

  • Motivo/ Ejemplo: Reclamo
  • Tipo (Nivel 1) / Ejemplo: Pedido incompleto
  • Subtipo: (Nivel 2) / Ejemplo: Canasto extraviado
  • Subtipo: (Nivel 3) / Ejemplo: Canasto perdido en ruta

📘

Niveles de segmentación

Pueden existir hasta 3 niveles de segmentación:

  • Motivo
  • Tipo (Nivel 1)
  • Subtipo (Nivel 2)
  • Subtipo (Nivel 3)

Este mix de configuraciones determina el tratamiento que deberá seguir cada incidencia hasta su resolución. Contando con las siguientes opciones:

  • Validación a las entidades que aplica:En la configuración del tipo se podrá indiciar si el "Tipo" puede asociarse:
    • Lógistica: Para escenarios en que el caso se deba generar automáticamente desde Janis Delivery APP.
    • Default (stockout): Cuando el caso se debe a un quiebre de stock.
    • Pedidos: Cuando el caso se asocia a un pedido completo.
    • ítems: Cuando el caso se asocia a un ítem específico de un pedido de un pedido o ambos.
  • Área a cargo: Permite identificar la/s Áreas operativas vinculadas a la incidencia (a modo de alertas y reportes)
  • Procesos afectados: Se pueden taggear los procesos que pueden verse afectados por esta incidencia (a modo de alertas y reportes).
  • Compensaciones: Identifica las posibles compensaciones que tendrá el operario de Atención al cliente para ofrecer a los clientes en caso de necesitarlo.
  • SLA del reclamo: Cada tipología de incidencia posee un SLA, que determina la caducidad del reclamo o bien su fecha de compromiso con el cliente. La misma puede ser configurada en Horas, Días y Semanas. El SLA medirá el cumplimiento o no de un reclamo, así como permitirá configurar acciones o reacciones específicas una vez sobrepasado el tiempo de SLA sin que el caso haya podido resolverse.

🚧

Configuración previa

Para poder cargar un Tipo de Motivo se deberá previamente tener configurados Compensaciones, áreas de soporte a cargo y los procesos afectados.

1.D. Estados

Los Estados son las etapas genéricas por las que debe pasar un ticket/reclamo, sea cual fuera su tipología, desde que es ingresado en el sistema hasta su posterior y final resolución, pasando por diferentes estatus intermedios que podrán ser ordenados en las Transiciones (Ver punto siguiente).

En este ordenamiento, es fundamental determinar el estatus inicial y final de las incidencias, a fin de definir el estatus de un reclamo desde su apertura hasta su finalización.

  • Inicial: Todos los reclamos o casos creados, sin importar su tipología, serán ingresados con este estado. Sólo se podrá generar 1 Estado inicial, y será la opción default para toda incidencia, cualquiera sea su tipo (ej.: Nuevo).
  • Final: Corresponde al último estado posible de una incidencia, la cual ya no podrá ser modificada. Pueden existir 1 o varios Estados finales, que serán aquellos en los cuales una Incidencia se dará por resuelta (ej.: Cerrada, Cancelada, Solucionada).
  • Notificable: Indica si cuando un caso pase a este estado, se deberá notificar vía Webhook.

1.E. Transiciones

Las Transiciones determinan los posibles pasajes de Estado de una incidencia, cualquiera sea su Tipo, permitiendo personalizar el flujo que debe seguir una incidencia desde su ingreso hasta su resolución. Determinan entonces los estados a los que podrá moverse una incidencia desde un estado previo.

Por ejemplo:

  • (Estado Inicial) Nuevo > En análisis
  • En análisis > Verificado
  • Verificado > Resuelto (Estado Final)

Además existe la posibilidad de establecer un color para la transición.

1.F. Módulos adicionales

Como módulos adicionales para el manejo de tickets se cuenta con:

  • Resolución de incidencias: Acciones puntuales de resolución que activarán las acciones post-venta (cambio de talle, anulación y creación de nota de crédito, etc)
  • Gestiones: Son las opciones de resolución disponibles según el tipo de incidencia. Los status de la gestión corresponden al paso a paso que deben seguir los operadores para resolver la incidencia según su tipo.
  • Compensaciones: Herramientas que tendrá disponible el operador de Customer Care para ofrecer al cliente según el tipo de incidencia.
  • Semaforización: Permite establecer alertas gráficas según pase el tiempo y se vaya acercando el límite de SLA y la incidencia siga sin resolverse.

2. ¿Cómo crear un ticket de CSX?

Ya se podrá generar un ticket una vez que se hayan definido las configuraciones del punto anterior, . Un ticket está formado por distintos niveles de información, que determinarán su forma de tratamiento, posibles resoluciones, tiempos de respuesta (SLA), entre otros.

Como definiciones principales, una ticket estará siempre asociada a un Cliente (nuevo o existente), ya sea que la misma se ingrese para un Pedido o Cliente en particular:

  • Cliente: Ya sea nuevo o existente, un reclamo siempre estará asociado a un cliente.
  • Pedido (sobre un pedido específico): En caso de que el reclamo sea sobre un pedido realizado, se podrá vincular con el mismo para mostrar toda la información y acciones necesarias para su identificación y tratamiento. Al seleccionar un pedido, el sistema bloqueará los campos de Cliente y Tienda, ya que estos son datos ya vinculados internamente

Además, una incidencia estará siempre conformada y determinada por distintos factores de organización que segmentan y determinarán la forma de abordarla:

  • Canal: Medio desde el cual se registra el ingreso de la incidencia (ej.: Atención telefónica, Email, Redes sociales)
    Motivos: Corresponde al primer nivel de identificación del caso (ej.: Reclamo, Sugerencia, Consulta)
  • Tipos de reclamo: El Tipo de incidencia es el nivel más específico de caracterización o tipificación de la misma, determinando con éste el tratamiento que se le dará a cada incidencia. Al indicar el tipo de reclamo el SLA y la prioridad se toman de lo ya configurado, permitiendo cambios manuales antes de la creación.

2.A. Generar reclamos por ítems

Desde un ticket existe la posibilidad de poder relacionar a cada ítem del pedido una resolución.

Esto desde el apartado de Productos dentro del ticket, donde por cada item se tendrá la opción de crear un reclamo donde se podrá capturar y subtipificar el tipo y la resolución así como asignar una cantidad y un precio.

Dentro del reclamo, se deberá indicar Tipo}, Resolución para reclamo de ítem, Área a cargo y la respectiva cantidad y precio del ítem sobre el que se está haciendo el reclamo.

Una vez confirmado el reclamo asociado al ítem, se podrá visualizar dentro del mismo ticket.