WEBVTT 00:00:00.000 --> 00:00:10.940 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. 00:00:11.340 --> 00:00:14.440 É exatamente isso que o gerenciamento de casos da NEMX 365 resolve. 00:00:15.140 --> 00:00:21.920 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. 00:00:21.920 --> 00:00:31.160 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. 00:00:32.020 --> 00:00:33.600 O que um caso é na verdade em 20 palavras? 00:00:34.380 --> 00:00:35.620 Então o que exatamente é um caso? 00:00:36.180 --> 00:00:44.940 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. 00:00:45.380 --> 00:00:48.500 Tal ponto principal, um cliente pode ter vários casos ao mesmo tempo. 00:00:48.500 --> 00:00:54.800 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. 00:00:55.000 --> 00:01:01.220 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. 00:01:02.080 --> 00:01:04.740 Quando um agente cria um caso, ele o vincula diretamente ao cliente. 00:01:05.320 --> 00:01:10.120 Esse cliente pode ser um contato, ou seja, uma pessoa física ou uma conta, significando a empresa para a qual ele trabalha. 00:01:10.680 --> 00:01:15.160 Portanto, se Jamie The Northwind Traders relatar um problema, o caso pode apontar tanto para Jamie quanto para a empresa, 00:01:15.160 --> 00:01:19.500 e qualquer pessoa que abrir o registro pode ver quem precisa de ajuda e a qual organização o problema pertence. 00:01:20.760 --> 00:01:24.860 O caso também precisa de uma descrição clara do problema, geralmente começando com um título como 00:01:24.860 --> 00:01:30.140 Nossa impressora parou após a atualização de software, ou Nosso cliente foi cobrado duas vezes pelo plano anual, 00:01:30.500 --> 00:01:34.760 e esse título ajuda as pessoas a examinarem uma lista de casos abertos sem abrir cada registro. 00:01:35.780 --> 00:01:37.400 Abaixo desse título, a gente adiciona os detalhes. 00:01:37.740 --> 00:01:38.140 O que aconteceu? 00:01:38.480 --> 00:01:39.040 Quando começou? 00:01:39.400 --> 00:01:40.400 O que o cliente já tentou fazer? 00:01:40.980 --> 00:01:41.860 O produto está envolvido? 00:01:41.860 --> 00:01:48.060 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. 00:01:48.800 --> 00:01:49.820 Vamos detalhar ainda mais? 00:01:50.580 --> 00:01:53.360 Um caso pode conter assunto, produto, prioridade e tipo de caso. 00:01:53.880 --> 00:01:57.200 O assunto agrupa a questão em uma área, como faturamento ou suporte técnico. 00:01:57.480 --> 00:01:59.300 O produto identifica o que o cliente utiliza. 00:02:00.000 --> 00:02:02.040 A prioridade indica à equipe a urgência da análise. 00:02:02.640 --> 00:02:06.160 E o tipo de caso oferece outra forma de organizar o trabalho com base no processo de suporte. 00:02:06.160 --> 00:02:12.520 Nenhum desses campos resolve o problema do cliente por si só, mas eles ajudam a equipe de suporte a visualizar o trabalho com clareza, 00:02:12.620 --> 00:02:15.380 especialmente quando centenas de casos chegam de clientes diferentes. 00:02:16.320 --> 00:02:20.940 Uma equipe lidando com uma falha grave de serviço não deveria ter que procurar entre perguntas gerais para encontrá-la. 00:02:21.500 --> 00:02:24.260 Bem, um caso não é apenas um formulário que alguém preenche e esquece. 00:02:25.100 --> 00:02:27.140 Ele se torna o registro de trabalho de toda a conversa. 00:02:27.680 --> 00:02:31.120 E-mails podem ser vinculados ao caso, chamadas telefônicas podem aparecer nele, 00:02:31.120 --> 00:02:35.200 e um agente pode adicionar notas após um chat, definir uma tarefa de acompanhamento ou registrar um compromisso. 00:02:36.040 --> 00:02:38.660 Cada atividade permanece junto ao mesmo problema do cliente, 00:02:38.740 --> 00:02:41.540 para que a próxima pessoa não precise reconstruir a história do zero. 00:02:42.340 --> 00:02:46.800 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. 00:02:47.460 --> 00:02:50.680 Sem um registro de caso, o especialista poderia receber apenas uma mensagem curta como 00:02:50.680 --> 00:02:51.720 Ei, você pode dar uma olhada nisso? 00:02:52.480 --> 00:02:53.400 Que não é suficiente. 00:02:54.400 --> 00:02:57.560 Com o registro do caso, ele pode ver o problema original, os detalhes do cliente, 00:02:57.600 --> 00:02:59.880 o que aconteceu durante a chamada e o que o primeiro agente já verificou. 00:02:59.880 --> 00:03:01.880 Isso oferece uma transferência muito melhor. 00:03:02.660 --> 00:03:06.760 O Dynamics 365 mantém o caso em estado claro à medida que ele avança no processo de suporte. 00:03:07.460 --> 00:03:09.660 Ele pode permanecer ativo enquanto a equipe investiga, 00:03:09.700 --> 00:03:12.880 e assim que a equipe corrige o problema ou fornece a resposta final, eles o resolvem. 00:03:13.580 --> 00:03:15.140 Se a solicitação não precisar mais de trabalho, 00:03:15.560 --> 00:03:19.140 talvez tenha chegado por engano, ou o cliente tenha desistido, a equipe pode cancelá-la. 00:03:19.820 --> 00:03:21.240 Ativo, resolvido e cancelado. 00:03:22.260 --> 00:03:26.440 Esses três estados oferecem à equipe uma visão compartilhada da situação de cada problema. 00:03:26.440 --> 00:03:30.340 Para que ninguém precise adivinhar se um caso ainda precisa de atenção, 00:03:30.860 --> 00:03:34.860 e os gerentes não precisem tratar trabalhos antigos finalizados como um problema novo. 00:03:35.860 --> 00:03:39.820 Um registro oferece controle, e o histórico completo do cliente fornece ao agente o contexto. 00:03:40.820 --> 00:03:42.600 A história do cliente por trás do caso. 00:03:43.360 --> 00:03:44.920 O caso diz a você o que precisa se consertar. 00:03:45.300 --> 00:03:47.000 O registro do cliente diz a você o que levou este momento. 00:03:47.000 --> 00:03:51.240 Quando um agente abre um caso no Dynamics 365 Customer Service, 00:03:51.320 --> 00:03:52.880 ele pode olhar, além da última mensagem. 00:03:53.560 --> 00:03:56.500 Eles veem o panorama geral, casos anteriores, e meios passados, 00:03:56.580 --> 00:03:58.800 os produtos conectados ao cliente e seu histórico de suporte. 00:03:59.540 --> 00:04:00.820 O contexto muda a conversa. 00:04:01.660 --> 00:04:02.460 Qual é o contexto importante? 00:04:03.020 --> 00:04:04.960 Imagine que um cliente relata uma falha no dispositivo. 00:04:05.440 --> 00:04:08.880 Se o agente vira apenas a mensagem de hoje, ele pode começar com perguntas básicas. 00:04:09.680 --> 00:04:10.120 Qual o modelo? 00:04:10.460 --> 00:04:11.040 Onde isso começou? 00:04:11.340 --> 00:04:12.000 Você o reiniciou? 00:04:12.000 --> 00:04:15.240 Mas o cliente entrou em contato com o suporte duas vezes esta semana. 00:04:15.620 --> 00:04:17.300 O primeiro agente enviou passos e solução de problemas. 00:04:17.420 --> 00:04:18.780 O segundo providenciou uma peça de reposição. 00:04:19.340 --> 00:04:22.380 Um terceiro agente que vê esse histórico não pedirá ao cliente para recomeçar. 00:04:22.960 --> 00:04:23.860 Em vez disso, ele diz, 00:04:24.180 --> 00:04:26.880 veja que você já tentou esses passos e a peça de reposição não resolveu. 00:04:27.260 --> 00:04:28.100 Vamos tentar a próxima etapa. 00:04:28.880 --> 00:04:31.060 Isso é muito diferente de você pode explicar o problema novamente. 00:04:32.260 --> 00:04:34.360 Isso é frequentemente chamado de visão 360 graus. 00:04:34.980 --> 00:04:36.600 O nome parece sofisticado, mas é simples. 00:04:37.020 --> 00:04:40.680 Significa que o agente vê o cliente de mais de um ângulo, não apenas uma mensagem isolada. 00:04:40.680 --> 00:04:45.460 O agente vê a pessoa, a empresa, solicitações de suporte anteriores, conversas passadas 00:04:45.460 --> 00:04:47.040 e os produtos conectados a elas. 00:04:47.700 --> 00:04:50.260 Para uma equipe de suporte, se substitui suposições por um ponto de partida. 00:04:50.840 --> 00:04:53.040 Bem, nem todo cliente recebe o mesmo tipo de suporte. 00:04:53.640 --> 00:04:55.240 Um cliente pode ter comprado uma garantia. 00:04:55.580 --> 00:04:58.000 Sua empresa pode pagar por um número fixo de horas de suporte. 00:04:58.420 --> 00:05:00.920 Ou eles podem ter um contrato que permite um certo número de casos 00:05:00.920 --> 00:05:02.820 ou suporte premium com ajuda mais rápida. 00:05:03.580 --> 00:05:06.140 O Dynamics 365 rastreia tudo isso através de direitos. 00:05:07.060 --> 00:05:09.840 Um direito, o acordo de suporte ao cliente dentro do sistema 00:05:09.840 --> 00:05:12.940 Pense nisso com os termos de serviço anexados à conta dele. 00:05:13.520 --> 00:05:16.240 Antes de um agente prometer um engenheiro ou iniciar um trabalho cobrável, 00:05:16.440 --> 00:05:18.340 ele verifica qual suporte se aplica. 00:05:19.120 --> 00:05:20.400 Isso evita surpresas agradáveis. 00:05:20.680 --> 00:05:23.820 Por exemplo, um cliente pode ainda ter cobertura de garantia para um produto com defeito. 00:05:24.220 --> 00:05:25.240 O caso pode seguir esse caminho. 00:05:25.820 --> 00:05:27.940 Outro cliente pode ter usado todas as suas horas de suporte. 00:05:28.460 --> 00:05:30.900 A gente vê isso antes de se comprometer com o trabalho fora do contrato. 00:05:31.300 --> 00:05:33.640 Isso também ajuda a equipe de suporte a tratar os clientes de forma justa. 00:05:33.640 --> 00:05:36.840 A gente não precisa procurar em contratos antigos ou perguntar a outro departamento. 00:05:36.840 --> 00:05:40.560 Os termos de suporte ficam junto com as informações do cliente onde o agente pode encontrá-los 00:05:40.560 --> 00:05:41.820 depois da base de conhecimento. 00:05:42.240 --> 00:05:44.220 Equipes de suporte resolvem os mesmos problemas repetidamente. 00:05:44.800 --> 00:05:46.700 Redefinições de senha, instruções de configuração, 00:05:46.780 --> 00:05:48.140 um erro conhecido após uma atualização, 00:05:48.280 --> 00:05:49.860 uma pergunta de faturamento com resposta padrão. 00:05:50.160 --> 00:05:52.000 Um artigo de conhecimento armazena essa resposta em um solo. 00:05:52.520 --> 00:05:53.880 Dentro da área de trabalho de serviço, 00:05:53.940 --> 00:05:56.040 um agente pode pesquisar artigos enquanto trabalha em um caso. 00:05:56.400 --> 00:05:58.200 Um artigo pode incluir uma explicação simples, 00:05:58.400 --> 00:05:59.640 passos, uma captura de tela 00:05:59.640 --> 00:06:01.780 ou as verificações exatas que a equipe deve completar. 00:06:02.120 --> 00:06:04.300 Em vez de cada agente escrever sua própria versão de memória, 00:06:04.300 --> 00:06:06.960 eles usam uma resposta compartilhada que a equipe revisou. 00:06:07.400 --> 00:06:08.540 Isso mantém o suporte consistente. 00:06:08.940 --> 00:06:10.160 Também ajuda os agentes mais novos. 00:06:10.520 --> 00:06:13.460 Eles não precisam de anos de experiência para lidar bem com problemas comuns, 00:06:13.540 --> 00:06:16.220 pois as soluções conhecidas da equipe estão disponíveis quando eles precisam. 00:06:16.600 --> 00:06:18.920 Os resumos de casos do Copilot ajudam com outro problema comum, 00:06:19.040 --> 00:06:19.840 históricos de casos novos. 00:06:20.260 --> 00:06:23.280 Um caso pode acumular muitos e-mails, notas e atualizações ao longo do tempo. 00:06:23.560 --> 00:06:25.680 Ler tudo isso leva tempo, especialmente após uma transferência. 00:06:25.980 --> 00:06:28.560 O Copilot cria um breve resumo do caso que reúne o título, 00:06:28.700 --> 00:06:33.340 cliente, assunto, produto, prioridade, tipo de caso, descrição e atividades recentes. 00:06:33.340 --> 00:06:35.440 É uma síntese rápida antes de o agente começar o trabalho. 00:06:35.940 --> 00:06:38.140 O agente ainda verifica o registro e usa seu julgamento, 00:06:38.460 --> 00:06:39.960 mas entende a situação mais rapidamente. 00:06:40.720 --> 00:06:43.860 Isso ajuda quando o cliente está esperando e o caso passou por várias mãos. 00:06:44.860 --> 00:06:46.860 Assim que o agente entende o cliente e o problema, 00:06:46.980 --> 00:06:48.600 o caso precisa chegar à pessoa certa. 00:06:50.960 --> 00:06:52.040 Dá entrada para a fila correta. 00:06:52.760 --> 00:06:54.540 Um cliente pode pedir ajuda de várias formas, 00:06:54.720 --> 00:06:57.440 e-mail, telefone, chat, redes sociais ou portal de autoatendimento. 00:06:57.920 --> 00:07:01.520 O canal muda, mas a equipe de suporte ainda precisa de um lugar claro para gerenciar a solicitação. 00:07:01.520 --> 00:07:05.540 O Dynamics 365 pode criar casos a partir dessas conversas 00:07:05.540 --> 00:07:07.560 quando a configuração inclui regras de criação de registros. 00:07:08.300 --> 00:07:10.800 Pense um e-mail chegando ao endereço de suporte compartilhado. 00:07:11.360 --> 00:07:13.660 Em vez de deixá-lo em uma caixa de entrada até que alguém o veja, 00:07:13.820 --> 00:07:15.280 uma regra transforma esse e-mail em um caso. 00:07:15.880 --> 00:07:18.360 A mensagem se torna o início do trabalho dentro do atendimento ao cliente. 00:07:18.700 --> 00:07:20.100 Isso reduz a necessidade de copiar manualmente. 00:07:20.560 --> 00:07:22.560 A mesma ideia se aplica a outros canais conectados. 00:07:22.560 --> 00:07:25.420 A equipe escolhe quais mensagens criam um novo caso 00:07:25.420 --> 00:07:26.860 e quais pertencem a um caso existente. 00:07:27.700 --> 00:07:29.660 Uma resposta a um problema aberto permanece com esse problema. 00:07:29.660 --> 00:07:31.240 Uma nova pergunta gera seu próprio caso. 00:07:31.520 --> 00:07:33.580 Então o caso precisa de um local, enquanto alguém é sua responsabilidade. 00:07:33.860 --> 00:07:34.920 Esse local geralmente é uma fila. 00:07:35.240 --> 00:07:37.220 Uma fila é uma caixa de entrada de trabalho compartilhada por mim. 00:07:37.520 --> 00:07:41.040 Não é a caixa de entrada de um agente, nem pertence à pessoa que viu a solicitação. 00:07:41.560 --> 00:07:44.280 Em vez disso, oferece à equipe inteira um lugar para ver o trabalho e a cotenção. 00:07:44.840 --> 00:07:46.420 Imagina uma empresa com uma equipe de faturamento, 00:07:46.540 --> 00:07:48.440 uma equipe de suporte técnico, uma equipe de devoluções. 00:07:49.060 --> 00:07:50.380 Cada equipe tem sua própria fila. 00:07:50.520 --> 00:07:52.040 Perguntas de faturamento vão para o faturamento, 00:07:52.180 --> 00:07:53.740 falhas de produto vão para o suporte técnico, 00:07:54.180 --> 00:07:56.400 pedidos de devolução vão para quem entende o processo de devolução. 00:07:56.900 --> 00:07:57.820 Isso parece simples porque é. 00:07:57.820 --> 00:08:01.360 Uma classificação clara evita que as pessoas passem o trabalho diante das cegas. 00:08:01.760 --> 00:08:03.240 As regras de roteamento ajudam nessa classificação. 00:08:03.540 --> 00:08:05.920 Uma regra de roteamento verifica os detalhes de um caso 00:08:05.920 --> 00:08:07.240 e envia para a fila ou pessoa certa. 00:08:07.980 --> 00:08:10.260 Um caso sobre um produto específico vai para a equipe do produto. 00:08:10.840 --> 00:08:12.880 Um caso de uma determinada região vai para o suporte local. 00:08:13.360 --> 00:08:14.820 Problema sério vai para uma fila de urgência. 00:08:15.380 --> 00:08:16.860 Uma pergunta geral aguarda com a equipe padrão. 00:08:17.620 --> 00:08:19.560 Umas organizações direcionam um trabalho com base em habilidade. 00:08:20.040 --> 00:08:21.620 Por exemplo, um cliente que escreve em francês 00:08:21.620 --> 00:08:22.920 precisa de um agente que fale francês. 00:08:23.320 --> 00:08:25.600 Um problema técnico requer alguém treinado em um produto específico. 00:08:25.600 --> 00:08:28.600 O direcionamento coloca o caso mais perto de quem pode resolvê-lo, 00:08:28.660 --> 00:08:30.360 em vez de tratar todas as solicitações da mesma forma. 00:08:30.700 --> 00:08:32.520 A automação ajuda, mas as pessoas ainda tomam decisões. 00:08:33.100 --> 00:08:36.300 Um líder de equipe pode analisar um caso difícil e atribuí-lo diretamente a um agente sênior. 00:08:36.780 --> 00:08:38.140 Talvez alguém já conheça o cliente. 00:08:38.820 --> 00:08:42.100 Talvez o problema envolva vários produtos e exija uma experiência que uma regra não consegue avaliar. 00:08:42.680 --> 00:08:45.140 A atribuição manual dá à equipe espaço para essa escolha humana. 00:08:45.600 --> 00:08:46.940 A responsabilidade pode mudar durante um ano. 00:08:47.340 --> 00:08:49.940 Um agente pode precisar de mais informações e devolver o caso para uma fila. 00:08:49.940 --> 00:08:53.240 Uma equipe pode descobrir que o problema pertence a outro departamento. 00:08:53.320 --> 00:08:56.620 Ou uma solicitação urgente pode precisar de escalonamento quando a equipe normal não consegue resolver. 00:08:57.480 --> 00:09:01.060 O Dynamics 365 mantém o trabalho em movimento em vez de deixá-lo parado com alguém. 00:09:01.760 --> 00:09:03.780 Às vezes um único problema cria muitos casos. 00:09:04.740 --> 00:09:06.960 Imagine uma falha de software afetando dezenas de clientes. 00:09:07.500 --> 00:09:09.380 Cada cliente entra em contato com o suporte separadamente, 00:09:09.500 --> 00:09:10.760 então cada relato precisa do seu próprio caso. 00:09:11.300 --> 00:09:13.240 Mas todos os relatos se conectam a um problema maior. 00:09:13.740 --> 00:09:15.460 Um caso o pai rastreia essa questão mais ampla, 00:09:15.520 --> 00:09:18.320 enquanto o caso os filhos rastreiam os relatos individuais dos clientes abaixo dele. 00:09:18.320 --> 00:09:20.580 Isso dá a equipe de suporte duas vezes ao mesmo tempo. 00:09:20.900 --> 00:09:23.000 Eles trabalham na falha subjacente por meio do caso pai, 00:09:23.320 --> 00:09:25.880 enquanto cada caso filho mantém o cliente correspondente informado. 00:09:26.220 --> 00:09:29.700 Quando encontram a correção, não precisam investigar a mesma falha do zero para cada solicitante. 00:09:30.180 --> 00:09:32.340 Casos duplicados criam um problema semelhante em menor escala. 00:09:32.920 --> 00:09:35.460 Um cliente pode enviar um e-mail e ligar sobre o mesmo problema, 00:09:35.600 --> 00:09:37.940 ou dois agentes podem abrir casos antes de perceberem o outro. 00:09:38.520 --> 00:09:41.380 Em vez de dividir o esforço, a equipe pode mesclar casos semelhantes. 00:09:42.020 --> 00:09:44.720 Um caso torna-se o registro principal e o trabalho permanece unificado. 00:09:44.940 --> 00:09:46.820 Ninguém deveria resolver o mesmo problema duas vezes. 00:09:46.820 --> 00:09:50.140 Levar um caso para a fila e as pessoas certas dá início ao trabalho, 00:09:50.320 --> 00:09:52.320 e o cliente espera uma resposta dentro do prazo prometido. 00:09:53.960 --> 00:09:56.140 Cumprindo promessas com SLA e trabalho guiado. 00:09:57.240 --> 00:09:59.360 Levar um caso para a pessoa certa é apenas metade do trabalho, 00:09:59.500 --> 00:10:01.520 pois o cliente também espera ajuda dentro do tempo prometido. 00:10:02.140 --> 00:10:05.100 E é aí que entra o acordo de nível de serviço, que chamaria de SLA. 00:10:06.140 --> 00:10:08.080 Um SLA anexa um cronômetro ao caso, 00:10:08.160 --> 00:10:11.020 para que a equipe saiba exatamente quanto tempo tem para cumprir a promessa feita ao cliente, 00:10:11.020 --> 00:10:13.640 seja para responder pela primeira vez ou para resolver o problema totalmente. 00:10:13.640 --> 00:10:15.440 Mas é que a automação é fundamental. 00:10:16.080 --> 00:10:17.380 Esses nem sempre são os mesmos prazos. 00:10:18.160 --> 00:10:20.220 Veja um cliente que espera um reconhecimento em uma hora, 00:10:20.300 --> 00:10:23.720 mesmo que a equipe técnica precise de dois dias úteis para encontrar e testar a correção. 00:10:24.640 --> 00:10:28.900 O Dynamics 300 C5 rastreia a meta da primeira resposta e a meta de resolução separadamente, 00:10:29.240 --> 00:10:32.860 para que a equipe possa agir rapidamente sem fingir que todo problema pode ser resolvido instantaneamente. 00:10:33.340 --> 00:10:35.060 Agora imagine um cliente cujo serviço funcionar. 00:10:35.060 --> 00:10:37.720 Ele não espera um reparo completo em 10 minutos, 00:10:37.840 --> 00:10:40.100 mas espera que alguém confirme que o problema é conhecido, 00:10:40.180 --> 00:10:42.680 explique o que acontecerá em seguida e o mantenha informado. 00:10:43.220 --> 00:10:45.360 A meta da primeira resposta é rastrear esse contato inicial, 00:10:45.540 --> 00:10:48.400 enquanto a meta de resolução rastrea todo o caminho até uma resposta ou correção. 00:10:49.000 --> 00:10:50.680 E clientes diferentes podem ter promessas diferentes. 00:10:51.220 --> 00:10:55.060 Uma empresa com suporte premium obtém metas de resposta mais rápidas do que um cliente em um plano padrão. 00:10:55.720 --> 00:10:59.940 Uma interrupção de alta prioridade tem um prazo menor do que uma dúvida rotineira de como fazer. 00:11:00.740 --> 00:11:03.980 Acordos de suporte, prioridade e tipo de caso definem as regras de tempo que se aprendem. 00:11:03.980 --> 00:11:05.740 Isso mantém as promessas justas e claras. 00:11:06.280 --> 00:11:09.200 Sem SLA, um agente pode trabalhar a partir do item mais antigo em uma lista 00:11:09.200 --> 00:11:11.480 enquanto um caso urgente perde silenciosamente seu prazo. 00:11:12.060 --> 00:11:15.260 Com SLA, essa tela de casos mostra indicadores de tempo que informam o agente 00:11:15.260 --> 00:11:16.900 qual promessa precisa de atenção primeiro. 00:11:17.460 --> 00:11:18.480 Assim você verá a pressão aumentar. 00:11:18.880 --> 00:11:21.220 Um caso com bastante tempo disponível precisa de trabalho, 00:11:21.340 --> 00:11:23.860 mas um caso próximo ao prazo de resposta precisa de atenção agora. 00:11:24.580 --> 00:11:27.460 As equipes também podem definir alertas ou etapas de escalonamento 00:11:27.460 --> 00:11:28.920 quando uma meta está próxima ou já expirou, 00:11:29.000 --> 00:11:31.500 para que um supervisor possa intervir antes que o cliente precise cobrar a equipe. 00:11:31.500 --> 00:11:33.720 As metas de tempo orientam a urgência 00:11:33.720 --> 00:11:35.940 e os fluxos de processo de negócios orientam o trabalho em si. 00:11:36.500 --> 00:11:39.440 Um fluxo de processo de negócios são conjuntos de estágios exibidos dentro do caso. 00:11:39.960 --> 00:11:41.720 Ele oferece ao agente um caminho claro a seguir 00:11:41.720 --> 00:11:44.060 com base em como a organização deseja que os casos sejam tratados. 00:11:44.500 --> 00:11:47.100 Os estágios podem ir da triagem, a investigação e a resolução 00:11:47.100 --> 00:11:49.400 com as perguntas e verificações certas em cada ponto. 00:11:49.820 --> 00:11:52.120 Pense nisso com uma lista de verificação com lugar definido no processo. 00:11:52.120 --> 00:11:54.960 Um novo agente não precisa adivinhar quais detalhes importam 00:11:54.960 --> 00:11:56.300 antes de enviar um caso a um especialista. 00:11:56.300 --> 00:11:59.340 O fluxo pode solicitar o produto, tipo de problema, impacto 00:11:59.340 --> 00:12:01.180 e outras informações que a próxima equipe precisa. 00:12:01.580 --> 00:12:03.440 Um agente mais experiente pode se mover mais rápido, 00:12:03.560 --> 00:12:06.160 mas o caminho compartilhado ainda mantém a equipe trabalhando na mesma direção. 00:12:06.580 --> 00:12:07.200 Aqui está um celular. 00:12:07.700 --> 00:12:09.300 Chega uma interrupção de serviço de alta prioridade. 00:12:09.800 --> 00:12:12.760 O caso entra na fila urgente e seu SLA começa a contagem regressiva. 00:12:13.460 --> 00:12:15.060 O agente confirma os detalhes do cliente, 00:12:15.060 --> 00:12:16.880 registra o impacto e envia a primeira resposta 00:12:16.880 --> 00:12:18.880 antes que essa meta de resposta expire. 00:12:19.860 --> 00:12:22.800 Em seguida, o fluxo do processo move o caso para o diagnóstico, 00:12:23.040 --> 00:12:25.620 onde a equipe coleta detalhes do erro e verifica relatórios relacionados. 00:12:25.620 --> 00:12:27.520 O caso então passa para a resolução, 00:12:27.640 --> 00:12:30.240 quando a equipe identifica a causa e prepara uma atualização para o cliente. 00:12:31.020 --> 00:12:33.300 Essa sequência também oferece aos gerentes uma visão mais clara. 00:12:33.840 --> 00:12:36.060 Eles conseguem ver onde o chamado trava durante a triagem, 00:12:36.140 --> 00:12:37.920 o diagnóstico ou a resposta final ao cliente. 00:12:38.680 --> 00:12:40.080 O fluxo não resolve o problema da equipe, 00:12:40.180 --> 00:12:42.880 mas evita que etapas básicas sejam esquecidas em um dia corrido. 00:12:43.560 --> 00:12:46.400 O Dynamics 365 também pode controlar quais alterações de status 00:12:46.400 --> 00:12:47.680 os agentes podem escolher em diferentes momentos. 00:12:48.360 --> 00:12:50.260 Isso é chamado de transição de motivo de status, 00:12:50.320 --> 00:12:51.960 que parece técnico, mas a ideia é simples. 00:12:51.960 --> 00:12:54.620 Um chamado deve seguir etapas sensatas. 00:12:54.620 --> 00:12:57.400 Você não quer que alguém marque um chamado como resolvido, 00:12:57.480 --> 00:12:59.060 enquanto ele aguarda uma verificação interna, 00:12:59.240 --> 00:13:01.940 ou que pule de novo para cancelado sem registrar o motivo. 00:13:02.800 --> 00:13:05.120 As opções permitidas podem mudar conforme o chamado muda. 00:13:05.500 --> 00:13:08.440 Por exemplo, um caso de investigação pode permitir que um agente o coloque em espera 00:13:08.440 --> 00:13:09.960 enquanto aguarda detalhes do cliente. 00:13:10.620 --> 00:13:13.260 Após a resposta do cliente, o agente pode retomar o trabalho ativo. 00:13:13.840 --> 00:13:15.980 Quando o problema é corrigido, o chamado pode ser movido para resolver. 00:13:16.360 --> 00:13:17.320 Isso é o que é chamado mais limpo. 00:13:17.820 --> 00:13:19.300 Apenas uma resposta não finaliza o trabalho. 00:13:19.300 --> 00:13:22.820 A equipe precisa registrar como o problema terminou, então fechar o chamado corretamente. 00:13:24.080 --> 00:13:25.640 Resolução aprendizada e melhor atendimento. 00:13:26.780 --> 00:13:28.820 Enviar uma resposta não fecha um chamado automaticamente. 00:13:29.200 --> 00:13:32.460 A equipe precisa registrar a resolução, o que significa anotar o que corrigiu o problema 00:13:32.460 --> 00:13:34.100 ou qual resposta final o cliente recebeu. 00:13:34.580 --> 00:13:36.600 Pode ser o envio de um dispositivo de substituição, 00:13:36.700 --> 00:13:39.980 reembolso de um pagamento duplicado ou atualização de uma configuração que impediu acesso. 00:13:40.920 --> 00:13:45.000 Essa nota torna-se parte do registro do cliente e oferece ao próximo agente um ponto de partida útil 00:13:45.000 --> 00:13:48.080 Se o mesmo cliente contatar o suporte meses depois com um problema relacionado, 00:13:48.720 --> 00:13:50.000 às vezes a primeira correção funciona. 00:13:50.320 --> 00:13:52.820 Talvez o cliente siga as instruções e o erro retorne. 00:13:53.380 --> 00:13:55.540 Talvez uma peça de substituição chegue, mas não resolva a falha. 00:13:56.080 --> 00:14:00.280 Nessa situação, a equipe pode reabrir o chamado ou colocá-lo de volta na fila para mais trabalho, 00:14:00.400 --> 00:14:02.380 em vez de iniciar um novo registro sem histórico. 00:14:03.340 --> 00:14:04.900 O chamado continua de onde a equipe parou. 00:14:05.340 --> 00:14:06.640 Isso é importante quando a responsabilidade morre. 00:14:06.920 --> 00:14:09.660 Um novo agente pode ver o que o anterior tentou, o que o cliente confirmou 00:14:09.660 --> 00:14:11.380 e o que ainda precisa ser verificado. 00:14:11.380 --> 00:14:16.040 O cliente não precisa explicar toda a história desde o início só porque outra pessoa assumiu o trabalho. 00:14:16.880 --> 00:14:20.000 Com o tempo, todos esses chamados também mostram à equipe de suporte o que está acontecendo 00:14:20.000 --> 00:14:21.240 além de um problema específico. 00:14:21.740 --> 00:14:23.560 Os gerentes podem analisar o tempo de resolução, 00:14:23.780 --> 00:14:26.400 que rastreia quanto tempo os chamados levam da abertura até o fechamento. 00:14:27.000 --> 00:14:29.520 Eles podem ver o tempo por etapa, que mostra onde os chamados gastam mais tempo. 00:14:30.060 --> 00:14:32.400 Eles também podem observar a resolução no primeiro contato, 00:14:32.400 --> 00:14:36.240 ou seja, com que frequência a primeira pessoa que fala com o cliente consegue resolver o problema sem transferências. 00:14:36.780 --> 00:14:37.700 Para cair o trabalho também importa. 00:14:38.060 --> 00:14:40.660 Se uma fila lota toda segunda-feira de manhã, a equipe consegue ver isso. 00:14:40.660 --> 00:14:43.960 Se chamados técnicos passam dias aguardando uma verificação interna, 00:14:44.280 --> 00:14:45.620 esse atraso aparece nos dados do caso. 00:14:46.040 --> 00:14:49.080 Se uma equipe fecha os chamados rapidamente, mas os clientes continuam reabrindo-os, 00:14:49.240 --> 00:14:52.160 a equipe tem motivos para analisar melhor a qualidade dessas primeiras correções. 00:14:52.880 --> 00:14:54.680 Os números não explicam tudo por si sós. 00:14:55.020 --> 00:14:57.060 Eles indicam à equipe quais perguntas valem a pena ser feitas. 00:14:57.720 --> 00:14:59.180 Por que o chamado sobre um produto está aumentando? 00:14:59.560 --> 00:15:01.860 Por que um certo tipo de caso demora mais do que o esperado? 00:15:02.540 --> 00:15:06.600 Por que os agentes pesquisam repetidamente a mesma resposta sem encontrar um artigo de conhecimento útil? 00:15:07.320 --> 00:15:09.540 Padrões transformam o trabalho de suporte em aprendizado prático. 00:15:09.540 --> 00:15:12.400 Um aumento em casos semelhantes pode apontar uma falha no produto. 00:15:12.820 --> 00:15:14.920 Pode mostrar que uma atualização recente confunde os clientes. 00:15:15.340 --> 00:15:17.600 Pode revelar que um guia de instruções precisa de passo mais claro. 00:15:18.280 --> 00:15:20.240 Em vez de tratar cada solicitação como algo isolado, 00:15:20.320 --> 00:15:22.260 a equipe pode identificar a causa comum e trabalhar nela. 00:15:22.720 --> 00:15:24.120 Isso pode reduzir o volume de futuros chamados. 00:15:24.500 --> 00:15:26.020 O feedback do cliente também faz parte desse cenário. 00:15:26.360 --> 00:15:29.160 Um chamado fechado pode mostrar que a equipe atingiu a meta de resposta, 00:15:29.340 --> 00:15:32.400 mas o cliente pode se sentir frustrado se teve que contatar o suporte três vezes. 00:15:33.600 --> 00:15:37.280 Analisar tanto o histórico do caso quanto o feedback dá aos gestores uma visão mais completa da experiência. 00:15:37.280 --> 00:15:39.700 Alguns clientes preferem evitar a criação de um chamado. 00:15:40.140 --> 00:15:41.600 É aí que um portal de autoatendimento pode ajudar. 00:15:42.000 --> 00:15:44.300 Por meio de um portal, os clientes podem criar uma solicitação, 00:15:44.520 --> 00:15:46.500 verificar seu status, adicionar novas informações 00:15:46.500 --> 00:15:49.160 ou ler artigos de suporte aprovados sem ligar para a equipe. 00:15:50.040 --> 00:15:52.420 Para perguntas simples, isso economiza tempo para todos. 00:15:53.080 --> 00:15:54.620 Um cliente pode verificar o status de entrega, 00:15:54.680 --> 00:15:56.680 ou seguir um dia de configuração quando for conveniente para ele. 00:15:57.480 --> 00:16:00.620 Enquanto isso, os agentes podem dedicar mais tempo a problemas que precisam de uma pessoa 00:16:00.620 --> 00:16:02.380 para investigar, explicar ou tomar uma decisão. 00:16:02.380 --> 00:16:07.020 O Dynamics 365 Customer Service também pode se conectar com ferramentas conhecidas da Microsoft 00:16:07.020 --> 00:16:08.000 em torno do processo de chamada. 00:16:08.240 --> 00:16:09.980 Um agente pode trabalhar com o e-mail pelo Outlook. 00:16:10.420 --> 00:16:12.340 Uma equipe pode discutir um problema difícil no Teams. 00:16:13.020 --> 00:16:15.040 Documentos e informações compartilhadas podem ficar no SharePoint. 00:16:15.340 --> 00:16:18.620 O Power BI pode transformar dados de chamados em relatórios e dashboards, 00:16:18.720 --> 00:16:21.640 enquanto as ferramentas da Power Platform podem dar suporte a formulários extras, 00:16:21.800 --> 00:16:23.140 alertas ou etapas automatizadas. 00:16:23.800 --> 00:16:24.880 Cada ferramenta tem sua profissão. 00:16:25.280 --> 00:16:28.940 O caso continua sendo o local, onde o problema de suporte e seu histórico permanecem conectados, 00:16:28.940 --> 00:16:32.160 mesmo quando as pessoas usam outras ferramentas para comunicar e compartilhar arquivos ao seu trabalho. 00:16:32.740 --> 00:16:35.100 A gestão de casos não se trata apenas de preencher uma tela de chamada. 00:16:35.580 --> 00:16:37.520 Trata-se de dar a cada problema do cliente um caminho claro, 00:16:37.580 --> 00:16:39.840 uma resposta registrada e uma equipe que possa aprender com o que aconteceu. 00:16:42.000 --> 00:16:43.340 Mantenha toda a história do cliente unida. 00:16:44.000 --> 00:16:45.300 Portanto, aqui está o verdadeiro aprendizado. 00:16:46.180 --> 00:16:49.260 O gerenciamento de casos do Dynamics 365 mantém o problema, 00:16:49.400 --> 00:16:51.720 trabalhos, promessas e o resultado em um único registro. 00:16:52.320 --> 00:16:54.000 Chega de contexto perdido ou correções repetidas. 00:16:54.420 --> 00:16:55.540 Analise seu próprio acesso de suporte. 00:16:56.100 --> 00:16:57.920 Dá para onde as informações do cliente desaparecem. 00:16:57.920 --> 00:17:00.200 É aí que reunir tudo isso muda tudo. 00:17:01.000 --> 00:17:03.100 Inscreva-se na sua plataforma de podcast favorita 00:17:03.100 --> 00:17:05.020 para mais pílulas de conhecimento da Microsoft comigo, 00:17:05.180 --> 00:17:07.260 Mirko Peters, no M365.fm, 00:17:07.340 --> 00:17:10.220 onde explicamos as ferramentas da Microsoft para o trabalho diário em linguagem 5.