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 do Suporte

• Como eu atuo nos tickets? 

1. Analisar o incidente com as informações enviadas  pelo cliente e caso não esteja claro as evidências, realizar uma interação com o cliente para o entendimento e coleta do máximo de dados para simular  o teste. Vale a pena ressaltar a importância de como documentar o ticket de acordo com o Processo de Boas Práticas, presente nesta documentação.

   
   

   Não solicitar informações que o cliente já enviou no ticket.

   
   

2. Após todo entendimento, consultar todas documentações no TDN/KCS e validação se a rotina e/ou processo está desatualizado.
   
   
3. Preparando meu ambiente igual ao do cliente para realização do teste:
   1. Utilizar o mesmo release, data do fonte e montando o cenário igual ao do cliente.
   2. Realizar teste/evidência
   3. Se reproduzir ticket, devo abrir uma issue para o desenvolvimento.
   4. Se não reproduzir, devo enviar o teste ao cliente e perguntar se faltou algum detalhe.
      
      
4. Em caso de dúvidas sobre o processo, deve consultar o time, trocar conhecimento com a equipe de suporte e maestro/Tech Lead.
   
   
5. Quando o ticket chega ao fim, para solucionar o mesmo devemos documentar todo processo realizado e incluir a pesquisa de satisfação.

• O que ele deveria fazer no FCR?

1. O First Call Resolution -  FCR; é a solução na primeira interação, quando o ticket é aberto via portal do cliente e já existe uma outra ocorrência relatando o mesmo incidente, para garantir o FCR devemos solucionar o ticket apenas com uma interação”
   
   
2. Ao criar um novo ticket via atendimento telefônico é necessário registrar o incidente para salvar e após essa interação de abertura, para garantir o FCR “Devemos incluir apenas mais uma interação para solucionar o ticket” deixando como status Resolvido.

• Qual prazo de finalização?

O prazo de finalização do ticket é medido pelo SLA , Service Level Agreement  que  é composto por criticidade de cada rotina (utilizando o critério de pesos de 1 a 6).

Essa composição é definida na abertura do ticket. Portanto, medimos o prazo de finalização de acordo com SLA no ticket.

• Qual status devo usar para cada cenário?

Para informações sobre status dos tickets, clique aqui.

• Qual classificação de ticket preciso utilizar para cada cenário?

No primeiro momento é importante validar o cenário do cliente, tão logo a verdadeira causa da questão seja identificada, deve-se atribuir uma das causas disponíveis de acordo com a documentação abaixo:

1. Para os times de suporte Protheus, clique aqui.
2. Para os demais times, veja o KCS EC - ZEN - Campos Causa e Classificação no ticket.

• Quando o cliente solicita posicionamento? O que devo fazer

Cliente entra em contato solicitando o prazo de entrega o analista deverá verificar se a demanda foi priorizada, verificando os campos do ticket "Solicitação Priorizada" e "Data Priorização", "além de verificar o campo "Data Acordo Entrega" (neste campo estará a data prevista de entrega fornecida pelo time de desenvolvimento).

• Cliente solicita prazo no atendimento do ticket:

1. Ticket sem atribuição:
   • Deve assumir e informar o cliente, durante o atendimento, que será avaliado dentro do SLA.
2. Ticket atribuído a outro analista:
   • Caso o analista que atendeu a ligação já saiba a solução, deve enviá-la no ticket.  Caso não tenha ainda uma solução, deve posicionar o cliente, durante o atendimento, que será avaliado dentro do SLA e informar diretamente o analista atribuído/responsável.
3. Cliente está parado e não pode aguardar o prazo SLA:
   • Indicar Consultoria Técnica ou acionar a liderança para viabilizar a possibilidade de antecipar.

• Quando o cliente não concorda com a solução apresentada, o que fazer?

Certificar-se que a solução apresentada é coerente e realizar contato telefônico para alinhamento de expectativas do cliente.

• Quando o cliente tem algum problema na base de dados, o que fazer?

1. Erro causado por algum fonte padrão:
   • Acionar o Tech Lead para confirmação sobre o incidente e realizar a abertura de Issue, pois o dev precisa realizar o ajuste na base do cliente. 
2. Não foi possível identificar o cenário para reprodução e nem a causa raiz:
   • Indicar escopo de Consultoria (Técnica, Módulo ou In loco) de acordo com escopo para identificar qual a inconsistência nos registros.
3. Para suporte a registros inconsistentes, específicos.
   • Ex. Se refizer o processamento seguindo o processo exatamente igual, com um registro idêntico inserido para testes, o problema não ocorre. Somente com o registro que já estava gravado na base). Deverá ser indicado a Consultoria Técnica. Que canal devo Procurar: https://tdn.totvs.com/x/NOJeI

• Cliente SMART com ambiente desatualizado, quem acionar?

O Smart é um Software as a Service (SaaS,) cujo é uma forma de disponibilizar softwares e soluções de tecnologia por meio da internet, como um serviço.

O cliente deve acionar o time de Suporte padrão responsável por cada módulo específico onde fará a avaliação dos fontes.

• Se o fonte atualizado está no acumulado, o cliente deve aguardar a janela de atualização automática.
• Se o fonte atualizado está somente em Issue fora do acumulado, o ticket será associado no Issue e o cliente irá aguardar a atualização em seu ambiente.
  

O cliente pode acompanhar a janela de atualização automática e outras dúvidas específicas do SMART na página SmartERP.

• Quando o cliente interage no ticket mas está falando com o time interno. O que fazer?

Quando o cliente interage no ticket, mas está evidente que se trata de uma troca de e-mails interna, e não um contato com a TOTVS, significa que o cliente não está aguardando um parecer do Suporte neste momento.

Apenas envie o ticket novamente com o status anterior (Pendente/Resolvido) e registre em comentário interno para fins de histórico “[troca de e-mails interna]”.

Se houver alguma reincidência, onde a questão reportada ocorre novamente, realize contato telefônico com o cliente e explique que a troca de mensagens em cima do próprio e-mail recebido pelo Suporte, para praticidade ao cliente, gera reabertura no ticket. Uma vez que, se tratando de comunicação interna, é sempre recomendado desvincular os e-mails, visto que este engano pode causar volumes indevidos de demandas na área de Suporte e consequente redução de agilidade nos retornos. Registre o contato com o cliente em interação interna e retorne ao status anterior (Pendente/Resolvido). Obs: É possível criar uma macro a fim de ter fácil acesso à informação que deve ser passada ao cliente, mas recomenda-se que o registro do contato nestas situações sejam realizados em interações internas, e não públicas, visto que não se tratam de um registro pertinente à análise efetiva do ticket. A utilização de interação pública compromete o indicador de qualidade “até 5 dias sem retorno”. 

• Como devo trabalhar com a Data Controle no ticket? O que reportar ao cliente quando definimos uma data?

O campo Data controle é registrado pelos Agile Master em todos os tickets que recebem solicitação de prioridade, e também pelos próprios analistas sempre que notam essa necessidade de priorizar a demanda, ou quando combinam com o cliente uma data de retorno. Nessas situações é importante posicionar o cliente que compreendemos sua necessidade de urgência de forma que estamos priorizando a demanda, informar que estamos avaliando as evidências enviadas para análise do incidente e posterior retorno, o mais rápido que possível. Indicar possíveis medidas paliativas para contorno provisório da situação, e combinar que daremos um posicionamento até x data, podendo ocorrer antes.

Importante: Este campo é utilizado como modo de sinalizar o analista e impedir que o ticket não receba o retorno até a data combinada, e deve ser exibido de modo evidente nas views de cada analista e na views de tickets priorizados das áreas para uma gestão eficiente destas demandas. Em casos que o ticket retornar necessitando de nova análise, o analista deve atualizar esse campo para a nova data de retorno prevista.

• Quando é necessário chamar o Tech Lead?

Tech Lead na estrutura ágil do Suporte recebe o papel de focar em situações que sobressaltam discussões sobre a usabilidade do produto, e o conhecimento técnico do time para resolução eficiente de problemas, de modo que este deve ser acionado para apoios desta natureza (para identificar com precisão as situações que envolvem o Tech Lead como referência, consulte o Checklist de atividades de sua estrutura).

• Como realizar atendimento via chat?

O atendimento via chat é mais um canal entre Suporte e cliente, que vem ganhando espaço e preferência dentre os canais disponíveis visto sua praticidade e agilidade. O atendimento deve ser pessoal e o mais efetivo possível, fornecendo uma pronta solução quando se trata de casos mapeados (assim como ocorre em atendimentos via fone), ou registrando criteriosamente a ocorrência obtendo prontamente todos os detalhes necessários à análise do problema (assim como ocorre na primeira interação em atendimentos via ticket). 

• Como proceder quando o atendimento envolve análise de dados do cliente que possam comprometer o cumprimento da LGPD (Lei Geral de Proteção de Dados)?

Sempre que for necessário armazenar dados do cliente em nossos servidores, Google Drive ou máquina do TOTVER, precisamos ter atenção e alguns cuidados. Todos os dados recebidos devem ter alguma finalidade de uso. Caso receba dados desnecessários, descarte-os e oriente o cliente a enviar somente o necessário. Depois que a demanda foi resolvida e aprovada pelo cliente, é importante que o analista de suporte elimine os dados e as bases acessadas. 

• Como realizar atendimento ao telefone?

Atender fazendo a identificação da área de atendimento, nome do analista e saudação. Praticar a escuta ativa, registrar com o máximo de detalhes a dúvida do cliente e informar o número do ticket aberto. 

Sempre perguntar se o cliente já tem o ticket aberto antes de abrir um novo ticket.

• Quando o cliente solicitar que eu altere algum parâmetro para ele, o que devo fazer?

Orientar o cliente como fazer, enviar documentação e vídeos explicativos. Se for o caso, acessar e fazer junto com o cliente em base de homologação.

• Acredito que devemos fazer algo a mais quando não reproduzimos o problema visto que neste item que o cliente desiste e mais reclama.Temos alguma ferramenta para reproduzir igual ao cliente? O que precisamos melhorar nas ferramentas para conseguir fazer isso? Não deveria colocar o TOTVS Replay?

Entendo que o totvs replay atende esta demanda.

• Quando orientar o ESN????????????????????????????????????????????

Somente quando o cliente solicitar  upgrade de seu contrato e Garantia estendida.

Consultar no Zendesk, selecionando o nome da organização, no painel ao lado esquerdo terá a opção de nome e E-mail do GAR e EAR.

• O que é o ESN?

Executivo de Soluções e Negócios.