Objetivo:

Fornecer orientações claras e objetivas para os colaboradores sobre como deve ocorrer o atendimento dos ticket.

1 - Revisão de dados dos tickets.

Ao receber um ticket, alguns itens devem ser observados, no entanto, esta ação de verificação pode ocorrer em qualquer momento, na triagem, na interação, na solução ou na transferência. Ao revisar o ticket, deverão ser observados os seguintes itens:

• Assunto do ticket se tem coerência com a necessidade descrita na solicitação;
• Se o ticket está com a marca TOTVS;
• Formulário se está como Suporte Técnico;
• Se o campo Tipo da Solicitação está com Suporte técnico ou Consultoria Técnica;
• Se o campo Tipo está correto;
• Se a Prioridade está de acordo com a urgência mencionada pelo cliente no ticket;
• Se a causa está preenchida de acordo com o TDN;
• Se o release/versão/ambiente está preenchido;
• Se o catálogo está preenchido corretamente;
• Se o ticket está registrado em nome do cliente (código T)

2 - Interação.

Considere os itens abaixo:

1. Ler a descrição inicial com atenção, avaliar os anexos enviados e confirmar a questão reportada com o cliente. Com a devida confirmação do caso, evitaremos o envio de informações incorretas e assuntos distintos dentro do mesmo ticket.
2. Avalie a classificação do ticket se está correta, se for necessário reclassificar (criticidade ou tipo) deve incluir uma interação interna explicando o motivo da alteração.
3. Certifique que está atuando conforme estratégia da sua equipe em relação ao SLA/Aging.
   1. No modelo ágil, contribua com a estratégia no momento da Daily. Caso tenha  dúvidas, busque saná-las no momento da agenda, caso alguma persista, busque o alinhamento com seu Agile Master / Squad sobre qual a estratégia para o dia. Dessa forma será possível se antecipar caso ocorra alguma situação específica.
   2. Fique atento a estratégia definida em sua Squad:
      1. No link a seguir (Indicadores do Suporte Padrão), é possível acessar informações sobre principais indicadores relacionados ao processo de atendimento.
4. Revise o preenchimento dos seguintes campos do Ticket: Catálogo, Causa, Release, Formulário.
5. Em toda interação, seja claro e objetivo ao descrever as solicitações ou soluções no chamado. Sempre procurar escrever de forma respeitosa e seguindo as regras gramaticais.
6. Deverá ser seguido a estrutura de atendimento do ticket (descrito no item 1.1).
   
   Exemplo de interação:
   “Olá [nome cliente], eu sou o analista [seu nome] e seguirei com o seu atendimento. Entendi que seu incidente é [detalhar o que entendeu], está correto meu entendimento? Notei que já enviou  algumas informações importantes para a nossa análise..”

3 - Estrutura do atendimento de tickets.

O objetivo principal é minimizar a quantidade de interações nos tickets e gerar uma experiência positiva ao cliente uma vez que, ao seguir a estrutura a seguir, as interações serão claras e objetivas.

Estão listados abaixo seus principais objetivos:

• Minimizar retrabalho;
• Melhorar a experiência do cliente no atendimento;
• Otimizar tempo de atendimento;
• Empatia com o cliente.

Os atendimentos devem ser estruturados da seguinte forma:

1. Introdução:
   1. Ler a interação do cliente com atenção, avaliar os anexos enviados.
   2. Confirmar o problema do cliente. Com a devida confirmação do caso, evitaremos o envio de informações incorretas e assuntos distintos dentro do mesmo ticket.
   3. Verificar quais são os pontos focais e contatos do cliente envolvidos na demanda e adicioná-los nas comunicações dos tickets. 
      
      
   4. Atenção aos seguintes cenários:
      
      

      1. Cliente parado:

         • Acessar o ticket e validar se o registro e artefatos enviados, são suficientes para realizarmos o atendimento.

         • Entrar em contato com o cliente por telefone, verificar se é uma ocorrência pontual ou generalizada, e se de fato a operação está parada sem saída de contorno, ajustar o campo Impacto para que fique de acordo com a urgência.

         • Realizar a interação no ticket, se necessário aplicar a macro solicitando mais informações e informando o horário do atendimento do suporte (das 07h às 19h)

         • Sinalizar o líder sobre falta de retorno de cliente que estava parado. 
           
           

      2. Caso seja final de expediente:

         • Avise imediatamente o seu People Lead |Agile Master, para que possa estar ciente de seu atendimento e tomar ações necessárias em caráter de exceção.
           
           

      3. Performance:

         • Primeiro passo,  verificar se o cliente está com ambiente atualizado, coletar as informações e logs de produto específicos que fornecerão embasamento para identificar a causa do baixo desempenho através de análise pelo Suporte. Se o produto for Protheus, coletar o questionário (localizado neste Link)
           
           

      4. Customizado:

         1. Para garantir que a ocorrência está no customizado/ponto de entrada do cliente, deve solicitar que o mesmo processo seja executado em um ambiente sem customizações. Confirmando essa informação, o analista deverá informar o cliente que o Suporte Padrão não realiza manutenção em customizados / ponto de entrada, esse serviço pode ser realizado por sua própria TI ou se preferir temos uma equipe HUB(se o produto for Protheus) para esse serviço, porém existe um custo. Caso queira podemos transferir o ticket para que essa equipe realize um orçamento.

            
            
            Exemplos:
            
            A questão reportada não foi compreendida.
            "Verifiquei tuas colocações, porém, não ficou claro para mim a ocorrência. Você pode me dar mais detalhes por favor?
            Favor descrever o processo realizado, o comportamento obtido e sua necessidade ou expectativa (qual o comportamento correto em sua percepção)."
            
            Observação: Se a interação do cliente não permitir o entendimento do incidente, fazer contato verbal para entendimento e registrar com quem falou tudo o que foi conversado, deixar o ticket pendente (caso não consiga contato).
            (Exceto em equipes durante sazonalidades ou período crítico/demanda, neste cenário, realizar uma interação humanizada informando que o conteúdo registrado no ticket, não possibilita o entendimento do cenário, solicitando mais detalhes do processo.)
            
            

            Como padrão estabelecido, em cada ticket, não deve haver mais do que 3 interações públicas, por escrito sem que haja contato telefônico com o cliente, independentemente do tipo de contrato ou da forma de abertura do ticket (portal ou telefone).

            
            

            A questão reportada foi compreendida.
            "Apenas confirmando, sua questão é [descrever com suas próprias palavras o problema interpretado]. Está correto meu entendimento?"
            
            
            

2. Desenvolvimento:
   1. Neste tema será desenvolvido o problema do cliente conforme a sua introdução, detalhando todas as informações necessárias para sua resolução.
   2. Orientar o cliente para a resolução da questão.
      1. Ao apresentar a solução ao cliente, o analista deve recomendar a realização de testes primeiramente no ambiente de homologação, utilizando a macro de texto Recomendar testes em homologação, existente no Zendesk.
   3. Nesta etapa serão encaminhados:
      1. Documentações existentes relacionadas com o caso (KCS/TDN);
      2. Caso não exista KCS sobre o tema, realizar a criação do mesmo e enviar para o cliente após publicado, o que contribuirá para que nossa base de conhecimento fique ainda mais rica de informações;
      3. Testes (prints e/ou evidências relacionadas);
      4. Se possível, trechos de fontes (demonstrando trecho do fonte)
      5. Exemplos de interações:
         • "Com base nas informações enviadas, realizamos o teste, mas não foi possível chegar ao mesmo comportamento mencionado. Por favor verifique nossa evidência de teste anexa e indique se há alguma particularidade a observar para chegarmos ao mesmo cenário. Há algum passo/processo diferente do que tenha realizado que possamos ajustar para refazer os testes conforme teu cenário?
           Estou enviando a documentação principal relacionada ao assunto mencionado, e que pode conter as informações relevantes ao que precisa: [APLICAR MACRO e VINCULAR KCS/TDN relacionado] [informar o trecho do KCS que atenderá a necessidade]."
           
   4. Caso a ação, seja indicação de artigo KCS, registrar de forma humanizada. Se o Artigo possuir muitas informações, indicar o trecho que atenderá a necessidade pontual do cliente.
      1. Exemplos de interações:
         • “Olá [nome cliente], eu sou o analista [seu nome] e seguirei com o seu atendimento. Entendi sua solicitação [detalhar o que entendeu], está correto meu entendimento? Temos uma documentação que pode atender sua necessidade. Veja que no trecho [especificar o trecho] aborda o tema solicitado. Avalie as orientações, e caso não atenda sua expectativa, poderia, por favor, me encaminhar mais detalhes do processo, se possível uma evidência em vídeo?”
         • "Estou enviando a documentação principal relacionada ao assunto mencionado, e que pode conter as informações relevantes ao que precisa: (vincular o KCS relacionado e informar o trecho que atenderá a necessidade, quando for o caso)."
   5.  Caso não tenha KCS, desenvolver o mesmo, o que contribuirá para que nossa base de conhecimento fique ainda mais rica de informações.
   6. Se o incidente citado não é uma ocorrência conhecida com solução mapeada, faça levantamento completo de tudo que necessita (parâmetros, rotinas, cadastros, consultas, relatórios, release, etc.)
   7. Envio de atualização sobre o caso só pode ocorrer em duas situações:
      1. Incidente idêntico ao do Issue (associar);
      2. Quando houver um cenário mapeado e evidenciado exatamente igual ao do cliente que apresente a ocorrência (banco, SO, release e datas de fontes). Enviar a solução a ser aplicada em ambiente de testes do cliente, sugerindo que aplique se o ambiente estiver com datas inferiores às da nova solução.
         
         
   8. Atenção aos seguintes cenários:
      
      

      1. Cliente parado:

         • Caso seja pontual repassar o processo do início ao fim, com o objetivo identificar alguma falha na execução do processo, avaliar se possíveis atualizações fariam a diferença no ambiente do cliente.

         • Caso seja generalizado, confirmar se o cliente utiliza a estrutura do Cloud da TOTVS, através da ferramenta TCloud ou avaliar com time de framework, se não utilizar a estrutura do Cloud.
           
           

      2. Performance:

         • Caso a lentidão/travamento persista no ambiente atualizado, solicite o LogProfile (se produto Protheus).

         • Realize a análise internamente em conjunto com seu agile master/tech lead
           
           

3.  Conclusão:
   Resolver o ticket ou solicitar outras evidências.
   1. Conclusão - Solicitação de informações para análise.
      1. Para analisarmos o caso pontualmente e direcionarmos a solicitação de forma mais ágil e assertiva, é imprescindível que o cliente forneça / esclareça as seguintes informações:
         • Rotinas e datas dos fontes envolvidos no processo (ambiente; servidor; porta; versão, assim poderá acessar e validar os dados);
         • Detalhar o cenário (processo e comportamento);
         • Listar as dúvidas conforme análise do erro descrito (Foi após alguma atualização? - Ocorre em algum tipo específico de registro ou todos?) e, caso seja necessário, solicitar vídeo ou evidência do processo para casos mais detalhados onde só a descrição feita pelo cliente não nos dá insumo para realizar o teste.
      2. Deverá ser fornecido:
         • [SE PROTHEUS] Profiler do processo (execute na rotina em que identificou a inconsistência);
         • [SE INTEGRAÇÃO EAI] XML criteriosamente gerado conforme a orientação: “Como Extrair o XML na integração EAI (Protheus)“. 
         • Nome e fone (com DDD) para contato, caso venha ser necessário (obs: mantenha sempre seu cadastro atualizado junto ao CST);
         • Dados do ambiente Teste no qual ocorre o problema, se o ambiente estiver hospedado no Cloud da TOTVS, caso venha ser necessário.
      3. Atenção aos seguintes pontos:
         • Status do ticket deverá ser mantido para pendência do cliente até o retorno das informações;
         • Caso o cliente informe durante o contato telefônico, as informações necessárias para extração dos logs, essa informação deverá ser documentada no ticket e o mesmo deverá ficar em aberto para análise do suporte;

         • Relembre a visão Zendesk x Visão cliente.
           
           

           Para mais informações importantes sobre abertura de ticket para que o seu atendimento seja mais ágil, clique aqui.

           
           
           

   2. Conclusão - Solução - Resolver o Ticket.
      1. Nesta etapa, se as orientações do item anterior forem suficientes para solucionar o erro, o ticket deverá ser resolvido com a solicitação da pesquisa de satisfação.

4 - Quando transferir / abrir ticket filho ou um novo ticket.

1. Ocorrência exclusivamente de outro módulo/produto → Transferir:
   • Cliente abriu o ticket em uma equipe errada e pela o motivo da transferência (*NÃO deverá ser utilizado apenas o texto “transferido para equipe correta/pertinente”).interação da abertura e ou evidência enviada fica claro que o atendimento é pertinente a outro módulo. Neste caso, necessário efetuar uma interação interna, informando resumidamente.
2. Ocorrência que depende de apoio de outra equipe → Acionar Maestro ou ponto focal:
   • Pela análise efetuada foi identificado que se faz necessário uma atuação com apoio/conhecimento de outra equipe, então deverá alinhar com maestro de seu time para que ele alinhe o com maestro ou ponto focal do outro time para agendar atuação em conjunto.
   • Exceção: com o time de JOI deverá abrir ticket filho.
3. Ocorrência inicial resolvida, porém processo ainda não concluído
   • Abrir novo ticket para continuidade do processo ou caso seja outro processo/módulo/produto citando o ticket atual para manter histórico para atuação do novo incidente. No ticket anterior, citar a solução e que o novo incidente será tratado no ticket xxxxx.
   • Exemplo: Cliente gerou a solicitação que não conseguia gerar a DIRF no Financeiro, esse processo foi concluído, mas não conseguiu transmitir, neste caso gerar uma nova solicitação para o time de RH.

5. Passos a seguir antes de enviar a consultoria do Suporte.

Certifique-se de todas as ações antes de enviar o ticket à Consultoria e saiba qual consultoria deverá ser direcionada, consultando nosso material de apoio Suporte Padrão e Consultorias.

6. Quando assumir tickets de outros analistas.

Durante atuação online:

1. Se o ticket citado pelo cliente for de outra equipe, transferir a ligação para URA e informar o caminho que o cliente precisa seguir (números da URA). Se o cliente questionar o porquê não pode transferir direto para a equipe, deve informar que o sistema precisa identificar a empresa para facilitar a abertura do ticket.
2. Se o ticket citado for de sua equipe, consultar o atribuído para saber se pode transferir a ligação
3. Em caso negativo (ausência ou outra atividade), ler todo o ticket com atenção e entender a criticidade do cliente
1. Se for crítico:
1. Se tiver conhecimento sobre o assunto e decidir atuar no ticket, deverá assumi-lo até a solução.
2. Caso não tenha conhecimento, acione a liderança para avaliar priorização.
2. Se não for crítico:
1. Se tiver conhecimento sobre o assunto e decidir atuar no ticket, deverá assumi-lo até a solução.
2. Caso não tenha conhecimento, registre o contato do cliente em interação “interna” no ticket e mantenha o atribuído anterior.

Durante atuação offline:

Somente quando o analista atribuído estiver ausente ou estratégia e alinhamento com sua liderança

1. Ler todo o ticket com muita atenção
2. NUNCA solicitar informações que já estão no ticket
3. Se atuar no ticket, deverá ligar para o cliente, confirmar o entendimento do cenário e assumi-lo até a solução.
4. Usar interação exemplo:
   "Olá xxx,
   Eu sou o analista [seu nome] e darei sequência do atendimento iniciado pelo [nome do outro analista]. Conforme conversamos precisamos de mais alguns dados para analisarmos o incidente, por isso, favor nos encaminhar [dados]."

7. Avaliar seus GAPs na ferramenta.

Consultar seus GAPS pelo menos 1 x por semana e ajustar no Zendesk os tickets que não estão fechados.

• • Carreira e Indicadores

• • Central do analista

• • Gap's de Processo de Atendimento

• • Gap's de Tickets sem Release Informada

Boas Práticas - Suporte