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)

1 - 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..”

2 - 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 diferentes cenários:
      
      

      1. Cliente parado:

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

         2. 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.

         3. 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)

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

      2. Caso seja final de expediente:

         1. 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:

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

      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 RPO atualizado 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 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.)
            
            Importante: Como padrão estabelecido, em cada ticket, não deve haver mais do que 3 interações por escrito sem que haja contato telefônico com o cliente.
            
            A questão reportada foi compreendida.
            "Apenas confirmando, tua 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?"
           
   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.

1.  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:
         • Profiler do processo (execute na rotina em que identificou a inconsistência);
         • XML gerado (em casos de integração);
         • Dados do ambiente Teste no qual ocorre o problema, se o ambiente estiver hospedado no Cloud da TOTVS, caso venha ser necessário.
   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 utilizando obrigatoriamente a macro PESQUISA DE SATISFAÇÃO - Ticket Resolvido.

Boas práticas - Protheus