Fazer monitoria de qualidade no Salesforce Service Cloud significa avaliar as respostas que o atendente escreveu, o canal e o estado em que o caso ficou. Antes de tudo, decida o que conta como a conversa, porque um caso reúne muitos registros relacionados.
Em resumo
- Muitas vezes, o proprietário do caso não foi quem escreveu a resposta.
- Ligue cada critério a um campo que existe na sua org.
- Defina a população da amostra com um relatório.
- Decida antes da implantação como avaliar casos com vários canais.
O que monitoria de qualidade no Salesforce Service Cloud significa na prática
A maior parte das orientações sobre QA parte de um ticket: um cliente, uma thread, um responsável, lido de cima para baixo. O Service Cloud não funciona assim, e essa única diferença estrutural é o motivo pelo qual os conselhos genéricos de QA costumam desmoronar já na primeira semana.
Um caso é um registro. Ele tem campos como status, origem, motivo, prioridade e proprietário, embora os valores dessas listas de opções sejam configurados pelo seu próprio administrador e não fixados pela plataforma. Em volta desse registro está o que o cliente e o atendente realmente fizeram: e-mails, transcrições de chat ou de mensagens, publicações internas, tarefas e, quando a org tem voz provisionada, registros de chamadas. O feed do caso mostra a cronologia dessa atividade, mas uma cronologia não é a mesma coisa que uma conversa. Ela mistura respostas do atendente com entradas do sistema, alterações de campos e publicações de pessoas que nunca falaram com o cliente.
Por isso, a primeira pergunta da monitoria no Service Cloud não é “o que devemos avaliar”. É o que estamos chamando de conversa. Existem três respostas defensáveis, e você precisa escolher uma de forma deliberada:
- Só a troca visível para o cliente. Toda mensagem que o cliente podia ver, em ordem, ignorando publicações internas e histórico de campos. É o que mais se parece com a thread de um ticket e o mais fácil de explicar a um atendente.
- A troca mais o estado do registro. As mesmas mensagens, avaliadas junto com a forma como o caso foi categorizado e encerrado. Indicado para equipes cuja qualidade de dados alimenta os relatórios.
- O caso inteiro, incluindo o trabalho interno. Mensagens, notas internas, transferências e tarefas. A visão mais completa, e a mais difícil de avaliar de forma consistente, porque os avaliadores discordam sobre quanto trabalho interno é suficiente.
Registre a resposta antes de escrever os critérios. Se não fizer isso, cada avaliador escolhe a sua em silêncio, e você chega ao padrão de divergência que todo líder de QA reconhece: duas pessoas dão sessenta e oitenta e cinco ao mesmo caso, e nenhuma consegue dizer por quê. A mecânica do formulário que fica por cima disso é a mesma de qualquer programa de monitoria de atendimento, e se você ainda não montou o seu, comece por como montar uma planilha de monitoria de qualidade e depois volte.
O que dá para avaliar em um caso, e o que não dá
Antes de escrever os critérios, pegue um caso encerrado recentemente e faça o inventário do que realmente está nele. Faça isso na sua própria org e não a partir de um modelo, porque o que está presente varia muito conforme a configuração da org.
Normalmente disponível
- Mensagens escritas pelo atendente. As respostas por e-mail, os turnos de chat ou de mensagens e as publicações públicas. É a evidência central para tudo o que diz respeito à comunicação.
- Registros de data e hora. Quando o cliente escreveu, quando o atendente respondeu, quando a propriedade mudou, quando o caso foi encerrado. Suficiente para analisar a capacidade de resposta, com as ressalvas abaixo.
- Valores dos campos no encerramento. Status, motivo, campos de produto ou categoria e quaisquer campos personalizados que a sua org exija. É isso que torna um caso reportável, então faz parte da qualidade de forma legítima.
- Notas e publicações internas. A qualidade da transferência, a investigação, o raciocínio do escalonamento.
- Histórico de propriedade. Quem ficou com o caso e quando ele mudou de mãos.
Muitas vezes ausente, e vale verificar antes de prometer um critério
- Voz. Se há uma chamada anexada e se existe uma transcrição, e não apenas uma gravação ou uma nota, depende de como a voz está provisionada na sua org. Confirme isso antes de escrever um critério que dependa do conteúdo da chamada.
- O que o atendente conseguia ver. A segurança em nível de campo e as regras de compartilhamento fazem com que a visão do avaliador sobre um caso não seja necessariamente a mesma do atendente. Se um critério pressupõe que o atendente tinha uma informação em mãos, verifique se tinha mesmo.
- O estado da base de conhecimento na época. Se um artigo mudou depois do encerramento do caso, o atendente pode ter acertado em relação à versão que tinha.
- Tudo o que aconteceu fora do registro. Um retorno por telefone registrado como uma nota de uma linha, uma conversa numa ferramenta de chat, uma transferência direta para outra equipe. É trabalho real e é invisível para a monitoria.
A regra que decorre disso é curta. Se um critério não pode ser comprovado por algo que está no caso, ele não é um critério de QA, é uma opinião. Ou você encontra o campo ou a mensagem que o comprova, ou tira o critério do formulário e o leva para o coaching. Um formulário de monitoria de atendimento genérico é um bom inventário inicial, mas cada linha dele precisa passar por esse teste diante do layout de caso da sua org.
Como os dados do caso viram critérios do formulário de monitoria
Este é o exercício de mapeamento que faz ou desfaz o programa. Para cada critério, nomeie a evidência, a verificação e o modo de falha que você espera. A última coluna é a que as equipes pulam, e é ela que prevê todas as discussões que você vai ter.
| Tipo de critério | Evidência no caso | Como o avaliador verifica | Onde dá errado |
|---|---|---|---|
| Precisão da resolução | A última mensagem do atendente, lida em relação aos campos com que o caso foi encerrado | A resposta dada corresponde ao resultado registrado, e estava correta naquele momento | O status é definido por uma automação ou uma macro, então o registro diz resolvido sem nenhuma evidência de que foi |
| Cumprimento do processo | Campos obrigatórios, notas internas e quaisquer registros de direitos ou de nível de serviço que a org tenha configurado | Compare o que o caso registra com o processo documentado para aquele tipo de caso | A exigência está numa wiki e não num campo, então dois avaliadores aplicam duas versões diferentes dela |
| Qualidade da comunicação | Apenas as mensagens escritas pelo atendente, nunca o feed inteiro | Avalie o texto que o cliente de fato podia ler | Os avaliadores absorvem o tom de publicações internas e entradas do sistema e o atribuem ao atendente |
| Capacidade de resposta e esforço | Registros de data e hora das mensagens e das mudanças de propriedade | Meça os intervalos entre uma mensagem do cliente e a resposta seguinte do atendente | Tempo de fila, horário comercial e espera por outra equipe são todos cobrados de quem por acaso é o proprietário do caso |
| Categorização e qualidade de dados | Origem, motivo, tipo de registro e os seus próprios campos de relatório | Os valores descrevem o que realmente aconteceu na conversa | Os atendentes escolhem o valor que passa mais rápido pela regra de validação, e ninguém avaliava isso até agora |
| Roteamento | Histórico de propriedade, participação em filas, tipo de registro | O caso chegou primeiro à equipe certa, e se não chegou, por quê | Um roteamento errado causado por uma regra de roteamento é avaliado como falha do atendente |
Como avaliar um caso difere de avaliar um ticket do Zendesk
Muitos líderes de operações de atendimento já fizeram monitoria no Zendesk e agora precisam fazê-la no Service Cloud, ou nos dois ao mesmo tempo. A filosofia do formulário se transfere. A mecânica não, e estas são as seis diferenças que mais custam tempo. Se você também cuida do lado do Zendesk, a mecânica específica dessa plataforma está em monitoria de qualidade para o Zendesk.
| Dimensão | Ticket do Zendesk | Caso do Salesforce Service Cloud |
|---|---|---|
| A unidade de avaliação | Um ticket é uma thread. Solicitante, responsável e comentários se leem como uma conversa linear | Um caso é um registro. A conversa é montada a partir de mensagens, transcrições e itens de feed relacionados |
| Quem fez o trabalho | O responsável e os autores dos comentários visíveis | O campo proprietário diz quem está com o caso agora. A autoria precisa ser lida em cada mensagem individual |
| Canal | Normalmente uma propriedade do próprio ticket | Os canais chegam como registros relacionados diferentes, e um caso pode ter mais de um |
| Definir a população da amostra | Visualizações e filtros de busca | Um relatório ou uma visualização de lista criados com os campos de caso da sua própria org |
| O quanto é padrão | O conjunto de campos é bastante consistente entre contas | Tipos de registro, campos personalizados e valores das listas de opções são configurados por org, então nenhum formulário se transfere sem ajustes |
| Estado de encerramento | Um conjunto curto e conhecido de status | Os valores de status, e o que cada um significa na operação, são definidos pelo seu administrador |
Como tirar uma amostra que você consegue defender
A acusação mais comum contra um programa de monitoria é que o avaliador escolheu os piores casos. No Service Cloud essa acusação é fácil de fazer, porque não existe uma fila de revisão natural e é realmente tentador trabalhar com a visualização de lista que já está aberta.
Defina primeiro a população, num relatório, e salve o relatório. Um filtro que funciona é: data de encerramento dentro do período avaliado, tipo de registro ou fila que identifica o trabalho que você está avaliando, canal se você avalia os canais separadamente e uma exclusão para casos sem nenhuma mensagem escrita por um atendente. Casos duplicados, casos encerrados automaticamente e casos que nunca chegaram a uma pessoa são ruído, e deixá-los na população infla ou reduz em silêncio todas as médias que você publicar depois.
Depois, tire a amostra dessa população e não da lista. Duas regras importam mais do que o tamanho da amostra:
- Sorteie dentro de estratos, não no conjunto inteiro. Estratifique por atendente e por tipo de caso e sorteie dentro de cada estrato. Uma amostragem aleatória pura sobre um mês inteiro dá vinte casos aos atendentes mais ocupados e um ao mais novo, o que torna as notas individuais incomparáveis.
- Feche a amostra antes que alguém leia um caso. Sorteie a lista, salve-a e avalie o que foi sorteado. Uma amostra escolhida depois que o avaliador deu uma olhada na população não é uma amostra.
Seja honesto consigo mesmo sobre o que uma amostra manual entrega. Avaliar trinta casos por atendente por mês é muito trabalho, e ainda assim diz muito pouco sobre os tipos de caso específicos que acontecem raramente e mais prejudicam. Essa limitação é aritmética, não falta de esforço, e é a mesma restrição que o manual de engenharia do NIST apresenta ao perguntar se uma proporção amostrada de defeituosos atende a um requisito: a amostra precisa ser grande o bastante para que o teste seja válido antes de a resposta significar alguma coisa. É por isso que uma nota amostrada e uma nota de qualidade interna reportada à liderança precisam vir com o intervalo de confiança ao lado do número, e por isso vale saber onde a amostragem de monitoria deixa de conseguir responder à pergunta.
Quem escreveu a resposta: atribuição em um caso que mudou de mãos
Este é o problema para o qual nenhum modelo prepara você, e o que mais prejudica a confiança dos atendentes num programa de monitoria no Service Cloud.
Os casos se movem. São roteados, escalonados, reatribuídos, retirados de uma fila, passados a uma equipe especializada e devolvidos. O campo proprietário registra quem está com o caso no momento em que você olha. Ele não registra quem escreveu a resposta que irritou o cliente, nem quem fez a investigação que resolveu o problema. Se o seu processo de monitoria avalia um caso e lança o resultado no proprietário, então em cada caso transferido você atribuiu o trabalho de uma pessoa a outra.
A consequência prática é previsível e específica. Os atendentes que cuidam dos escalonamentos herdam casos que já estão indo mal e ficam com as notas resultantes. Normalmente são as suas pessoas mais capazes. Em um trimestre eles aprendem que pegar um caso difícil sai caro, e o comportamento que você mais queria incentivar vira o comportamento que o seu placar pune.
Quatro regras que resolvem isso
- Avalie a mensagem, não o registro. Cada desconto deve estar ligado a uma mensagem específica escrita pelo atendente, com data, hora e autor, e não ao caso como um todo.
- Atribua pelo autor. Leia a autoria em cada mensagem, e não no campo proprietário. Se os seus relatórios não conseguem fazer isso, é a primeira coisa a corrigir, antes de ajustar um único peso.
- Trate os casos com vários atendentes de forma explícita. Ou avalie separadamente a contribuição de cada atendente, ou exclua o caso da avaliação individual e use-o para revisão de processo. As duas opções são defensáveis. Avaliar em silêncio o último proprietário não é.
- Mantenha o histórico de propriedade ao lado da nota. Quando uma nota é contestada, a primeira pergunta é sempre quem fez o quê. Se a resposta leva vinte minutos para ser reconstruída, a contestação já está perdida.
Os casos transferidos também são a fonte mais rica que você tem para trabalhar processos, e não para o coaching individual. Um caso que mudou de mãos quatro vezes antes de ser resolvido está dizendo algo sobre roteamento, direitos de atendimento ou fronteiras entre equipes, e isso pertence à análise de causa raiz, não ao formulário de alguém.
Avaliar todos os casos em vez de uma amostra
Com o método manual definido, a pergunta óbvia é se dá para parar de amostrar. Dá, e o argumento a favor é mais forte no Service Cloud do que num modelo de ticket mais simples, porque os tipos de caso que mais importam costumam ser justamente os raros, que uma amostra nunca alcança. Há uma diferença real entre uma cobertura de 100% (em inglês), que revela tendências que uma amostragem de 3% nunca mostraria, e uma revisão mensal de trinta casos por atendente.
A cobertura sozinha não é a parte interessante, porém, e também já não é um diferencial. Todo fornecedor desta categoria agora avalia tudo. A pergunta que decide se uma nota automatizada sobrevive ao contato com a sua equipe é se você consegue mostrar que o avaliador automático acertou. No Service Cloud, especificamente, isso significa quatro coisas:
- Rastreabilidade dentro do caso. Um desconto precisa nomear o critério e apontar a mensagem exata dentro do caso que o provocou. “Comunicação: menos dez” num caso com quarenta itens de feed é inutilizável.
- A mesma evidência que o avaliador automático usou. Quem confere uma nota deve ver o conjunto de mensagens a partir do qual a nota foi calculada, e não um resumo dele.
- Um caminho para contestação. Um atendente precisa poder contestar uma nota (em inglês) e ter alguém que examine o raciocínio. Se não puder, a nota é um veredito.
- Concordância medida antes de a nota valer. Rode a nota automatizada em paralelo com os seus próprios avaliadores nos mesmos casos por algumas semanas e valide a avaliação (em inglês) antes de associar o número a qualquer coisa com consequências.
O Auto QA da Kaizo aplica os critérios do seu próprio formulário aos casos e mantém o raciocínio ligado à conversa, para que um desconto contestado possa ser rastreado até a troca que o causou, em vez de ser discutido de memória. Ele funciona no Service Cloud pela integração com o Salesforce, descrita em mais detalhes em Kaizo no Salesforce, ao lado da mesma integração para o Zendesk, o que importa se você faz monitoria nos dois enquanto uma migração está em andamento. Agende uma demo para ver isso nos seus próprios casos.
Uma implantação que sobrevive à primeira contestação
Os programas de monitoria no Service Cloud falham sempre no mesmo ponto: a primeira vez que um atendente contesta seriamente uma nota e o programa não consegue responder. Organize a implantação para que a resposta exista antes da contestação.
| Etapa | O que você faz | Concluída quando |
|---|---|---|
| 1. Defina a unidade | Escolha uma das três definições de conversa e registre-a por escrito. Faça o inventário do que realmente está presente num caso encerrado da sua org | Um avaliador consegue dizer, sem rodeios, quais registros estão no escopo |
| 2. Ligue os critérios aos campos | Para cada critério, nomeie a evidência, a verificação e o modo de falha esperado. Descarte o que você não consegue comprovar | Cada critério aponta para um campo ou um tipo de mensagem que existe |
| 3. Monte o relatório da população | Um relatório salvo que define o conjunto avaliável, com exclusões para casos encerrados automaticamente e casos sem atendente | Duas pessoas que rodam o relatório chegam ao mesmo número de casos |
| 4. Avaliação paralela e calibração | Três avaliadores avaliam os mesmos quinze casos de forma independente, incluindo pelo menos três que mudaram de proprietário. Comparem e discutam | Você conhece a taxa de divergência dos seus avaliadores, e ela está caindo |
| 5. Publique com um caminho de recurso | Anuncie juntos o formulário, o método de amostragem e o processo de recurso. Um recurso sem caminho é uma queixa | Os atendentes conseguem explicar o processo sem precisar consultá-lo |
| 6. Reporte e depois reveja o mapeamento | Reporte as notas ao lado de resultados operacionais como reaberturas e escalonamentos. Reveja o mapeamento a cada trimestre | A variação das notas explica algo que um gestor já suspeitava |
Reportar a nota de um caso para que alguém aja
Uma nota de QA que vive apenas numa ferramenta de QA é lida pela equipe de QA. Para valer o esforço, a nota precisa ficar ao lado dos números operacionais que a liderança de atendimento já acompanha, e precisa ser desdobrada de um jeito que aponte uma ação.
Três recortes fazem a maior parte do trabalho com dados do Service Cloud:
- Por tipo de caso ou tipo de registro, não apenas por atendente. A qualidade varia muito mais conforme o tipo de trabalho do que conforme a pessoa que o faz. Uma média baixa num tipo de registro é um problema de processo, de conhecimento ou de roteamento, e pode ser corrigido de forma centralizada.
- Por critério, na equipe inteira. Um critério que falha de forma ampla quase nunca é um problema de coaching. É uma política pouco clara, um artigo que falta na base de conhecimento ou um critério mal escrito.
- A nota em relação à taxa de reabertura e de escalonamento. Esta é a verificação do próprio formulário. Se os casos com nota alta reabrem na mesma proporção que os de nota baixa, o formulário está medindo outra coisa que não a qualidade e precisa ter os pesos refeitos.
Esse terceiro recorte é o que vale proteger. É ele que impede um programa de monitoria de virar um ritual de compliance que todos cumprem e ninguém usa. Juntar as notas de qualidade ao panorama operacional é exatamente para isso que serve uma visão de análise do atendimento, e é também o caminho mais rápido para mostrar a uma liderança cética que o programa de monitoria está medindo algo real.
Perguntas frequentes
O Salesforce Service Cloud já vem com avaliação de QA?
O Service Cloud oferece a matéria-prima: o registro do caso, as mensagens e transcrições relacionadas a ele, o histórico de campos e uma camada de relatórios sobre tudo isso. Um formulário com pesos, uma fila de revisão, calibração entre avaliadores e um histórico de recursos auditável não fazem parte do objeto de caso padrão. As equipes ou montam uma versão simples com campos personalizados e relatórios, o que funciona até a divergência entre avaliadores virar o gargalo, ou adicionam uma ferramenta de QA que lê os casos. Verifique o que a sua própria org já tem configurado antes de supor qualquer uma das duas coisas, porque a personalização varia muito.
O que avaliar em um caso do Salesforce?
Apenas o que o caso comprova. Na prática, são as mensagens escritas pelo atendente, os registros de data e hora dessas mensagens e das mudanças de propriedade, os valores dos campos com que o caso foi encerrado e as notas internas, se a sua definição de conversa as inclui. Tudo o que você não consegue apontar no registro, como o que o atendente sabia na época ou um retorno por telefone registrado como uma nota de uma linha, pertence ao coaching e não a uma nota.
Qual é a diferença entre fazer QA no Service Cloud e no Zendesk?
A filosofia do formulário é a mesma, a mecânica não. Um ticket do Zendesk (em inglês) é uma thread linear com um responsável claro, então a unidade de avaliação é óbvia. Um caso do Salesforce é um registro com mensagens, transcrições e itens de feed relacionados, então você precisa definir a unidade por conta própria. A autoria também precisa ser lida em cada mensagem, e não tirada do campo proprietário, e como os tipos de registro e os campos personalizados são configurados por org, nenhum formulário se transfere entre duas orgs do Salesforce sem ajustes.
Como tirar uma amostra de casos do Salesforce para a monitoria?
Monte um relatório salvo que defina a população, filtrando por data de encerramento, tipo de registro ou fila, canal quando for relevante, e excluindo casos sem nenhuma mensagem escrita por um atendente. Depois sorteie dentro de estratos, por atendente e por tipo de caso, em vez de sortear sobre o mês inteiro, para que cada atendente contribua com um número comparável de casos. Feche a amostra antes que alguém abra um caso. Avaliar uma lista em que você já deu uma olhada não é amostragem.
Quem fica com a nota de QA quando um caso muda de proprietário?
Não automaticamente o proprietário atual, que é o padrão em que a maioria dos programas cai e o que mais causa danos. Atribua cada mensagem avaliada a quem a escreveu. Num caso tratado por várias pessoas, avalie separadamente a contribuição de cada atendente ou tire o caso da avaliação individual e use-o para revisão de processo. Dar ao último proprietário a nota de um trabalho que ele herdou ensina os seus melhores atendentes a evitar escalonamentos.
Dá para avaliar e-mail, chat e voz no mesmo caso?
Dá, mas decida a abordagem antes da implantação, e não durante a primeira contestação. Uma única nota combinada para um caso que contém uma thread de e-mail e uma transcrição de chat é difícil de usar no coaching, porque os padrões dos dois canais são de fato diferentes. Avaliar cada trecho de canal separadamente e reportar cada um à parte costuma ser mais claro. Se houver voz, confirme primeiro se a sua org tem mesmo transcrições anexadas, e não apenas gravações, já que um critério que depende do conteúdo da chamada não tem como ser aplicado sem elas.
