El control de calidad en Salesforce Service Cloud consiste en evaluar las respuestas que escribió un agente, el canal y el estado en que quedó el caso. Decida primero qué cuenta como la conversación, porque un caso reúne muchos registros relacionados.
En resumen
- El propietario del caso a menudo no escribió la respuesta.
- Vincule cada criterio a un campo que exista en su org.
- Defina la población de la muestra con un informe.
- Decida antes del despliegue cómo evaluar los casos con varios canales.
Qué significa realmente el control de calidad en Salesforce Service Cloud
La mayoría de las guías de QA dan por hecho un ticket: un cliente, un hilo, un responsable asignado, leído de arriba abajo. Service Cloud no funciona así, y esa única diferencia estructural es la razón por la que los consejos genéricos de QA suelen desmoronarse en la primera semana.
Un caso es un registro. Lleva campos como estado, origen, motivo, prioridad y propietario, aunque los valores de esas listas de selección los configura su propio administrador y no los fija la plataforma. Alrededor de ese registro está lo que el cliente y el agente hicieron de verdad: correos electrónicos, transcripciones de chat o mensajería, publicaciones internas, tareas y, cuando la org tiene la voz habilitada, registros de llamadas. El feed del caso muestra una cronología de esa actividad, pero una cronología no es lo mismo que una conversación. Mezcla respuestas de agentes con entradas del sistema, cambios de campos y publicaciones de personas que nunca hablaron con el cliente.
Así que la primera pregunta del control de calidad en Service Cloud no es «qué debemos evaluar». Es a qué llamamos la conversación. Hay tres respuestas defendibles, y usted tiene que elegir una de forma deliberada:
- Solo el intercambio con el cliente. Cada mensaje que el cliente pudo ver, en orden, sin las publicaciones internas ni el historial de campos. Es lo más parecido a un hilo de ticket y lo más fácil de explicar a un agente.
- El intercambio más el estado del registro. Los mismos mensajes, juzgados junto con la forma en que el caso se categorizó y se cerró. Adecuado para equipos cuya calidad de datos alimenta los reportes.
- El caso completo, incluido el trabajo interno. Mensajes, notas internas, traspasos y tareas. La visión más completa y la más difícil de evaluar de forma coherente, porque los revisores no se ponen de acuerdo sobre cuánto trabajo interno es suficiente.
Ponga la respuesta por escrito antes de escribir los criterios. Si no lo hace, cada revisor elige la suya en silencio y aparece el patrón de desacuerdo que todo responsable de QA reconoce: dos personas evalúan el mismo caso con 60 y 85, y ninguna sabe decir por qué. La mecánica de la scorecard que se apoya en esto es la misma que en cualquier programa de QA de atención al cliente, y si todavía no ha creado una, empiece por cómo crear una scorecard de QA y vuelva después.
Qué se puede evaluar en un caso y qué no
Antes de escribir criterios, tome un caso cerrado recientemente y haga inventario de lo que realmente contiene. Hágalo en su propia org y no a partir de una plantilla, porque lo que está presente varía muchísimo según cómo se haya configurado la org.
Normalmente disponible
- Mensajes escritos por agentes. Las respuestas por correo electrónico, los turnos de chat o mensajería y cualquier publicación pública. Es la evidencia central para todo lo relacionado con la comunicación.
- Marcas de tiempo. Cuándo escribió el cliente, cuándo respondió el agente, cuándo cambió el propietario, cuándo se cerró el caso. Suficiente para razonar sobre la capacidad de respuesta, con las salvedades que se indican más abajo.
- Valores de los campos al cierre. Estado, motivo, campos de producto o categoría y cualquier campo personalizado que exija su org. Es lo que permite incluir un caso en los reportes, así que forma parte legítima de la calidad.
- Notas y publicaciones internas. La calidad del traspaso, la investigación, el razonamiento detrás de un escalamiento.
- Historial de propietarios. Quién tuvo el caso y cuándo cambió de manos.
A menudo ausente, y conviene comprobarlo antes de prometer un criterio
- Voz. Que haya una llamada adjunta, y que exista una transcripción en lugar de solo una grabación o una nota, depende de cómo esté habilitada la voz en su org. Confírmelo antes de escribir un criterio que dependa del contenido de la llamada.
- Lo que el agente podía ver. La seguridad a nivel de campo y las reglas de uso compartido hacen que la vista del revisor sobre un caso no sea necesariamente la del agente. Si un criterio da por hecho que el agente tenía una información, verifique que la tenía.
- El estado de la base de conocimientos en ese momento. Si un artículo cambió después del cierre del caso, puede que el agente tuviera razón según la versión que tenía.
- Todo lo que ocurrió fuera del registro. Una devolución de llamada registrada como una nota de una línea, una conversación en una herramienta de chat, un traspaso en persona a otro equipo. Es trabajo real y resulta invisible para QA.
La regla que se deriva es breve. Si un criterio no se puede demostrar con algo que esté en el caso, no es un criterio de QA, es una opinión. O encuentra el campo o el mensaje que lo demuestra, o lo saca de la scorecard y lo lleva al coaching. Una checklist de QA de atención al cliente genérica es un buen inventario de partida, pero cada línea tiene que superar esta prueba frente al formato de página de sus propios casos.
Cómo llevar los datos del caso a los criterios de la scorecard
Este es el ejercicio de correspondencia que hace o deshace el programa. Para cada criterio, nombre la evidencia, nombre la comprobación y nombre el modo de fallo que espera. La última columna es la que los equipos se saltan, y es la que predice cada discusión que va a tener.
| Tipo de criterio | Evidencia en el caso | Cómo lo comprueba un revisor | Dónde falla |
|---|---|---|---|
| Exactitud de la resolución | El último mensaje del agente, leído frente a los campos con los que se cerró el caso | ¿Coincide la respuesta dada con el resultado registrado, y era correcta en ese momento? | El estado lo establece una automatización o una macro, así que el registro dice «resuelto» sin ninguna evidencia de que lo estuviera |
| Cumplimiento del proceso | Campos obligatorios, notas internas y cualquier registro de derechos de asistencia o nivel de servicio que haya configurado la org | Comparar lo que registra el caso con su proceso documentado para ese tipo de caso | El requisito vive en una wiki y no en un campo, así que dos revisores aplican dos versiones distintas |
| Calidad de la comunicación | Solo los mensajes escritos por agentes, nunca el feed completo | Evaluar el texto que el cliente realmente podía leer | Los revisores absorben el tono de las publicaciones internas y las entradas del sistema y se lo atribuyen al agente |
| Capacidad de respuesta y esfuerzo | Marcas de tiempo de los mensajes y de los cambios de propietario | Medir los intervalos entre un mensaje del cliente y la siguiente respuesta del agente | El tiempo en cola, el horario laboral y la espera a otro equipo se cargan a quien tenga el caso en ese momento |
| Categorización y calidad de datos | Origen, motivo, tipo de registro y sus propios campos de reporte | ¿Describen los valores lo que realmente pasó en la conversación? | Los agentes eligen el valor que supera antes la regla de validación, y nadie lo había evaluado hasta ahora |
| Enrutamiento | Historial de propietarios, pertenencia a colas, tipo de registro | ¿Llegó el caso primero al equipo correcto, y si no, por qué? | Un enrutamiento erróneo causado por una regla de enrutamiento se evalúa como un fallo del agente |
En qué se diferencia evaluar un caso de evaluar un ticket de Zendesk
Muchos responsables de operaciones de atención al cliente han hecho QA en Zendesk y ahora se les pide hacerlo en Service Cloud, o en ambos a la vez. La filosofía de la scorecard se puede trasladar. La mecánica no, y estas son las seis diferencias que más tiempo cuestan. Si también gestiona el lado de Zendesk, la mecánica específica de esa plataforma se trata por separado en control de calidad para Zendesk.
| Dimensión | Ticket de Zendesk | Caso de Salesforce Service Cloud |
|---|---|---|
| La unidad de revisión | Un ticket es un hilo. Solicitante, responsable asignado y comentarios se leen como una sola conversación lineal | Un caso es un registro. La conversación se arma a partir de mensajes, transcripciones y elementos del feed relacionados |
| Quién hizo el trabajo | El responsable asignado más los autores visibles de los comentarios | El campo propietario indica quién tiene el caso ahora. La autoría hay que leerla en cada mensaje |
| Canal | Normalmente una propiedad del propio ticket | Los canales llegan como registros relacionados distintos, y un caso puede incluir más de uno |
| Definir la población de la muestra | Vistas y filtros de búsqueda | Un informe o una vista de lista basados en los campos de caso propios de su org |
| Cuánto es estándar | El conjunto de campos es en general coherente entre cuentas | Los tipos de registro, los campos personalizados y los valores de las listas de selección se configuran por org, así que ninguna scorecard se traslada sin cambios |
| Estado de cierre | Un conjunto corto y conocido de estados | Los valores de estado, y lo que cada uno significa en la operación, los define su administrador |
Cómo sacar una muestra que pueda defender
La acusación más habitual contra un programa de QA es que el revisor eligió los peores casos. En Service Cloud esa acusación es fácil de hacer, porque no existe una cola de revisión natural y resulta muy tentador trabajar con la vista de lista que ya está abierta.
Defina primero la población, en un informe, y guarde el informe. Un filtro práctico: fecha de cierre dentro del periodo de revisión, tipo de registro o cola que identifique el trabajo que evalúa, canal si evalúa los canales por separado, y una exclusión para los casos sin ningún mensaje escrito por un agente. Los duplicados, los casos cerrados automáticamente y los que nunca llegaron a una persona son ruido, y dejarlos en la población infla o desinfla en silencio cada promedio que publique después.
Después, saque la muestra de esa población y no de la lista. Hay dos reglas que importan más que el tamaño de la muestra:
- Aleatorice dentro de estratos, no en todo el conjunto. Estratifique por agente y por tipo de caso, y luego extraiga al azar dentro de cada estrato. Un muestreo puramente aleatorio sobre todo un mes da veinte casos a sus agentes más ocupados y uno a su agente más nuevo, lo que hace que las notas individuales no sean comparables.
- Fije la muestra antes de que nadie lea un caso. Extraiga la lista, guárdela y revise lo que extrajo. Una muestra elegida después de que el revisor haya hojeado la población no es una muestra.
Sea honesto consigo mismo sobre lo que le da una muestra manual. Revisar treinta casos por agente al mes es mucho trabajo y aun así le dice muy poco sobre los tipos de caso concretos que ocurren rara vez y hacen más daño. Esa limitación es aritmética, no de esfuerzo, y es la misma restricción que plantea el manual de ingeniería del NIST cuando pregunta si una proporción de defectuosos obtenida en una muestra cumple un requisito: la muestra tiene que ser lo bastante grande para que la prueba sea válida antes de que la respuesta signifique algo. Por eso una nota obtenida por muestreo y un puntaje de calidad interno que se presenta a la dirección deben llevar su intervalo de confianza junto a la cifra, y por eso vale la pena saber dónde el muestreo de QA deja de poder responder la pregunta.
Quién escribió la respuesta: la atribución en un caso que cambió de manos
Este es el problema para el que ninguna plantilla le prepara, y el que más daña la confianza de los agentes en un programa de QA en Service Cloud.
Los casos se mueven. Se enrutan, se escalan, se reasignan, se toman de una cola, se pasan a un equipo especializado y se devuelven. El campo propietario registra quién tiene el caso en el momento en que usted lo mira. No registra quién escribió la respuesta que molestó al cliente, ni quién hizo la investigación que lo resolvió. Si su proceso de QA evalúa un caso y asigna el resultado al propietario, en cada caso transferido habrá atribuido el trabajo de una persona a otra.
La consecuencia práctica es predecible y concreta. Los agentes que gestionan los escalamientos heredan casos que ya van mal y se llevan las notas resultantes. Suelen ser sus personas más capaces. En un trimestre aprenden que aceptar un caso difícil les cuesta, y el comportamiento que usted más quería fomentar se convierte en el que su marcador castiga.
Cuatro reglas que lo solucionan
- Evalúe el mensaje, no el registro. Cada penalización debe ir ligada a un mensaje concreto escrito por un agente, con marca de tiempo y autor, y no al caso en su conjunto.
- Atribuya por autor. Lea la autoría en cada mensaje y no en el campo propietario. Si sus reportes no pueden hacerlo, es lo primero que hay que arreglar, antes de ajustar una sola ponderación.
- Trate de forma explícita los casos con varios agentes. O evalúa por separado la contribución de cada agente, o excluye el caso de la evaluación individual y lo usa para revisar el proceso. Ambas opciones son defendibles. Evaluar en silencio al último propietario no lo es.
- Mantenga el historial de propietarios junto a la nota. Cuando se disputa una nota, la primera pregunta siempre es quién hizo qué. Si la respuesta lleva veinte minutos de reconstrucción, la disputa ya está perdida.
Los casos transferidos son además su fuente más rica para trabajar en procesos y no en coaching individual. Un caso que cambió de manos cuatro veces antes de resolverse le está diciendo algo sobre el enrutamiento, los derechos de asistencia o los límites entre equipos, y eso pertenece al análisis de causa raíz y no a la scorecard de alguien.
Evaluar todos los casos en lugar de una muestra
Una vez asentado el método manual, la pregunta obvia es si puede dejar de muestrear. Puede, y el argumento a favor es más fuerte en Service Cloud que en un modelo de tickets más simple, porque los tipos de caso que más importan suelen ser los poco frecuentes, los que una muestra nunca alcanza. Hay una diferencia real entre una cobertura del 100% que revela tendencias que una muestra del 3% nunca podría mostrar, y una revisión mensual de treinta casos por agente.
La cobertura por sí sola no es lo interesante, sin embargo, y tampoco es ya un factor diferenciador. Todos los proveedores de esta categoría evalúan ya todo. La pregunta que decide si una nota automatizada sobrevive al contacto con su equipo es si usted puede demostrar que la evaluación acertó. En Service Cloud en concreto, eso significa cuatro cosas:
- Trazabilidad hasta el caso. Una penalización tiene que nombrar el criterio y señalar el mensaje exacto del caso que la provocó. «Comunicación: menos diez» en un caso con cuarenta elementos en el feed no sirve de nada.
- La misma evidencia que usó la evaluación. Un revisor que comprueba una nota debe ver el conjunto de mensajes con el que se calculó la nota, no un resumen.
- Una vía de disputa. Un agente tiene que poder impugnar una nota y conseguir que alguien revise el razonamiento. Si no puede, la nota es un veredicto.
- Acuerdo medido antes de que cuente. Ejecute la nota automatizada en paralelo con sus propios revisores sobre los mismos casos durante unas semanas y valide la evaluación antes de vincular la cifra a cualquier cosa con consecuencias.
El Auto QA de Kaizo aplica los criterios de su propia scorecard a los casos y mantiene el razonamiento unido a la conversación, de modo que una penalización disputada puede rastrearse hasta el intercambio que la causó en lugar de discutirse de memoria. Funciona en Service Cloud mediante la integración con Salesforce, descrita con más detalle en Kaizo en Salesforce, junto a la misma integración para Zendesk, algo importante si hace QA en ambas plataformas mientras hay una migración en curso. Reservar una demo.
Un despliegue que sobrevive a la primera disputa
Los programas de QA en Service Cloud fracasan en el mismo punto: la primera vez que un agente impugna en serio una nota y el programa no sabe responder. Ordene el despliegue para que la respuesta exista antes que la impugnación.
| Etapa | Qué hace | Terminado cuando |
|---|---|---|
| 1. Definir la unidad | Elegir una de las tres definiciones de la conversación y ponerla por escrito. Hacer inventario de lo que realmente hay en un caso cerrado de su org | Un revisor puede decir, sin titubear, qué registros entran |
| 2. Vincular criterios a campos | Para cada criterio, nombrar la evidencia, la comprobación y el modo de fallo esperado. Descartar todo lo que no se pueda demostrar | Cada criterio apunta a un campo o a un tipo de mensaje que existe |
| 3. Crear el informe de población | Un informe guardado que define el conjunto revisable, con exclusiones para los casos cerrados automáticamente y los casos sin agente | Dos personas que ejecutan el informe obtienen el mismo número de casos |
| 4. Evaluación en paralelo y calibración | Tres revisores evalúan por separado los mismos quince casos, incluidos al menos tres que cambiaron de propietario. Comparar y discutir | Conoce la tasa de desacuerdo de sus revisores, y está bajando |
| 5. Publicar con una vía de apelación | Anunciar a la vez la scorecard, el método de muestreo y el proceso de apelación. Una apelación sin vía es una queja | Los agentes pueden nombrar el proceso sin buscarlo |
| 6. Reportar y revisar la correspondencia | Reportar las notas junto a resultados operativos como reaperturas y escalamientos. Revisar la correspondencia cada trimestre | El movimiento de la nota explica algo que un manager ya sospechaba |
Cómo reportar la nota de un caso para que alguien actúe
Una nota de QA que solo vive en una herramienta de QA la lee el equipo de QA. Para que el esfuerzo merezca la pena, la nota tiene que estar junto a las cifras operativas que la dirección de atención al cliente ya mira, y desglosarse de forma que señale una acción.
Tres cortes hacen la mayor parte del trabajo con los datos de Service Cloud:
- Por tipo de caso o tipo de registro, no solo por agente. La calidad varía mucho más según el tipo de trabajo que según la persona que lo hace. Un promedio bajo en un tipo de registro es un problema de proceso, de conocimiento o de enrutamiento, y se puede corregir de forma centralizada.
- Por criterio, en todo el equipo. Un criterio que falla de forma generalizada casi nunca es un problema de coaching. Es una política poco clara, un artículo de conocimiento que falta o un criterio mal redactado.
- La nota frente a la tasa de reapertura y de escalamiento. Este es el control de la propia scorecard. Si los casos con nota alta se reabren al mismo ritmo que los de nota baja, la scorecard mide algo distinto de la calidad y hay que volver a ponderarla.
Ese tercer corte es el que vale la pena proteger. Es lo que impide que un programa de QA derive en un ritual de cumplimiento que todos ejecutan y nadie usa. Unir las notas de calidad con la imagen operativa es justo para lo que sirve una vista de analítica de atención al cliente, y es también la forma más rápida de demostrar a una dirección escéptica que el programa de QA mide algo real.
Preguntas frecuentes
¿Salesforce Service Cloud incluye evaluación de QA de serie?
Service Cloud le da la materia prima: el registro del caso, los mensajes y transcripciones relacionados con él, el historial de campos y una capa de reportes sobre todo ello. Una scorecard ponderada, una cola de revisión, la calibración entre revisores y un registro de apelaciones auditable no forman parte del objeto caso estándar. Los equipos o bien crean una versión ligera con campos personalizados e informes, que funciona hasta que el desacuerdo entre revisores se convierte en el cuello de botella, o bien añaden una herramienta de QA que lee los casos. Compruebe lo que su propia org ya tiene configurado antes de dar nada por hecho, porque la personalización varía enormemente.
¿Qué debe evaluar en un caso de Salesforce?
Solo lo que el caso demuestra. En la práctica, son los mensajes escritos por agentes, las marcas de tiempo de esos mensajes y de los cambios de propietario, los valores de los campos con los que se cerró el caso y las notas internas si su definición de la conversación las incluye. Todo lo que no pueda señalar en el registro, como lo que el agente sabía en ese momento o una devolución de llamada registrada como una nota de una línea, pertenece al coaching y no a una nota.
¿En qué se diferencia el QA en Service Cloud del QA en Zendesk?
La filosofía de la scorecard es la misma, la mecánica no. Un ticket de Zendesk es un hilo lineal con un responsable asignado claro, así que la unidad de revisión es evidente. Un caso de Salesforce es un registro con mensajes, transcripciones y elementos del feed relacionados, así que la unidad la tiene que definir usted. Además, la autoría hay que leerla en cada mensaje y no en el campo propietario, y como los tipos de registro y los campos personalizados se configuran por org, ninguna scorecard se traslada sin cambios entre dos orgs de Salesforce.
¿Cómo se muestrean los casos de Salesforce para la revisión de QA?
Cree un informe guardado que defina la población, con filtros por fecha de cierre, tipo de registro o cola, canal cuando proceda, y excluyendo los casos sin mensajes escritos por un agente. Después extraiga al azar dentro de estratos, por agente y por tipo de caso, y no al azar sobre todo el mes, para que cada agente aporte un número comparable de casos. Fije la muestra antes de que nadie abra un caso. Revisar una lista que ya ha hojeado no es muestrear.
¿Quién recibe la nota de QA cuando un caso cambia de propietario?
No automáticamente el propietario actual, que es la opción por defecto en la que caen la mayoría de los programas y la que más daño hace. Atribuya cada mensaje evaluado a quien lo escribió. En un caso gestionado por varias personas, o evalúa por separado la contribución de cada agente, o saca el caso de la evaluación individual y lo usa para revisar el proceso. Evaluar al último propietario por un trabajo que heredó enseña a sus mejores agentes a evitar los escalamientos.
¿Se pueden evaluar correo electrónico, chat y voz en el mismo caso?
Sí, pero decida el enfoque antes del despliegue y no durante la primera disputa. Una única nota combinada sobre un caso que contiene un hilo de correo y una transcripción de chat es difícil de usar en coaching, porque los estándares de ambos son realmente distintos. Evaluar cada tramo de canal por separado y reportarlos por separado suele ser más claro. Si hay voz de por medio, confirme primero si su org tiene de verdad transcripciones adjuntas y no solo grabaciones, porque un criterio que depende del contenido de una llamada no se puede aplicar sin ellas.
