Um cliente envia um e-mail sobre um pedido com defeito, liga no dia seguinte, depois abre um chat porque ninguém parece saber o que aconteceu, repetindo a mesma história sempre, enquanto sua equipe de suporte vasculha caixas de entrada, anotações e ferramentas separadas. É exatamente isso que o gerenciamento de casos da NEMX 365 resolve. Pense em um caso com uma pasta etiquetada em um escritório movimentado, onde cada parte de um problema do cliente vai para aquela pasta, desde a primeira pergunta até a resposta final. Eu sou Mirko Peters, da NEMX 365 FM, e nesta pílula de conhecimento você verá como casos, roteamento, prazo de resposta, artigos de suporte e encerramento se encaixam. O que um caso é na verdade em 20 palavras? Então o que exatamente é um caso? Um caso é um registro para um problema de cliente que precisa de uma resposta ou solução, e o problema pode ser um produto danificado, uma dúvida de cobrança, um problema de login ou um pedido de ajuda para usar um serviço.

Tal ponto principal, um cliente pode ter vários casos ao mesmo tempo. Um único cliente pode perguntar sobre uma fatura na segunda-feira, relatar uma falha no dispositivo na terça-feira e precisar de ajuda para mudar o endereço da feira. Esses são problemas separados, por isso o NEMX 365 os mantém em registros de casos distintos, em vez de acumular cada conversa em um tópico confuso. Quando um agente cria um caso, ele o vincula diretamente ao cliente. Esse cliente pode ser um contato, ou seja, uma pessoa física ou uma conta, significando a empresa para a qual ele trabalha. Portanto, se Jamie The Northwind Traders relatar um problema, o caso pode apontar tanto para Jamie quanto para a empresa, e qualquer pessoa que abrir o registro pode ver quem precisa de ajuda e a qual organização o problema pertence. O caso também precisa de uma descrição clara do problema, geralmente começando com um título como Nossa impressora parou após a atualização de software, ou Nosso cliente foi cobrado duas vezes pelo plano anual, e esse título ajuda as pessoas a examinarem uma lista de casos abertos sem abrir cada registro.

Abaixo desse título, a gente adiciona os detalhes. O que aconteceu? Quando começou? O que o cliente já tentou fazer? O produto está envolvido? E se é uma pergunta, uma solicitação ou uma falha, esses detalhes transformam uma mensagem vaga em um trabalho que alguém pode assumir e resolver. Vamos detalhar ainda mais? Um caso pode conter assunto, produto, prioridade e tipo de caso. O assunto agrupa a questão em uma área, como faturamento ou suporte técnico. O produto identifica o que o cliente utiliza. A prioridade indica à equipe a urgência da análise. E o tipo de caso oferece outra forma de organizar o trabalho com base no processo de suporte. Nenhum desses campos resolve o problema do cliente por si só, mas eles ajudam a equipe de suporte a visualizar o trabalho com clareza, especialmente quando centenas de casos chegam de clientes diferentes. Uma equipe lidando com uma falha grave de serviço não deveria ter que procurar entre perguntas gerais para encontrá-la.

Bem, um caso não é apenas um formulário que alguém preenche e esquece. Ele se torna o registro de trabalho de toda a conversa. E-mails podem ser vinculados ao caso, chamadas telefônicas podem aparecer nele, e um agente pode adicionar notas após um chat, definir uma tarefa de acompanhamento ou registrar um compromisso. Cada atividade permanece junto ao mesmo problema do cliente, para que a próxima pessoa não precise reconstruir a história do zero. Imagine que um agente começa a trabalhar de manhã e depois transfere o caso para um especialista de produto após o almoço. Sem um registro de caso, o especialista poderia receber apenas uma mensagem curta como Ei, você pode dar uma olhada nisso? Que não é suficiente. Com o registro do caso, ele pode ver o problema original, os detalhes do cliente, o que aconteceu durante a chamada e o que o primeiro agente já verificou. Isso oferece uma transferência muito melhor.

O Dynamics 365 mantém o caso em estado claro à medida que ele avança no processo de suporte. Ele pode permanecer ativo enquanto a equipe investiga, e assim que a equipe corrige o problema ou fornece a resposta final, eles o resolvem. Se a solicitação não precisar mais de trabalho, talvez tenha chegado por engano, ou o cliente tenha desistido, a equipe pode cancelá-la. Ativo, resolvido e cancelado. Esses três estados oferecem à equipe uma visão compartilhada da situação de cada problema. Para que ninguém precise adivinhar se um caso ainda precisa de atenção, e os gerentes não precisem tratar trabalhos antigos finalizados como um problema novo. Um registro oferece controle, e o histórico completo do cliente fornece ao agente o contexto. A história do cliente por trás do caso. O caso diz a você o que precisa se consertar. O registro do cliente diz a você o que levou este momento. Quando um agente abre um caso no Dynamics 365 Customer Service, ele pode olhar, além da última mensagem.

Eles veem o panorama geral, casos anteriores, e meios passados, os produtos conectados ao cliente e seu histórico de suporte. O contexto muda a conversa. Qual é o contexto importante? Imagine que um cliente relata uma falha no dispositivo. Se o agente vira apenas a mensagem de hoje, ele pode começar com perguntas básicas. Qual o modelo? Onde isso começou? Você o reiniciou? Mas o cliente entrou em contato com o suporte duas vezes esta semana. O primeiro agente enviou passos e solução de problemas. O segundo providenciou uma peça de reposição. Um terceiro agente que vê esse histórico não pedirá ao cliente para recomeçar. Em vez disso, ele diz, veja que você já tentou esses passos e a peça de reposição não resolveu. Vamos tentar a próxima etapa. Isso é muito diferente de você pode explicar o problema novamente. Isso é frequentemente chamado de visão 360 graus. O nome parece sofisticado, mas é simples.

Significa que o agente vê o cliente de mais de um ângulo, não apenas uma mensagem isolada. O agente vê a pessoa, a empresa, solicitações de suporte anteriores, conversas passadas e os produtos conectados a elas. Para uma equipe de suporte, se substitui suposições por um ponto de partida. Bem, nem todo cliente recebe o mesmo tipo de suporte. Um cliente pode ter comprado uma garantia. Sua empresa pode pagar por um número fixo de horas de suporte. Ou eles podem ter um contrato que permite um certo número de casos ou suporte premium com ajuda mais rápida. O Dynamics 365 rastreia tudo isso através de direitos. Um direito, o acordo de suporte ao cliente dentro do sistema Pense nisso com os termos de serviço anexados à conta dele. Antes de um agente prometer um engenheiro ou iniciar um trabalho cobrável, ele verifica qual suporte se aplica. Isso evita surpresas agradáveis. Por exemplo, um cliente pode ainda ter cobertura de garantia para um produto com defeito.

O caso pode seguir esse caminho. Outro cliente pode ter usado todas as suas horas de suporte. A gente vê isso antes de se comprometer com o trabalho fora do contrato. Isso também ajuda a equipe de suporte a tratar os clientes de forma justa. A gente não precisa procurar em contratos antigos ou perguntar a outro departamento. Os termos de suporte ficam junto com as informações do cliente onde o agente pode encontrá-los depois da base de conhecimento. Equipes de suporte resolvem os mesmos problemas repetidamente. Redefinições de senha, instruções de configuração, um erro conhecido após uma atualização, uma pergunta de faturamento com resposta padrão. Um artigo de conhecimento armazena essa resposta em um solo. Dentro da área de trabalho de serviço, um agente pode pesquisar artigos enquanto trabalha em um caso. Um artigo pode incluir uma explicação simples, passos, uma captura de tela ou as verificações exatas que a equipe deve completar.

Em vez de cada agente escrever sua própria versão de memória, eles usam uma resposta compartilhada que a equipe revisou. Isso mantém o suporte consistente. Também ajuda os agentes mais novos. Eles não precisam de anos de experiência para lidar bem com problemas comuns, pois as soluções conhecidas da equipe estão disponíveis quando eles precisam. Os resumos de casos do Copilot ajudam com outro problema comum, históricos de casos novos. Um caso pode acumular muitos e-mails, notas e atualizações ao longo do tempo. Ler tudo isso leva tempo, especialmente após uma transferência. O Copilot cria um breve resumo do caso que reúne o título, cliente, assunto, produto, prioridade, tipo de caso, descrição e atividades recentes. É uma síntese rápida antes de o agente começar o trabalho. O agente ainda verifica o registro e usa seu julgamento, mas entende a situação mais rapidamente. Isso ajuda quando o cliente está esperando e o caso passou por várias mãos.

Assim que o agente entende o cliente e o problema, o caso precisa chegar à pessoa certa.

Dá entrada para a fila correta. Um cliente pode pedir ajuda de várias formas, e-mail, telefone, chat, redes sociais ou portal de autoatendimento. O canal muda, mas a equipe de suporte ainda precisa de um lugar claro para gerenciar a solicitação. O Dynamics 365 pode criar casos a partir dessas conversas quando a configuração inclui regras de criação de registros. Pense um e-mail chegando ao endereço de suporte compartilhado. Em vez de deixá-lo em uma caixa de entrada até que alguém o veja, uma regra transforma esse e-mail em um caso. A mensagem se torna o início do trabalho dentro do atendimento ao cliente. Isso reduz a necessidade de copiar manualmente. A mesma ideia se aplica a outros canais conectados. A equipe escolhe quais mensagens criam um novo caso e quais pertencem a um caso existente. Uma resposta a um problema aberto permanece com esse problema. Uma nova pergunta gera seu próprio caso.

Então o caso precisa de um local, enquanto alguém é sua responsabilidade. Esse local geralmente é uma fila. Uma fila é uma caixa de entrada de trabalho compartilhada por mim. Não é a caixa de entrada de um agente, nem pertence à pessoa que viu a solicitação. Em vez disso, oferece à equipe inteira um lugar para ver o trabalho e a cotenção. Imagina uma empresa com uma equipe de faturamento, uma equipe de suporte técnico, uma equipe de devoluções. Cada equipe tem sua própria fila. Perguntas de faturamento vão para o faturamento, falhas de produto vão para o suporte técnico, pedidos de devolução vão para quem entende o processo de devolução. Isso parece simples porque é. Uma classificação clara evita que as pessoas passem o trabalho diante das cegas. As regras de roteamento ajudam nessa classificação. Uma regra de roteamento verifica os detalhes de um caso e envia para a fila ou pessoa certa.

Um caso sobre um produto específico vai para a equipe do produto. Um caso de uma determinada região vai para o suporte local. Problema sério vai para uma fila de urgência. Uma pergunta geral aguarda com a equipe padrão. Umas organizações direcionam um trabalho com base em habilidade. Por exemplo, um cliente que escreve em francês precisa de um agente que fale francês. Um problema técnico requer alguém treinado em um produto específico. O direcionamento coloca o caso mais perto de quem pode resolvê-lo, em vez de tratar todas as solicitações da mesma forma. A automação ajuda, mas as pessoas ainda tomam decisões. Um líder de equipe pode analisar um caso difícil e atribuí-lo diretamente a um agente sênior. Talvez alguém já conheça o cliente. Talvez o problema envolva vários produtos e exija uma experiência que uma regra não consegue avaliar. A atribuição manual dá à equipe espaço para essa escolha humana.

A responsabilidade pode mudar durante um ano. Um agente pode precisar de mais informações e devolver o caso para uma fila. Uma equipe pode descobrir que o problema pertence a outro departamento. Ou uma solicitação urgente pode precisar de escalonamento quando a equipe normal não consegue resolver. O Dynamics 365 mantém o trabalho em movimento em vez de deixá-lo parado com alguém. Às vezes um único problema cria muitos casos. Imagine uma falha de software afetando dezenas de clientes. Cada cliente entra em contato com o suporte separadamente, então cada relato precisa do seu próprio caso. Mas todos os relatos se conectam a um problema maior. Um caso o pai rastreia essa questão mais ampla, enquanto o caso os filhos rastreiam os relatos individuais dos clientes abaixo dele. Isso dá a equipe de suporte duas vezes ao mesmo tempo. Eles trabalham na falha subjacente por meio do caso pai, enquanto cada caso filho mantém o cliente correspondente informado.

Quando encontram a correção, não precisam investigar a mesma falha do zero para cada solicitante. Casos duplicados criam um problema semelhante em menor escala. Um cliente pode enviar um e-mail e ligar sobre o mesmo problema, ou dois agentes podem abrir casos antes de perceberem o outro. Em vez de dividir o esforço, a equipe pode mesclar casos semelhantes. Um caso torna-se o registro principal e o trabalho permanece unificado. Ninguém deveria resolver o mesmo problema duas vezes. Levar um caso para a fila e as pessoas certas dá início ao trabalho, e o cliente espera uma resposta dentro do prazo prometido. Cumprindo promessas com SLA e trabalho guiado. Levar um caso para a pessoa certa é apenas metade do trabalho, pois o cliente também espera ajuda dentro do tempo prometido. E é aí que entra o acordo de nível de serviço, que chamaria de SLA. Um SLA anexa um cronômetro ao caso, para que a equipe saiba exatamente quanto tempo tem para cumprir a promessa feita ao cliente, seja para responder pela primeira vez ou para resolver o problema totalmente.

Mas é que a automação é fundamental. Esses nem sempre são os mesmos prazos. Veja um cliente que espera um reconhecimento em uma hora, mesmo que a equipe técnica precise de dois dias úteis para encontrar e testar a correção. O Dynamics 300 C5 rastreia a meta da primeira resposta e a meta de resolução separadamente, para que a equipe possa agir rapidamente sem fingir que todo problema pode ser resolvido instantaneamente. Agora imagine um cliente cujo serviço funcionar. Ele não espera um reparo completo em 10 minutos, mas espera que alguém confirme que o problema é conhecido, explique o que acontecerá em seguida e o mantenha informado. A meta da primeira resposta é rastrear esse contato inicial, enquanto a meta de resolução rastrea todo o caminho até uma resposta ou correção. E clientes diferentes podem ter promessas diferentes. Uma empresa com suporte premium obtém metas de resposta mais rápidas do que um cliente em um plano padrão.

Uma interrupção de alta prioridade tem um prazo menor do que uma dúvida rotineira de como fazer. Acordos de suporte, prioridade e tipo de caso definem as regras de tempo que se aprendem. Isso mantém as promessas justas e claras. Sem SLA, um agente pode trabalhar a partir do item mais antigo em uma lista enquanto um caso urgente perde silenciosamente seu prazo. Com SLA, essa tela de casos mostra indicadores de tempo que informam o agente qual promessa precisa de atenção primeiro. Assim você verá a pressão aumentar. Um caso com bastante tempo disponível precisa de trabalho, mas um caso próximo ao prazo de resposta precisa de atenção agora. As equipes também podem definir alertas ou etapas de escalonamento quando uma meta está próxima ou já expirou, para que um supervisor possa intervir antes que o cliente precise cobrar a equipe. As metas de tempo orientam a urgência e os fluxos de processo de negócios orientam o trabalho em si.

Um fluxo de processo de negócios são conjuntos de estágios exibidos dentro do caso. Ele oferece ao agente um caminho claro a seguir com base em como a organização deseja que os casos sejam tratados. Os estágios podem ir da triagem, a investigação e a resolução com as perguntas e verificações certas em cada ponto. Pense nisso com uma lista de verificação com lugar definido no processo. Um novo agente não precisa adivinhar quais detalhes importam antes de enviar um caso a um especialista. O fluxo pode solicitar o produto, tipo de problema, impacto e outras informações que a próxima equipe precisa. Um agente mais experiente pode se mover mais rápido, mas o caminho compartilhado ainda mantém a equipe trabalhando na mesma direção. Aqui está um celular. Chega uma interrupção de serviço de alta prioridade. O caso entra na fila urgente e seu SLA começa a contagem regressiva. O agente confirma os detalhes do cliente, registra o impacto e envia a primeira resposta antes que essa meta de resposta expire.

Em seguida, o fluxo do processo move o caso para o diagnóstico, onde a equipe coleta detalhes do erro e verifica relatórios relacionados. O caso então passa para a resolução, quando a equipe identifica a causa e prepara uma atualização para o cliente. Essa sequência também oferece aos gerentes uma visão mais clara. Eles conseguem ver onde o chamado trava durante a triagem, o diagnóstico ou a resposta final ao cliente. O fluxo não resolve o problema da equipe, mas evita que etapas básicas sejam esquecidas em um dia corrido. O Dynamics 365 também pode controlar quais alterações de status os agentes podem escolher em diferentes momentos. Isso é chamado de transição de motivo de status, que parece técnico, mas a ideia é simples. Um chamado deve seguir etapas sensatas. Você não quer que alguém marque um chamado como resolvido, enquanto ele aguarda uma verificação interna, ou que pule de novo para cancelado sem registrar o motivo.

As opções permitidas podem mudar conforme o chamado muda. Por exemplo, um caso de investigação pode permitir que um agente o coloque em espera enquanto aguarda detalhes do cliente. Após a resposta do cliente, o agente pode retomar o trabalho ativo. Quando o problema é corrigido, o chamado pode ser movido para resolver. Isso é o que é chamado mais limpo. Apenas uma resposta não finaliza o trabalho. A equipe precisa registrar como o problema terminou, então fechar o chamado corretamente. Resolução aprendizada e melhor atendimento. Enviar uma resposta não fecha um chamado automaticamente. A equipe precisa registrar a resolução, o que significa anotar o que corrigiu o problema ou qual resposta final o cliente recebeu. Pode ser o envio de um dispositivo de substituição, reembolso de um pagamento duplicado ou atualização de uma configuração que impediu acesso. Essa nota torna-se parte do registro do cliente e oferece ao próximo agente um ponto de partida útil Se o mesmo cliente contatar o suporte meses depois com um problema relacionado, às vezes a primeira correção funciona.

Talvez o cliente siga as instruções e o erro retorne. Talvez uma peça de substituição chegue, mas não resolva a falha. Nessa situação, a equipe pode reabrir o chamado ou colocá-lo de volta na fila para mais trabalho, em vez de iniciar um novo registro sem histórico. O chamado continua de onde a equipe parou. Isso é importante quando a responsabilidade morre. Um novo agente pode ver o que o anterior tentou, o que o cliente confirmou e o que ainda precisa ser verificado. O cliente não precisa explicar toda a história desde o início só porque outra pessoa assumiu o trabalho. Com o tempo, todos esses chamados também mostram à equipe de suporte o que está acontecendo além de um problema específico. Os gerentes podem analisar o tempo de resolução, que rastreia quanto tempo os chamados levam da abertura até o fechamento. Eles podem ver o tempo por etapa, que mostra onde os chamados gastam mais tempo.

Eles também podem observar a resolução no primeiro contato, ou seja, com que frequência a primeira pessoa que fala com o cliente consegue resolver o problema sem transferências. Para cair o trabalho também importa. Se uma fila lota toda segunda-feira de manhã, a equipe consegue ver isso. Se chamados técnicos passam dias aguardando uma verificação interna, esse atraso aparece nos dados do caso. Se uma equipe fecha os chamados rapidamente, mas os clientes continuam reabrindo-os, a equipe tem motivos para analisar melhor a qualidade dessas primeiras correções. Os números não explicam tudo por si sós. Eles indicam à equipe quais perguntas valem a pena ser feitas. Por que o chamado sobre um produto está aumentando? Por que um certo tipo de caso demora mais do que o esperado? Por que os agentes pesquisam repetidamente a mesma resposta sem encontrar um artigo de conhecimento útil? Padrões transformam o trabalho de suporte em aprendizado prático.

Um aumento em casos semelhantes pode apontar uma falha no produto. Pode mostrar que uma atualização recente confunde os clientes. Pode revelar que um guia de instruções precisa de passo mais claro. Em vez de tratar cada solicitação como algo isolado, a equipe pode identificar a causa comum e trabalhar nela. Isso pode reduzir o volume de futuros chamados. O feedback do cliente também faz parte desse cenário. Um chamado fechado pode mostrar que a equipe atingiu a meta de resposta, mas o cliente pode se sentir frustrado se teve que contatar o suporte três vezes. Analisar tanto o histórico do caso quanto o feedback dá aos gestores uma visão mais completa da experiência. Alguns clientes preferem evitar a criação de um chamado. É aí que um portal de autoatendimento pode ajudar. Por meio de um portal, os clientes podem criar uma solicitação, verificar seu status, adicionar novas informações ou ler artigos de suporte aprovados sem ligar para a equipe.

Para perguntas simples, isso economiza tempo para todos. Um cliente pode verificar o status de entrega, ou seguir um dia de configuração quando for conveniente para ele. Enquanto isso, os agentes podem dedicar mais tempo a problemas que precisam de uma pessoa para investigar, explicar ou tomar uma decisão. O Dynamics 365 Customer Service também pode se conectar com ferramentas conhecidas da Microsoft em torno do processo de chamada. Um agente pode trabalhar com o e-mail pelo Outlook. Uma equipe pode discutir um problema difícil no Teams. Documentos e informações compartilhadas podem ficar no SharePoint. O Power BI pode transformar dados de chamados em relatórios e dashboards, enquanto as ferramentas da Power Platform podem dar suporte a formulários extras, alertas ou etapas automatizadas. Cada ferramenta tem sua profissão. O caso continua sendo o local, onde o problema de suporte e seu histórico permanecem conectados, mesmo quando as pessoas usam outras ferramentas para comunicar e compartilhar arquivos ao seu trabalho.

A gestão de casos não se trata apenas de preencher uma tela de chamada. Trata-se de dar a cada problema do cliente um caminho claro, uma resposta registrada e uma equipe que possa aprender com o que aconteceu.

Mantenha toda a história do cliente unida. Portanto, aqui está o verdadeiro aprendizado. O gerenciamento de casos do Dynamics 365 mantém o problema, trabalhos, promessas e o resultado em um único registro. Chega de contexto perdido ou correções repetidas. Analise seu próprio acesso de suporte. Dá para onde as informações do cliente desaparecem. É aí que reunir tudo isso muda tudo. Inscreva-se na sua plataforma de podcast favorita para mais pílulas de conhecimento da Microsoft comigo, Mirko Peters, no M365.fm, onde explicamos as ferramentas da Microsoft para o trabalho diário em linguagem 5.