Exibir origem

<style>
#title-text {
	display: none !important; 
}

.custom-button{
	font-weight: bold}

.composition-banner-overlay{
	background:rgba(0,0,0,0.0);min-height:initial;position:relative;border-radius:5px;
}

.composition-banner-title{
	color: #FFFAF0!important;
	font-weight: 900;
	font-style: oblique;
}

</style>

<style>

.expand-control-text {
    color: #FF9900;
	font-size: 15px !important;
	font-weight:500 !important;
}

.expand-icon, .aui-icon, .aui-icon-small, .aui-iconfont-chevron-right {
    color: #FF9900;
}

}
.wiki-content img.confluence-embedded-image, .wiki-content img.editor-inline-macro, .wiki-content table.wysiwyg-macro {
    cursor: grabbing;
}  

ul. {
	list-color: #FF9900;
	list-style: square;
}

hr {
    border-bottom: 2px solid #FF9900;
}  

</style>

deck.tab.inactive.background = #EEE9E9
deck.tab.active.background = #FF9900

Aqui estão informações sobre os diferentes processos a serem seguidos por todas as equipes de suporte da TOTVS CRM.

¶ - ÍNDICE

    <ul><strong>
        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_1"><font color=#000000>1 - PROCESSO DE ATENDIMENTO</font></a></span>
            <ul>
                <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_1"><font color=#000000>1.1 - Processo de Atendimento.</font></a></span></li>
                    <ul>
                        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_1"><font color=#000000>1.1.1 - Processo de Atendimento.</font></a></span></li>
                        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_1"><font color=#000000>1.1.2 - Processo de Atendimento | Estrutura do atendimento de tickets.</font></a></span></li>
                        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_1"><font color=#000000>1.1.3 - Processo de Atendimento | Estrutura de páginas do processo.</font></a></span></li>
                        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_1"><font color=#000000>1.1.4 - Processo de Atendimento | Boas Práticas e Postura Profissional.</font></a></span></li>
                        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_1"><font color=#000000>1.1.5 - Processo de Atendimento | Boas Práticas de Documentação.</font></a></span></li>
                        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_1"><font color=#000000>1.1.6 - Processo de Suporte Integrado.</font></a></span></li>
                        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_1"><font color=#000000>1.1.7 - Processo de Suporte Integrado | Criar Ticket Filho e Aplicar Macro.</font></a></span></li>
                    </ul>
                <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_1"><font color=#000000>1.2 - Home de Processos TOTVS.</font></a></span></li>
                <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_1"><font color=#v000000>1.3 - Zendesk.</font></a></span></li>
                <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_1"><font color=#000000>1.4 - Processo de Priorização de Tickets.</font></a></span></li>
                <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_1"><font color=#000000>1.5 - Ferramenta WSST.</font></a></span></li></br>
            </ul></li>
        
        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_2"><font color=#000000>2 - PROCESSO KCS</font></a></span>
            <ul>
                <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_2"><font color=#000000>2.1 - Processo KCS</font></a></span></li>
                    <ul>
                        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_2"><font color=#000000>2.1.1 - Processo KCS - Knowledge-Centered Support.</font></a></span></li>
                        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_2"><font color=#000000>2.1.2 - Processo KCS | A Metodologia na TOTVS.</font></a></span></li>
                        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_2"><font color=#000000>2.1.3 - Coletânea de principais artigos sobre o processo KCS.</font></a></span></li>
                        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_2"><font color=#000000>2.1.4 - Metodologia e Processo KCS - Base de Conhecimento.</font></a></span></li>
                    </ul>
                <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_2"><font color=#000000>2.2 - Base de conhecimento KCS sobre o produto SFA.</font></a></span></li>
                <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_2"><font color=#000000>2.3 - Base de conhecimento KCS sobre o produto GC.</font></a></span></li>
            </ul></li>
    </strong></ul>

1 - PROCESSO DE ATENDIMENTO

Documentação com a estrutura de páginas do processo de atendimento, fluxos do processo de atendimento, fluxo do processo de suporte integrado boas práticas no atendimento, boas práticas na criação de documentação, instruções de trabalho e assuntos relacionados.

1.1.1 - Processo de Atendimento.

Gráfico com fluxo do processo de atendimento e links com assuntos relacionados.

1.1.2 - Processo de Atendimento | Estrutura do atendimento de tickets.

Artigo com instruções sobre como deve ocorrer o atendimento dos tickets.

Objetivo:

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

1 - Primeira interação.

Considere os itens abaixo:

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.
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.
Certifique que está atuando conforme estratégia da sua equipe em relação ao SLA/Aging.
Revise o preenchimento dos seguintes campos do Ticket: Catálogo, Causa, Release, Formulário.
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.
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:

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.
  
  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 5 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?"
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.
  3. Quando a demanda for transferida e ficar sob responsabilidade de um time que utiliza o Jira (criação de Issue para o time de Serviços ou Produto), o cliente deverá ser informado.

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.

O analista deve sempre ter em mente os processos com instruções em casos de cenários específicos previstos na documentação de processos do SFA.

Instruções gerais de conduta padrão, sobre como proceder nos atendimentos, poderão ser consultadas na documentação Processo de Atendimento | Boas Práticas e Postura Profissional.

O Cliente é a razão de estarmos aqui e por isso deve ser sempre prestado o melhor atendimento com a mais alta qualidade, para que possamos fidelizá-lo e evoluir cada vez mais o nosso NPS.

Boas práticas - Protheus

1.1.3 - Processo de Atendimento | Estrutura de páginas do processo.

Página com a estrutura/árvore de páginas do Processo de Atendimento.

1.1.4 - Processo de Atendimento | Boas Práticas e Postura Profissional.

Documentação com informações sobre boas práticas e postura profissional no atendimento, permitindo que os analistas de atendimento consultem sempre que necessário as dicas e técnicas para realizar um bom atendimento.

1.1.5 - Processo de Atendimento | Boas Práticas de Documentação.

Documentação com informações para auxiliar os analistas a evitar erros gramaticais e utilizar corretamente algumas regras da língua portuguesa para realizar um bom atendimento.

1.1.6 - Processo de Suporte Integrado.

Gráfico com fluxo do processo de suporte integrado (Zendesk → Jira / Zendesk → Cloud ) e links com assuntos relacionados.

1.1.7 - Processo de Suporte Integrado | Criar Ticket Filho e Aplicar Macro.

Processo com instruções para criação de tickets filho e envio para os times Cloud.

Boas práticas - Protheus

Página principal com todas as informações sobre os processos de atendimento, desenvolvimento e demais processos relacionados.

Tabela com informações que envolvem o processo de atendimento e como os recursos da ferramenta Zendesk devem ser utilizados de acordo com cada necessidade.

INSTRUÇÃO DE TRABALHO

DESCRIÇÃO

Manual Zendesk.

Documento que contém alguns dos procedimentos necessários para utilização da ferramenta de atendimento Zendesk.

EC - ZEN - Como acessar o Zendesk - Agente.

Artigo com instruções sobre como acessar o Zendesk.

EC - ZEN - Funcionalidade do aplicativo Quickie.

Artigo com informações sobre a funcionalidade do aplicativo Quickie (localizado no canto superior direito da ferramenta Zendesk).

EC - ZEN - Como incluir comentários em tickets?

Artigo com informações sobre como incluir comentários em tickets.

EC - ZEN - Quais os status de um ticket?

Artigo com informações sobre quais são e quando utilizar cada status.

EC - TOTVS Minha Senha - Envio de senha - Interno.

Artigo com instruções sobre como compartilhar senhas de maneira segura com base na LGPD (Lei Geral de Proteção de Dados).

EC - ZEN - Prazo de SLA de Atendimento.

Artigo com informações sobre os prazos de SLA de atendimento.

EC - ZEN - Como identificar clientes com suporte bloqueado?

Artigo com instruções sobre como identificar clientes com suporte bloqueado.

EC - ZEN - Campo Impacto no ticket.

Artigo com informações sobre o campo Impacto no ticket.

EC - ZEN - Finalidade do FCR.

Artigo com informações sobre a finalidade do FCR (First Call Resolution ou Resolução no Primeiro Contato).

EC - ZEN - Visualizar Hierarquia de Atendimento - Ticket.

Artigo com instruções sobre como Visualizar Hierarquia de Atendimento de um grupo de atendimento em um ticket.

EC - ZEN - Status dos tickets - Zendesk x Portal do Cliente.

Artigo que correlaciona os status dos tickets no Zendesk com o mesmos status no Portal do cliente.

EC - ZEN - Entender o SLA através dos Eventos do ticket.

Artigo com informações sobre como consultar a contabilização do SLA de um ticket..

EC - Portal do Consultor - Solicitar Priorização de Ticket.

Artigo com instruções sobre como solicitar prioridade em um ticket utilizando o portal do consultor (para quem não possui acesso ao Zendesk).

EC - ZEN - Pausa do SLA no ticket.

Artigo com informações sobre quando ocorre a pausa do SLA de um ticket.

EC - ZEN - Campos Causa e Classificação no ticket.

Artigo com descritivo sobre a finalidade e como utilizar os campos causa e classificação.

EC - ZEN - Visualização (Criação e Alterações).

Artigo com instruções sobre como criar uma visualização no Zendesk.

EC - ZEN - Abertura de Ticket manualmente em nome do cliente pelo Zendesk.

Artigo com instruções sobre como registrar um ticket manualmente em nome do cliente no Zendesk.

Instrução de Trabalho - Quando transferir ou compartilhar um ticket?

Instrução com descritivo de quando transferir ou compartilhar um ticket.

EC - ZEN - Como utilizar a transferência de ticket.

Artigo com informações sobre quando e como transferir um ticket.

EC - ZEN - Como utilizar o aplicativo de compartilhamento de tickets.

Artigo com instruções sobre como quando e como utilizar o aplicativo de compartilhamento de tickets.

EC - Zendesk - Fusão de Tickets.

Artigo com descritivo de como utilizar a opção de fundir tickets na ferramenta de atendimento (Atenção ao utilizar este recurso, somente deverão ser fundidos tickets da mesma organização).

EC - ZEN - Quando o cliente é Cloud.

Artigo com instruções sobre como identificar no Zendesk se o cliente possui ambiente hospedado em Cloud.

EC - ZEN - Procedimento para contatos sem organização.

Artigo com instruções sobre como proceder quando o suporte identifica tickets sem vínculo com organização.

EC - ZEN - Solicitante sem vínculo com organização.

Artigo com instruções sobre como proceder quando o solicitante do ticket está sem organização associada.

EC - ZEN - Retorno dos Clientes por E-mail não Registrado.

Artigo com informações sobre como proceder quando um cliente responde um ticket por e-mail e sua resposta não fica registrada no mesmo.

EC - ZEN - Como abrir uma solicitação, para prosseguir com atendimento de ticket fechado?

Artigo com informações sobre como abrir um ticket de acompanhamento.

EC - ZEN - Prazo de alteração automática de status do ticket pendente com o cliente.

Artigo com informações sobre a automação que altera automaticamente o status dos tickets pendentes com o cliente.

EC - ZEN - Atualização em massa de tickets.

Artigo com informações sobre como realizar atualizações em múltiplos tickets ao mesmo tempo (Atenção ao utilizar este recurso, seu uso indevido poderá acarretar em alterações indesejadas, em caso de duvidas contate o seu líder).

EC - Zendesk - Aplicação de Macro para equipe Manutenção.

Artigo com descritivo de como utilizar a Macro O3 | Transferência Manutenção.

EC - ZEN - Aplicação de Macro para Manutenção Associação.

Artigo com descritivo de como utilizar a Macro O3 | Transferência Manutenção - Associação.

EC - ZEN - Aplicação de Macro Apoio Manutenção.

Artigo com descritivo de como utilizar a Macro Apoio Manutenção.

EC - ZEN - Como gerar uma issue de Rejeição Manutenção.

Artigo com instruções sobre como gerar um Issue do tipo Rejeição Manutenção.

Tickets com Issue Vinculadas.

Artigo com informações sobre quando é possível resolver um ticket que possui um Issue vinculado.

EC - ZEN - Tags Aplicadas nas Macros Padrões de Transferência.

Artigo com informações sobre algumas tags aplicadas nos tickets com as macros de transferência para os times Jira.

EC - Jira - Erros no Processos Gerando Impacto Para o Cliente.

Artigo com informações sobre falhas comuns de processo e seus impactos para o cliente.

Processo e Ferramenta de Atendimento .

Atendimento - Base de Conhecimento.

Chat - Atendimento.

Metodologia e Processo KCS - Base de Conhecimento.

Macros Processo de Atendimento.

Jira Service Management.

Catálogo de Serviços.

Suporte RH Protheus - Procedimentos e Ferramentas do Atendimento (Apenas KCS Interno).

Base de Conhecimento - Interna Eng Corp Atendimento.

Template KCS.

Página com listas de artigos KCS sobre processos, separadas por temas.

Boas práticas - Protheus

Objetivo:

Ter visibilidade dos canais que solicitam prioridade em tickets, para que possamos mensurar a quantidade de solicitações e realizar atividades importantes para retenção, instrução e direcionando aos nossos clientes e aos canais que solicitam prioridade.

1 - Quem pode solicitar prioridade?

Qualquer pessoa poderá solicitar prioridade nos tickets (inclusive o cliente), no entanto, somente um a pessoa com acesso ao Zendesk conseguirá aplicar as alterações necessárias para que o processo seja aplicado corretamente. Clientes do Suporte Padrão podem realizar suas solicitações de prioridade ao analista de suporte ou diretamente por mensagem no ticket, os clientes do Suporte Prime podem realizar suas solicitações também ao time de CS. Caso o cliente solicite prioridade via nota em um ticket, os ajustes aplicáveis no Zendesk (mencionados nos itens 1.2 e 1.7), deverão ser realizados pelo agente responsável (no campo atribuído).

1.1 - Motivo da priorização, o que devo fazer?

A solicitação de prioridade pode vir de diversos canais (conforme abaixo). Um agente com acesso ao Zendesk, ao receber uma solicitação de prioridade ou identificar que um ticket deva ser priorizado, os motivos da tabela abaixo devem ser considerados:

MOTIVO DE PRIORIZAÇÃO	QUANDO USAR	SUPORTE USA?	GESTÃO SOBREPÕE	TM SOBREPÕE	CS SOBREPÕE
Cliente crítico	Clientes acompanhados pelo PDCA e farol vermelho	SIM	SIM	SIM	SIM
Entrega Fiscal	Priorização para que o cliente cumpra o prazo de entrega de obrigações fiscais	SIM	SIM	SIM	SIM
Franquia	Unidade/canal de venda solicitou prioridade por necessidade estratégica ou retenção de Churn	SIM	Particularidade 1.4
Gestão	Houve a solicitação direta da Gestão Prime para priorização do atendimento	SIM	Particularidade 1.4
Ouvidoria	Categorização pela área da Ouvidoria - Acompanha interação interna ao suporte	Ouvidoria	NÃO	NÃO	NÃO
Produção parada	Ação imediata - Cliente sem contorno de solução	SIM	SIM	SIM	SIM
Projeto	Projeto solicita priorização para andamento no projeto ou prazo de entrega e Go Live	SIM	SIM	SIM	SIM
Go Live	Utilização quando o item é impeditivo para o Go Live	SIM	SIM	SIM	SIM
Processo	É incluído automaticamente na ferramenta por conta da criticidade do ticket	Automatico Zendesk	SIM	SIM	SIM
SPOC Light	SPOC Light para clientes que contrataram o acompanhamento	SIM	NÃO	NÃO	CS
SPOC/CS	Houve acionamento por parte do cliente onde o ticket é crítico ou já se encontra com prazo de SLA comprometido	SIM	Particularidade 1.4
Ticket manager	Ticket manager solicitando priorização. Acompanha os clientes em Projeto (Futuro Prime, estratégicos e em crise)	SIM	Particularidade 1.4

Os motivos serão modificados (quando estiver como “processo” por exemplo) ao serem acionados pelo time de CS para solicitar prioridade em um atendimento específico. Quando o ticket não estiver priorizado deve ser incluído priorizado “sim” e o motivo da solicitação levando em consideração o quadro acima. A hierarquia de sobreposição dos motivos se dá da direita para a esquerda (gestão se sobrepõe à suporte, TM se sobrepõe à gestão e CS se sobrepõe à TM). Em outras palavras, se um gestor adiciona um motivo e outra orientação de priorização vier do CS (por exemplo), o ticket será priorizado com o novo motivo indicado por CS.

1.2 - Campo do Zendesk

O campo "Solicitação Priorizada?" (indicado abaixo) deve ser marcado como "Sim" para que os demais campos (Motivo da priorização, Data Priorização e Detalhamento) sejam disponibilizados e então preenchidos. Todos estes campos são de preenchimento obrigatório.

Linha Microsiga Protheus > Boas Práticas no Atendimento Humanizado > image2022-3-16_16-2-38.png

Observação: Sem a classificação correta não será possível mensurar os clientes que mais solicitam prioridade, e ou os clientes que acionam a gestão para solicitar apoio. A ideia é entender o motivo de um cliente solicitar muitas prioridades, por exemplo (por que ele não pode esperar o atendimento do SLA? Ele pede prioridade em casos realmente críticos ou virou cultural do cliente? Se o cliente possui muitos problemas e por este motivo solicita diversas prioridades, como podemos ajudá-lo na operação?).

Um ticket marcado como priorizado não poderá perder o status de priorizado. No entanto existem casos onde a questão crítica foi solucionada, por uma ação de contorno por exemplo, mas ainda há necessidade de investigação da causa raiz (que pode estar relacionada a outro tema). Para estes casos, o ticket priorizado será encerrado, uma vez que a situação crítica já foi resolvida, e um novo ticket aberto para investigação desta causa raiz. Ao resolver o ticket, o cliente deverá ser informado sobre o número do ticket relacionado a esta nova investigação.

Particularidades.

1.3 - SPOC Light.
O SPOC Light é uma modalidade diferente de contratação para o cliente do Padrão. Ele pode aderir esta modalidade para que seja um canal que vai solicitar prioridade caso ele precise de apoio internamente. Para esta priorização é necessário que, quando o SPOC Light solicitar prioridade em um ticket seja incluído no Zendesk para que possamos contabilizar as vezes que o cliente solicitou esse apoio pois, nesta modalidade existe um baseline de tickets em que o cliente pode solicitar apoio mensalmente.

1.4 - Ticket priorizado com motivo existente/classificado anteriormente.
O CS/TM não sobrepõe a Gestão (quando o ticket estiver classificado com este motivo no priorizado “sim” anteriormente) assim como, a gestão também não deve sobrepor a priorização do CS/TM, para que possamos avaliar a quantidade de solicitações de priorizações de cada canal de “origem”. A mesma regra acima vale para o motivo “Franquia”.

1.5 - Ouvidoria.
Nenhum canal/motivo irá sobrepor a ouvidoria.

Notificações.

1.6 - Notificação de priorização nos grupos de chat (somente para times do SFA).

Ao priorizar um ticket no Zendesk, o grupo de chat de prioridade deve ser notificado para melhorar a visibilidade e assegurar que as ações necessárias serão adotadas. As notificações de cada caso deverão ser realizadas no respectivo grupo de chat, marcando/alertando o respectivo ponto focal de priorizações de cada equipe ao qual o ticket está atribuído. O agente deverá avaliar qual é o grupo responsável no ticket, verificar neste artigo o nome da pessoa que está como ponto focal da equipe em questão (esta informação poderá mudar sem prévio aviso) e enviar mensagem no respectivo grupo, marcando/alertando a pessoa que consta como ponto focal.

Veja abaixo, a lista de pontos focais por grupos de chat e por equipes:

Priorização de chamados Suporte SFA (para tickets com as equipes de versão e integração devem ser notificados também neste grupo, para este grupo de suporte, o líder de cada equipe também deverá ser marcado):

TCRM SFA - Atendimento | Geral - Usuário desconhecido (matheus.kamer) - Erlan Henrique Gibowski

TCRM SFA - Atendimento | JBS - Usuário desconhecido (graciele.luhm) - Erlan Henrique Gibowski

TCRM SFA - Aplicação Customizada - Lucas Geovani Basse - Usuário desconhecido (rodrigo.rigo) - Usuário desconhecido (renato.sbarbosa)

TCRM SFA - Aplicação Standard - Izael Portela do Carmo - Usuário desconhecido (renato.sbarbosa)

TCRM SFA - Infra | BD | Sync - Leonardo Drzenicki - Murilo Gatto

TCRM SFA - Qi.on Coletor - Usuário desconhecido (joao.mario) - Murilo Gatto

TCRM SFA - B2B - Usuário desconhecido (patrick.juscelino) - Usuário desconhecido (renato.sbarbosa)

TOTVS CRM SFA Sustentação Integração - Anderson Lucas Raach - Usuário desconhecido (f.martins)

TOTVS CRM SFA Sustentação Aplicação (Versão) - Victor Uchoa Tavares - Murilo Gatto

Prioridades de desenvolvimento:

TOTVS CRM SFA Sustentação Aplicação (Dev) - Weslei Patrik de Oliveira

Prioridades BI:

TOTVS CRM SFA Sustentação Integração (tickets de BI) - Usuário desconhecido (leandro.machado)

Observação: Caso o agente que veja/receba a solicitação de prioridade não possua acesso ao respectivo grupo de chat de prioridades, o mesmo deve comunicar seu líder de equipe para que este realize a notificação de acordo com este processo.

1.7 - Solicitações de priorização de tickets que possuem Issue no Jira.

Após realizar os ajustes nos campos de priorização no Zendesk (descrito no item 1.2) é necessário também realizar a notificação para o Jira, conforme instruções abaixo:

Na ferramenta Jira, clique no botão notificar.

Linha Microsiga Protheus > Boas Práticas no Atendimento Humanizado > image2021-12-15_11-41-55.png

Insira as informações relevantes à solicitação de priorização e clique no botão "Notificar".

Linha Microsiga Protheus > Boas Práticas no Atendimento Humanizado > image2021-12-15_11-44-13.png

OBS: Se um ticket já priorizado gerar uma Issue, o Zendesk já fará esse processo. Portanto, se o ticket gerar uma Issue, a mesma irá conter o campo priorizado.

2 - Tickets priorizados pela ouvidoria.

Existem casos quando o cliente entra em contato com o time de ouvidoria da TOTVS a respeito de um ticket específico, nestes casos, o time de ouvidoria pode realizar a priorização do caso com o motivo Ouvidoria (conforme tabela do item 1.1 deste artigo).

O time de ouvidoria deve identificar o cenário de acordo com uma das situações:

O ticket está sob responsabilidade do time de suporte;
O ticket possui Issue criado e está sob responsabilidade de um dos times Jira.

2.1 - O ticket possui Issue criado e está sob responsabilidade de um dos times Jira.

O time da Ouvidoria faz o contato com o time de desenvolvimento diretamente via e-mail, sem necessariamente envolver o time de suporte ou realizar ações no ticket.

2.2 - O ticket está sob responsabilidade do time de suporte.

O time de Ouvidoria deve realizar os seguintes passos:

Atribuir o ticket em questão ao líder do respectivo time de atendimento;
Preencher o campo "Solicitação Priorizada?" como Sim;
Preencher o campo "Motivo da Priorização" como Ouvidoria;
Preencher o campo "Data da Priorização" com a data da priorização e o nome do membro do time de Ouvidoria;
Preencher o campo "Detalhamento" com a data da priorização e o nome do membro do time de Ouvidoria;
Inserir uma observação interna no ticket informando o motivo do acionamento junto à Ouvidoria.

A partir deste momento, o time de suporte tem até 24 horas (um dia útil) para interagir publicamente no ticket, seja indicando a solução do problema, solicitando informações para análise, indicando abertura de Issue ao desenvolvimento, ou até mesmo informando uma previsão de retorno ao cliente. Caso não ocorra o retorno dentro deste prazo o ticket será de escalado e atribuindo ao coordenador, que por sua vez tem o mesmo prazo do primeiro acionamento (24 horas). O ticket deve continuar a ser escalado aos níveis superiores, seguindo a mesma lógica deste processo, até que o cliente receba um retorno.

Controle, visibilidade e monitoramento.

3 - Controle de tickets priorizados.

O controle dos itens priorizados deverá ser realizado pelo Zendesk/Jira, utilizando a ferramenta de visualizações, não sendo sendo obrigatório o preenchimento de planilhas.

No item 3.4 mais abaixo, poderão ver instruções detalhadas sobre a criação da visualização para o monitoramento dos tickets priorizados.

3.1 - Campo Data controle.

O campo data controle é utilizado por agentes com acesso ao Zendesk e deverá obrigatoriamente ser preenchido sempre que alguma data de alguma ação for prometida/acordada ao/com cliente. Desta forma, poderemos monitorar se nossos prazos estão sendo cumpridos, evitando eventuais insatisfações em decorrência de descumprimentos.

Linha Microsiga Protheus > Boas Práticas no Atendimento Humanizado > image2021-12-16_17-28-14.png

3.2 - Campo Data (acordo cliente).

O campo Data (acordo cliente) é utilizado para exibir as datas e prazos para as entregas acordadas entre equipes que utilizam a ferramenta Jira e o cliente. A informação da data é registrada na Issue, conforme processo já vigente para usuários Jira, e é replicada para este campo Data (acordo cliente). É importante seu monitoramento e acompanhamento para que possamos saber se os prazos acordados estão sendo cumpridos, evitando eventuais insatisfações.

3.3 - Campo Data Priorização.

Este campo, de preenchimento obrigatório, deve ser utilizado para informar a data de quando o ticket foi priorizado. Desta forma será possível monitorar o tempo de resolução do ticket desde o momento da sua priorização até a sua resolução.

3.4 - Criação de visualização no Zendesk para monitoramento e acompanhamento dos tickets priorizados.

Para que os tickets priorizados não saiam do nosso "radar", uma visualização deve ser criada para que possa ser possível monitorá-los.

Segue abaixo instruções de sugestão de criação desta visualização:

Nas opções de visualizações, clique na opção "Adicionar Visualização".

Preencha os campos de título e descrição.

No campo "Condições", insira conforme abaixo.

Linha Microsiga Protheus > Boas Práticas no Atendimento Humanizado > image2021-12-15_12-8-59.png

Conforme indicado acima, aplique o filtro por grupo(s) monitorado(s).

Em "Opções de formatação", é importante adicionar os campos Próxima violação de SLA, Data Priorização, Data controle, Data (acordo cliente), Motivo da priorização e Detalhamento.

Linha Microsiga Protheus > Boas Práticas no Atendimento Humanizado > image2022-3-16_16-22-45.png

Em "Agrupar por" e "Ordenar por", é sugerido ordenar pela próxima violação de SLA.

Linha Microsiga Protheus > Boas Práticas no Atendimento Humanizado > image2021-12-15_12-15-23.png

4.0 - Fluxograma do processo.

Linha Microsiga Protheus > Boas Práticas no Atendimento Humanizado > Cópia de Fluxo prioridades (2).jpeg

Boas práticas - Protheus

O que é o WSST?

O WSST é uma aplicação de uso interno, desenvolvida pela própria empresa, sendo uma das ferramentas utilizadas pelos analistas e desenvolvedores para realizar conexões com os servidores dos clientes. Lá estarão implementadas as soluções fornecidas pela TOTVS. O acesso aos mesmos será necessário para que as questões reportadas pelos nossos clientes possam ser investigadas, tratadas e resolvidas. Abaixo está a documentação, criada pela equipe de produto, com instruções sobre sua instalação e utilização.

Ferramenta WSST.

Boas práticas - Protheus

2 - PROCESSO KCS

Tabela com informações que envolvem o processo KCS e como os recursos da ferramenta Zendesk devem ser utilizados de acordo com cada necessidade.

INSTRUÇÃO DE TRABALHO

DESCRIÇÃO

2.1.1 - Processo KCS - Knowledge-Centered Support.

Página onde está descrito o fluxo do processo KCS.

2.1.2 - Processo KCS | A Metodologia na TOTVS.

Página com informações sobre a metodologia KCS.

2.1.3 - Coletânea de principais artigos sobre o processo KCS.

Coletânea com os principais artigos sobre diferentes temas e ações realizadas no processo KCS.

Título do artigo.	Descrição do conteúdo.
EC - KCS - Treinamento / Vídeos do processo e ferramenta.	Artigo com informações sobre como acessar o treinamento sobre o processo KCS na Universidade TOTVS.
EC - KCS - O que pode ser incluído no Artigo.	Artigo com informações sobre o que pode ser incluído em um artigo.
EC - KCS - Quais são os objetivos do KCS.	Artigo com informações sobre os objetivos do KCS.
EC - KCS - Competências KCS e seus direitos e deveres.	Artigo que explica a função de cada papel dentro do processo KCS (KCS I, KCS II, KCS III, e etc.)
EC - Pesquisar documentação na Busca Unificada	Artigo com informações sobre como pesquisar documentação pela Busca Unificada (fora do Zendesk).
EC - KCS - Criar Artigo.	Artigo que detalha o processo de criação de um artigo.
EC - KCS – Criar artigo pelo app Knowledge Capture.	Artigo com instruções sobre como criar artigos por meio do aplicativo Knowledge Capture.
EC - KCS - Melhores práticas para criar um Artigo.	Artigo com informações sobre as melhores práticas para criar um artigo KCS.
Template \| Padrão de Escrita de Artigos.	Documento com informações sobre o padrão de criação de artigos.
EC - KCS - Padrões de template para criar Artigo na Central de Atendimento.	Artigo com informações sobre os padrões de template para criar um artigo.
EC - KCS - Inclui uma macro incorretamente como devo proceder antes de salvar o ticket.	Artigo com orientações sobre como proceder quando uma macro incorreta é aplicada.
EC - KCS - Alterar seção do artigo.	Artigo com instruções sobre como alterar a seção de um artigo.
EC - KCS - Artigo duplicado.	Artigo com instruções sobre como proceder quando processo quando o KCS II identifica um artigo duplicado, ou seja, sobre o mesmo assunto.
EC - KCS - Como deve ser incluída imagem no artigo.	Artigo com instruções sobre como deve ser incluída uma imagem no artigo. Observação: Em casos de ajuste de imagem com erro, deve-se remover a imagem antiga, adicionar a nova imagem (conforme este processo) utilizando um novo nome, salvar e publicar novamente o artigo.
EC - KCS - Incluir Vídeo How To no artigo.	Artigo sobre como deve ser incluído um Vídeo How To no Artigo.
EC - KCS - Labels / tags / rótulos obrigatórias em um Artigo.	Artigo sobre quais são as labels / tags / rótulos obrigatórias em um artigo.
EC - KCS - Formatação das labels / tags / rótulos nos artigos.	Artigo com instruções sobre a formatação que deve ser utilizada na label / tag / rótulo obrigatória no artigo KCS.
EC - KCS - Status de um artigo até a sua publicação a Central de Atendimento.	Artigo com informações sobre os os status de um artigo até a sua publicação.
EC - KCS - Revisar e Publicar um Artigo.	Artigo com informações sobre o processo para Revisar e Publicar um artigo (para analistas com acesso de KCS II ou III).
EC - KCS - Processo para ajustar ou realizar uma manutenção em um Artigo.	Artigo com instruções sobre os processos para ajustar ou realizar manutenção em um Artigo criado.

2.1.4 - Metodologia e Processo KCS - Base de Conhecimento.

Página com a listagem de todos os artigos existentes sobre o processo KCS.

Boas práticas - Protheus

Listagem completa de artigos KCS sobre o produto SFA (públicos e internos)
Base de conhecimento KCS sobre o produto SFA - Artigos Públicos.	Listagem completa de KCS públicos sobre o produto SFA.
Base de conhecimento KCS sobre o produto SFA - Artigos Privados.	Listagem completa de KCS Internos sobre o produto SFA.

Boas práticas - Protheus

Listagem completa de artigos KCS sobre o produto GC (públicos e internos)
Base de conhecimento KCS sobre o produto GC - Artigos Públicos.	Listagem completa de KCS públicos sobre o produto GC.
Base de conhecimento KCS sobre o produto GC - Artigos Privados.	Listagem completa de KCS Internos sobre o produto GC.

Boas práticas - Protheus

Aqui estão informações sobre os diferentes processos exclusivos das equipes de suporte do SFA.

¶ - ÍNDICE

    <ul><strong>
        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_1_2"><font color=#000000>1 - PROCESSO DE CRIAÇÃO DE ISSUES</font></a></span></li>
        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_2_2"><font color=#000000>2 - PROCESSO DE ENVIO PARA DEV (SUSTENTAÇÃO APLICAÇÃO), P&D E INTEGRAÇÃO</font></a></span></li>
        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_3_2"><font color=#000000>3 - PROCESSO DE MELHORIA/CUSTOMIZAÇÃO</font></a></span></li>
        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_4_2"><font color=#000000>4 - PROCESSO DE SOLICITAÇÕES RELACIONADAS À ATUALIZAÇÃO DO PROTHEUS</font></a></span></li>
        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_5_2"><font color=#000000>5 - PROCESSO DE SOLICITAÇÃO DE APOIO AO MAESTRO</font></a></span></li>
        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_6_2"><font color=#000000>6 - PROCESSO PARA OCORRÊNCIAS RELACIONADAS AO TOTVS CONNECTOR</font></a></span></li>
        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_7_2"><font color=#000000>7 - INSTRUÇÃO DE TRABALHO - PROCESSO DAS EQUIPES DE ATENDIMENTO DO SUPORTE</font></a></span>
            <ul>
                <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_7_2"><font color=#000000>7.1 - Processo de distribuição de tickets.</font></a></span></li>
                <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_7_2"><font color=#000000>7.2 - Preenchimento da planilha de produtividade.</font></a></span></li>
                <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_7_2"><font color=#000000>7.3 - Processo de execução de tickets priorizados.</font></a></span></li>
            </ul></li></br>
        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_8_2"><font color=#000000>8 - CRITÉRIOS de DoR e DoD - ZENDESK E JIRA - SFA</font></a></span></li>
        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_9_2"><font color=#000000>9 - PÁGINA DE CLIENTES - SFA</font></a></span></li>
    </strong></ul>

1 - PROCESSO DE CRIAÇÃO DE ISSUES

Objetivo:

Fornecer informações claras e bem definidas sobre o processo de criação dos diferentes tipos de Issues na ferramenta Jira, através do Zendesk, fornecendo os detalhes sobre cada um de seus processos de criação.

Introdução.

1.1 - Tipos de Issue.

No fluxo atual previsto para as equipes de suporte do SFA, existem 4 principais tipos de Issues que podem ser criadas, Manutenção, Associação (sub tarefa), Apoio e Epic. Cada tipo de issue será utilizado para um tipo de situação diferente, conforme abaixo:

Manutenção: Utilizado em caso de tickets de onde há algum tipo de erro/inconsistência, onde a equipe do Jira terá de atuar em algum tipo de manutenção. Poderá ser encaminhado para diferentes projetos no Jira.

Associado (Sub-tarefa): Utilizado em casos onde devemos associar o Issue a ser criado à um issue já existente no Jira. Poderá ser encaminhado para diferentes projetos no Jira.

Epic: Utilizado para tickets do tipo tarefa, atualmente dentro do fluxo do SFA, temos previsto apenas enviar este tipo de Issue para a fila TOTVS CRM SFA - Evolução.

Apoio: Utilizado quando uma determinada equipe precisa de algum tipo de ajuda ou informação de alguma equipe que utiliza o Jira. O ticket do Zendesk continuará sob responsabilidade da equipe que solicita o apoio, inclusive para efeitos de SLA.

Apoio - Cliente: Utilizado pela área de Desenvolvimento para demandas de Clientes onde não haverá commit de fonte e não serão executadas as demais etapas do processo padrão.

Rejeição Manutenção: Utilizado nos casos onde foi gerada uma issue de "Manutenção" no qual a equipe do Jira corrigiu e expediu para o Cliente, porém o problema permanece. Nesse caso, deve ser criada uma nova issue do tipo "Rejeição Manutenção".

Observação: Os Issues do tipo Apoio e Apoio - Cliente só devem ser criados em casos específicos e após ter sido solicitado apoio do Maestro. Em caso de dúvidas, contate o seu Líder.

1.2 - Tipos de macros de processo.

São macros criadas pela equipe da engenharia corporativa da TOTVS, de uso obrigatório, com diversas finalidades e funções. Interferem em prazos de SLA, status dos tickets, tags, comunicações com Jira, dente outras funcionalidades. Os tipos de macro de processo a serem utilizadas está associado ao tipo de Issue a ser criado. Abaixo poderão ver os diferentes tipos de macros de processo existentes dentro do fluxo do suporte do SFA:

O3 | Transferência Manutenção: Utilizada para criação de Issues do tipo Manutenção, Rejeição Manutenção e Apoio - Cliente.

O3 | Transferência Manutenção - Associação: Utilizada para criação de Issues do tipo Associação (sub tarefa).

Apoio Manutenção: Utilizada para criação de Issues do tipo Apoio.

Proposta Aprovada: Utilizada para criação de Issues do tipo Epic.

Observação: Existem outros tipos de Issues e macros disponíveis na ferramenta, apenas não foram mencionados neste artigo. Cada exceção deverá ser analisada e tratada individualmente.

1.3 - Macros de texto.

Para além das macros de processo existem macros que foram criadas, a pedido dos gestores das equipes do SFA, para mapear o fluxo de tickets entre as equipes e aplicar um texto padrão com informações essenciais para as respectivas equipes. Estas macros sempre terão em seu título o nome da equipe que irá utilizá-la e informações sobre a equipe no Zendesk ou o projeto no Jira para onde se destinam. Estas também são de uso obrigatório em seus respectivos casos, mas apenas adicionam "tags" de identificação, não tendo efeito ou interferem nos demais recursos do Zendesk. Cada equipe possui suas respectivas macros e sempre deverá haver uma macro para cada equipe para onde o ticket irá se destinar, de acordo com o fluxo de tickets de cada equipe. Abaixo verão os exemplos de macros de texto existentes:

TCRM SFA - Atendimento | Geral::Trâmite para Integração

TCRM SFA - Atendimento | Geral::Trâmite para BI

TCRM SFA - Atendimento | Geral::Trâmite para Infra

TCRM SFA - Atendimento | Geral::Trâmite para B2B

TCRM SFA - Atendimento | Geral::Trâmite para Aplicação Standard

TCRM SFA - Atendimento | Geral::Trâmite para Aplicação Customizada

TCRM SFA - Atendimento | JBS::Trâmite para Integração

TCRM SFA - Atendimento | JBS::Trâmite para BI

TCRM SFA - Atendimento | JBS::Trâmite para Infra

TCRM SFA - Atendimento | JBS::Trâmite para B2B

TCRM SFA - Atendimento | JBS::Trâmite para Aplicação Standard

TCRM SFA - Atendimento | JBS::Trâmite para Aplicação Customizada

TCRM SFA - Aplicação Customizada::Script de serviços - Customização

TCRM SFA - Aplicação Customizada::Trâmite pra Dev

TCRM SFA - Aplicação Customizada::Trâmite para Integração

TCRM SFA - Aplicação Customizada::Trâmite para Infra

TCRM SFA - Aplicação Customizada::Trâmite para BI

TCRM SFA - Aplicação Customizada::Trâmite para a equipe de versão

TCRM SFA - Aplicação Customizada::Trâmite para Atendimento

TCRM SFA - Aplicação Customizada::Trâmite para B2B

TCRM SFA - Aplicação Standard::Script de serviços - Customização

TCRM SFA - Aplicação Standard::Trâmite pra Dev

TCRM SFA - Aplicação Standard::Trâmite para Integração

TCRM SFA - Aplicação Standard::Trâmite para Infra

TCRM SFA - Aplicação Standard::Trâmite para BI

TCRM SFA - Aplicação Standard::Trâmite para a equipe de versão

TCRM SFA - Aplicação Standard::Trâmite para B2B

TCRM SFA - B2B::Trâmite pra Dev

TCRM SFA - B2B::Trâmite para Integração

TCRM SFA - B2B::Trâmite para Infra

TCRM SFA - Infra | BD | Sync::Trâmite para Aplicação Customizada

TCRM SFA - Infra | BD | Sync::Trâmite para Aplicação Standard

TCRM SFA - Infra | BD | Sync::Trâmite para Atendimento

TCRM SFA - Infra | BD | Sync::Trâmite para BI

TCRM SFA - Infra | BD | Sync::Trâmite para Integração

TCRM SFA - Infra | BD | Sync::Trâmite para Dev

TCRM SFA - Qi.on Coletor::Trâmite para Dev

TCRM SFA - Qi.on Coletor::Trâmite para Aplicação Customizada

TCRM SFA - Qi.on Coletor::Trâmite para Aplicação Standard;

1.4 - Projetos Jira.

Ao iniciar a criação de uma Issue na ferramenta Jira existente no Zendesk, a primeira informação solicitada é o projeto para o qual esta Issue se destina. Veja abaixo a lista de projetos no Jira por equipes:

Time de Desenvolvimento (problema na aplicação com fonte customizada): TOTVS CRM SFA - Sustentação Aplicação

Time P&D (problema no produto/integração padrão): TOTVS CRM SFA - P&D

Time de Versão: TOTVS CRM SFA - Sustentação Aplicação

Time de Integração: TOTVS CRM SFA - Sustentação Integração

Time de BI: TOTVS CRM SFA - Sustentação Integração

Time de Produto (serviços de customização): TOTVS CRM SFA - Evolução

1.5 - Tabela de relação entre macro de processo x tipo de Issue.

Linha Microsiga Protheus > Boas Práticas no Atendimento Humanizado > Cópia de Macro x Issue.jpeg

Observação: As macros de texto listadas no item 1.3 deste artigo, que não estão listadas nesta tabela, ainda são de uso obrigatório. Sua aplicação está relacionada à equipe para onde o Ticket/Issue se destina e não necessariamente ao tipo de Issue a ser criado.

Processo de criação.

1.5 - Etapas do processo de criação de Issue.

O fluxo do suporte do SFA foi mapeado para que todas as situações de envio de tickets e criação de Issues estejam previstas. Cada equipe possui seu fluxo e macros de texto próprias de acordo com sua necessidade. Situações de exceção devem ser tratadas individualmente. Uma vez identificada a necessidade de criação de uma issue, seu processo de criação se dá na seguinte ordem:

Aplicação de macro de processo (uma vez aplicada, podemos apagar seu texto no corpo da observação privada gerada no ticket, para que possamos prosseguir com o passo 2).
Aplicação da macro de texto.
Preenchimento dos campos da macro de texto.
Salvar o ticket em espera.
Clicar no botão "Criar Issue", na ferramenta do Jira existente no Zendesk.
Selecionar o projeto para onde o Issue se destina.
Nos campos de preenchimento, colocar no campo Issue type o tipo de Issue a ser criado; no campo "Reporter", o nome do respectivo líder de equipe (ou do Maestro, caso o mesmo tenha validado o envio do Issue); Clicar no botão "Copiar campos do ticket"; o campo "Assignee" deverá sempre estar em branco.
Clicar no botão "Criar Issue".

Obvervações: Para Issues do tipo Epic, será exibido um campo chamado "Epic Name", neste campo, poderá ser adicionado no número do ticket no Zendesk. Caso a demanda se trate de um Issue de Manutenção enviado a uma das filas do time de Produto (P&D, Sustentação Aplicação e Sustentação Integração), o cliente deverá ser notifcado, utilizando a macro: Notificação cliente - Envio para o time de produto.

Para detalhes sobre solicitações de customização/melhoria, veja o item 3 - PROCESSO DE MELHORIA/CUSTOMIZAÇÃO.

1.6 - Criação de Issues por equipes.

Descrito abaixo, poderão ver as etapas do processo de criação de Issue, de acordo com a equipe no Jira para onde se destina:

Time P&D (problema no produto/integração padrão):

Aplicar macro "Notificação cliente - Envio para o time de produto" e salvar o ticket em aberto.

Aplicar macro "O3 | Transferência Manutenção" (apague o texto inserido pela macro para aplicar a próxima macro);

Aplicar macro "Trâmite pra P&D";

Preencher os campos da macro de texto aplicada;

Salvar o ticket em espera;

Clicar no botão "Criar Issue" e selecionar o projeto TOTVS CRM SFA - P&D;

Adicionar no campo "Reporter", o nome do respectivo líder de equipe (ou do Maestro, caso o mesmo tenha validado o envio do Issue);

Campo "Assignee" deve ficar em branco;

Campo "Issue type", deverá ser Manutenção;

Clicar no botão "Copiar campos do ticket" e criar o Issue.

Time de Desenvolvimento (Dev, sustentação, problema):

Aplicar macro "Notificação cliente - Envio para o time de produto" e salvar o ticket em aberto.

Aplicar macro "O3 | Transferência Manutenção" (apague o texto inserido pela macro para aplicar a próxima macro);

Aplicar macro "Trâmite pra Dev";

Preencher os campos da macro de texto aplicada;

Salvar o ticket em espera;

Clicar no botão "Criar Issue" e selecionar o projeto TOTVS CRM SFA - Sustentação Aplicação;

Adicionar no campo "Reporter", o nome do respectivo líder de equipe (ou do Maestro, caso o mesmo tenha validado o envio do Issue);

Campo Assignee deve ficar em branco;

Campo Issue type, deverá ser Manutenção;

Clicar no botão "Copiar campos do ticket" e criar o Issue.

Time de Versão:

Aplicar macro "Notificação cliente - Envio para o time de produto" e salvar o ticket em aberto.

Aplicar macro "O3 | Transferência Manutenção" (apague o texto inserido pela macro para aplicar a próxima macro);

Aplicar macro "Trâmite para a equipe de versão";

Preencher os campos da macro de texto aplicada;

Salvar o ticket em espera;

Clicar no botão "Criar Issue" e selecionar o projeto TOTVS CRM SFA - Sustentação Aplicação;

Adicionar no campo "Reporter", o nome do respectivo líder de equipe (ou do Maestro, caso o mesmo tenha validado o envio do Issue);

Campo Assignee deve ficar em branco;

Campo Issue type, deverá ser Manutenção;

Clicar no botão "Copiar campos do ticket" e criar o Issue.

Time de Integração:

Aplicar macro "Notificação cliente - Envio para o time de produto e salvar o ticket em aberto".

Aplicar macro "O3 | Transferência Manutenção" (apague o texto inserido pela macro para aplicar a próxima macro);

Aplicar macro "Trâmite para Integração";

Preencher os campos da macro de texto aplicada;

Salvar o ticket em espera;

Clicar no botão "Criar Issue" e selecionar o projeto TOTVS CRM SFA - Sustentação Integração;

Adicionar no campo "Reporter", o nome do respectivo líder de equipe (ou do Maestro, caso o mesmo tenha validado o envio do Issue);

Campo Assignee deve ficar em branco;

Campo Issue type, deverá ser Manutenção;

Clicar no botão "Copiar campos do ticket" e criar o Issue.

Time de BI:

Aplicar macro "Notificação cliente - Envio para o time de produto" e salvar o ticket em aberto.

Aplicar macro "O3 | Transferência Manutenção" (apague o texto inserido pela macro para aplicar a próxima macro);

Aplicar macro "Trâmite para BI";

Salvar o ticket em espera;

Clicar no botão "Criar Issue" e selecionar o projeto TOTVS CRM SFA - Sustentação Integração;

Adicionar no campo "Reporter", o nome do respectivo líder de equipe (ou do Maestro, caso o mesmo tenha validado o envio do Issue);

Campo Assignee deve ficar em branco;

Campo Issue type, deverá ser Manutenção;

Clicar no botão "Copiar campos do ticket" e criar o Issue.

Time de Serviços (serviços de customização):

Aplicar macro "Proposta Aprovada" (apague o texto inserido pela macro para aplicar a próxima macro);

Aplicar macro "Script de serviços - Customização";

Preencher os campos da macro de texto aplicada;

Salvar o ticket em espera;

Clicar no botão "Criar Issue" e selecionar o projeto TOTVS CRM SFA - Evolução;

Adicionar no campo "Reporter", o nome do respectivo líder de equipe (ou do Maestro, caso o mesmo tenha validado o envio do Issue);

Campo Assignee deve ficar em branco;

Campo Issue type, deverá ser Epic;

Será exibido o campo Epic Name, de preenchimento obrigatório, adicione o número do ticket Zendesk;

Clicar no botão "Copiar campos do ticket" e criar o Issue.

Importante: Antes de criar Issue para o time de Evolução, é necessário se assegurar de que este é o processo correto a ser seguido.

Para detalhes sobre solicitações de customização/melhoria, veja o item 3 - PROCESSO DE MELHORIA/CUSTOMIZAÇÃO.

1.7 - Tipos de Issue adicionais.

Existem ainda 3 tipos adicionais de Issues (conforme descrito no item 1.1), a lógica de criação segue o mesmo padrão, segue abaixo o processo de aplicação de cada uma delas:

Apoio:

Aplicar macro "Apoio Manutenção" (preencha as informações corretamente para que, a equipe que irá receber o caso, possa identificar com facilidade de que se trata de um pedido de apoio);

Aplicar macro de texto para a equipe de destino;

Preencher os campos da macro de texto aplicada (a equipe ainda precisará ter detalhes sobre o caso para entender a situação e fornecer a ajuda necessária);

Salvar o ticket em espera;

Clicar no botão "Criar Issue" e selecionar o projeto de destino no Jira;

Adicionar no campo "Reporter", o nome do respectivo líder de equipe (ou do Maestro, caso o mesmo tenha validado o envio do Issue);

Campo Assignee deve ficar em branco;

Campo Issue type, deverá ser Apoio;

Clicar no botão "Copiar campos do ticket" e criar o Issue.

Para mais detalhes, leia o artigo EC - ZEN - Aplicação de Macro Apoio Manutenção.

Observação: O Issue do tipo Apoio só deve ser criado em casos específicos e após ter sido solicitado apoio do Maestro, em caso de dúvidas, contate o seu Líder.

Apoio - Cliente:

Aplicar macro "O3 |Transferência Manutenção" (preencha as informações corretamente para que, a equipe que irá receber o caso, possa identificar com facilidade de que se trata de um pedido de apoio);

Aplicar macro de texto para a equipe de destino;

Preencher os campos da macro de texto aplicada (a equipe ainda precisará ter detalhes sobre o caso para entender a situação e fornecer a ajuda necessária);

Salvar o ticket em espera;

Clicar no botão "Criar Issue" e selecionar o projeto de destino no Jira;

Adicionar no campo "Reporter", o nome do respectivo líder de equipe (ou do Maestro, caso o mesmo tenha validado o envio do Issue);

Campo Assignee deve ficar em branco;

Campo Issue type, deverá ser Apoio - Cliente;

Clicar no botão "Copiar campos do ticket" e criar o Issue.

Observação: O Issue do tipo Apoio - Cliente só deve ser criado em casos específicos e após ter sido solicitado apoio do Maestro, em caso de dúvidas, contate o seu Líder.

Rejeição Manutenção:

Aplicar macro "O3 | Transferência Manutenção" (preencha as informações corretamente para que, a equipe que irá receber o caso, possa identificar a razão da reabertura do ticket);

Aplicar macro de texto para a equipe de destino;

Preencher os campos da macro de texto aplicada (a equipe ainda precisará ter detalhes sobre o caso para entender a razão da reabertura);

Salvar o ticket em espera;

Clicar no botão "Criar Issue" e selecionar o projeto de destino no Jira;

Adicionar no campo "Reporter", o nome do respectivo líder de equipe (ou do Maestro, caso o mesmo tenha validado o envio do Issue);

Campo Assignee deve ficar em branco;

Campo Issue type, deverá ser Manutenção;

Clicar no botão "Copiar campos do ticket" e criar o Issue.

Para mais detalhes, leia o artigo EC - ZEN - Como gerar uma issue de Rejeição Manutenção.

Issue Associado (Sub-tarefa):

Aplicar macro "O3 | Transferência Manutenção" - Associação (apague o texto inserido pela macro para aplicar a próxima macro);

Associar o número do ticket de problema à ente novo incidente;

Aplicar macro de texto para a equipe de destino;

Preencher os campos da macro de texto aplicada;

Salvar o ticket em espera;

Clicar no botão "Criar Issue" e selecionar o projeto de destino no Jira;

Adicionar no campo "Reporter", o nome do respectivo líder de equipe (ou do Maestro, caso o mesmo tenha validado o envio do Issue);

Campo Assignee deve ficar em branco;

Campo Issue type, deverá ser Associado (sub tarefa);

Campo Parent, deve ser adicionado o número do Issue de Manutenção já existente no Jira ao qual o caso está relacionado;

Clicar no botão "Copiar campos do ticket" e criar o Issue.

Para mais detalhes, leia o artigo EC - ZEN - Aplicação de Macro para Manutenção Associação.

Boas práticas - Protheus

Linha Microsiga Protheus > Boas Práticas no Atendimento Humanizado > image2022-5-23_17-25-56.png

2 - PROCESSO DE ENVIO PARA DEV (SUSTENTAÇÃO APLICAÇÃO), P&D E INTEGRAÇÃO

Objetivo:

Fornecer instruções claras e bem definidas sobre o processo de tomada de decisão para envios de Issues de Manutenção para os times que cuidam de problemas de integração e/ou aplicação, que utilizam os projetos Jira TOTVS CRM SFA - Sustentação Aplicação, TOTVS CRM SFA - Sustentação Integração e TOTVS CRM SFA - P&D.

1.1 - TOTVS CRM SFA - Sustentação Aplicação.

Este projeto é utilizado pela equipe de produto, lá são tratados problemas (bugs) na aplicação de clientes que possuem código fonte de aplicação customizado.

1.2 - TOTVS CRM SFA - Sustentação Integração.

Este time está ligado à equipe de suporte, que trata de problemas de integração de clientes que possuem código fonte de integração customizado.

1.3 - TOTVS CRM SFA - P&D.

Este projeto é utilizado por outra equipe também pertencente ao time produto, que tratam problemas (bugs) na aplicação e/ou integração de clientes que possuem código fonte padrão (aplicação ou integração).

1.4 - Validação do tipo de fonte (padrão ou customizado).

A validação do tipo de fonte (integração e aplicação) deve ser realizada conforme descrito abaixo:

Acesse o Empodera, busque pelo cadastro do cliente em questão e clique na aba de campos customizados.

A informação sobre o código fonte de integração e aplicação deverá ser exibida conforme as imagens abaixo:

Linha Microsiga Protheus > Boas Práticas no Atendimento Humanizado > image2021-12-28_14-59-2.png

Observação: Caso o campo necessário não esteja preenchido (conforme imagens acima) contate o seu líder. Para acessar o Empodera, clique aqui.

1.5 - Passos da validação

A lógica de validação segue a seguinte ordem:

Identificar se o problema é de integração ou aplicação;
Validar se o código fonte em questão é padrão ou customizado;
Selecionar o respectivo projeto Jira, conforme descrito do item 1.1 ao 1.3.

Para instruções sobre o processo de criação de Issue para cada projeto, veja o item 1 - PROCESSO DE CRIAÇÃO DE ISSUES.

Boas práticas - Protheus

3 - PROCESSO DE MELHORIA/CUSTOMIZAÇÃO

Objetivo:

Fornecer instruções claras sobre como se dá o processo e dar elementos concretos para tomada de decisões de forma assertiva, ao tratar de solicitações de mudança/melhoria no SFA.

1 - Identificação do cliente.

Primeiro elemento que devemos observar, é se a organização ao qual o ticket está associado, se trata de um cliente standard ou um cliente customizado. Esta informação poderá ser facilmente verificada através das tags associadas ao cadastro da organização no Zendesk, conforme exemplo abaixo:

Linha Microsiga Protheus > Boas Práticas no Atendimento Humanizado > image2021-12-20_15-5-51.png

Esta informação também poderá ser encontrada no cadastro do cliente no Empodera, conforme imagem abaixo:

Linha Microsiga Protheus > Boas Práticas no Atendimento Humanizado > image2021-12-23_10-52-51.png

Para acessar o Empodera, clique aqui. Caso não possua acesso ao Empodera, contate a sua liderança.

Clientes Standard.

1.1 - Sugestões de melhoria vindas de clientes standard.

Caso algum cliente standard abra um ticket solicitando/enviando alguma sugestão de melhoria/customização no SFA, devemos aplicar a macro "Resolver tickets de melhorias" e resolver o ticket. Na macro há toda informação relevante para que o cliente possa enviar sua sugestão.

Foi criado também um KCS para ser anexado ao ticket, contendo as mesmas informações fornecidas pela macro acima citada:

Cross Segmentos - SFA - Sugestão de melhoria - Como enviar uma sugestão de melhoria.

Clientes Customizados.

1.2 - Sugestões de melhoria, vindas de clientes customizados, sem alteração de código fonte de aplicação e/ou integração.

Para os serviços onde não haverá alteração em código fonte de aplicação nem de integração, resolvemos o ticket orientando o cliente a enviar um e-mail para [email protected], para que ele possa enviar sua solicitação. Precisamos deixá-lo ciente também que há custos associados, caso queira de fato prosseguir e encaminhar sua solicitação para o e-mail informado.

1.3 - Sugestões de melhoria, vindas de clientes customizados, com alteração de código fonte de aplicação e/ou integração.

Todo serviço de customização onde haverá alguma alteração em código fonte de aplicação e/ou integração, precisa ter uma Issue criada e enviada para a fila TOTVS CRM SFA - Evolução, no Jira. Esta solicitação será um serviço, que implicará em custos para o cliente, enviada para a equipe de produto.

Critérios.

1.4 - Critérios de avaliação se a solicitação poderá ser atendida.

Para que possamos saber se a solicitação do cliente pode ou não ser efetivamente atendida pela equipe de produto, precisamos consultar a tabela Playbook TOTVS CRM Automação da Força de Vendas. Nesta tabela poderemos identificar quais módulos da aplicação são passíveis de customização. Devemos identificar em qual módulo se encontra o recurso que o cliente deseja customizar e identificar na tabela se este recurso pode ou não ser customizado.

1.5 - Caso o recurso não possa ser customizado.

Caso o recurso não possa ser customizado (de acordo com o item 1.4), devemos informar o cliente que este módulo não é passível de customização e seguir os passos descritos no item 1.1 deste artigo. É necessário também informar que o envio da sugestão de melhoria desta forma é apenas para este caso específico, uma vez que as solicitações de customização devem ser analisadas individualmente.

Observação: Clientes customizados não recebem atualizações do produto padrão, mesmo que enviem uma sugestão de melhoria e a mesma seja incorporada no produto padrão, estes clientes não irão recebê-la. Para que os clientes customizados possam receber as atualizações do produto padrão é necessário contratar um serviço pra migrar a versão SFA.

1.6 - Caso o recurso possa ser customizado.

Caso identifiquemos que a solicitação do cliente poderá ser atendida (de acordo com o item 1.4), precisamos informar que o serviço desejado acarretará em custos. Aplique a macro chamada "Aceite de custos", o cliente precisa nos confirmar, por escrito no ticket, se está de acordo e ciente de que este será um serviço pago. O texto da macro informa que o serviço desejado terá custos, pede o aceite e informa que, após o aceite, o ticket será enviado para a equipe responsável, que realizará o levantamento dos efetivos custos do serviço.

Importante: O aceite por parte do cliente precisar constar de forma clara e por escrito no ticket, somente após esta confirmação, poderemos então seguir o processo de criação de Issue para a fila de evolução. Caso o cliente informe que não está de acordo ou não deseja pagar os custos do serviço, o ticket deverá ser resolvido.

Para informações sobre como criar Issue para o time de Evolução, veja o item 1 - PROCESSO DE CRIAÇÃO DE ISSUES.

Boas práticas - Protheus

Linha Microsiga Protheus > Boas Práticas no Atendimento Humanizado > _Fluxograma Melhoria_Customização (4).jpeg

4 - PROCESSO DE SOLICITAÇÕES RELACIONADAS À ATUALIZAÇÃO DO PROTHEUS

Objetivo:

Facilitar a identificação e agilizar o atendimento de solicitações quando o cliente informa que haverá uma atualização na versão do Protheus para uma versão mais recente (caso de exemplo, ticket 13309465).

1 - Recebimento da solicitação.

Ao receber um ticket relacionado, a equipe de atendimento deverá identificar primeiramente para qual versão do Protheus o cliente deseja realizar a atualização.

Existem dois cenários principais que serão descritos neste artigo:

Atualização para a versão 33 - Descrito no item 2 e sub itens.

Atualização para outras versões que não a 33 - Descrito no item 3 e sub itens.

O time de atendimento deverá identificar em qual cenário se enquadra a solicitação e seguir conforme as instruções a seguir.

2 - Atualização para a versão 33.

O time de atendimento deve coletar as informações pertinentes sobre o caso (é indispensável que a informação sobre a versão de atualização conste no trâmite de envio para os times Jira) e realizar a abertura de dois Issues do tipo Apoio (no mesmo ticket Zendesk), um para o projeto TOTVS CRM SFA - Sustentação Aplicação e outro para TOTVS CRM SFA - Sustentação Integração.

Cada equipe realizará as validações pertinentes e identificar se será necessário realizar alguma mudança.

Para informações sobre o processo de criação de Issues, veja o item 1 - PROCESSO DE CRIAÇÃO DE ISSUES.

2.1 - Validações da equipe de Integração.

A equipe de Integração, deverá abrir um ticket com a TOTVS Cascavel, solicitando o patch do plugin para o cliente, em seguida, deverá identificar se há a necessidade de ajuste na integração (se a integração é antiga, sem o Token). Deverá verificar se, neste cliente, há a necessidade de ajuste para incluir a validação do Token.

Após a análise, o time de integração deverá resolver o Issue informando se há a necessidade de realizar alguma alteração, repassando o patch fornecido pela equipe TOTVS Cascavel e informando detalhes pertinentes sobre o caso (caso haja).

2.2 - Validações da equipe de Aplicação.

O time de aplicação deverá identificar se aplicação do cliente WEB/Mobile acessa o plugin do Protheus sem autenticação no protheus 25 e vai migrar para a protheus 33. Deverá validar também se a aplicação possui cálculo de imposto via plugin sem token.

Após a análise, o time de aplicação deverá resolver o Issue informando se há a necessidade de realizar alguma alteração, fornecendo os detalhes pertinentes (caso haja).

2.3 - Ações da equipe de atendimento após retorno dos times de integração e aplicação.

Quando ambos os Issues de apoio forem resolvidos, o ticket voltará em aberto na fila do agente, o mesmo deverá identificar o retorno de ambos os times e verificar se há a necessidade de realizar algum tipo de alteração. Caso um dos times Jira resolva o Issue de apoio sem que o outro Issue tenha sido também resolvido, salve o ticket com status "Em Espera" e clique no botão "Notificar" do Issue ainda em aberto no Jira. É necessário aguardar o parecer de ambas as equipes para prosseguir com o caso.

Existem 4 resultados possíveis, que serão descritos logo abaixo.

Possíveis situações após o parecer das equipes.

2.4 - Se ambos os times, integração e aplicação, informarem que há necessidade de alteração/customização.

Neste caso, o ticket deverá ser encaminhado para o projeto Jira TOTVS CRM SFA - Evolução, seguindo conforme o processo de solicitação de customização (a partir da etapa de envio da macro "Aceite de Custos").

O agente de atendimento deverá encaminhar para o cliente o patch repassado pela equipe de Integração e aplicar a macro "Aceite de Custos", para que o cliente esteja ciente e de acordo com eventuais custos associados ao serviço, só então a solicitação possa ser enviada para a fila de evolução.

Para informações sobre o processo de criação de Issues, veja o item 1 - PROCESSO DE CRIAÇÃO DE ISSUES.

2.5 - Se houver necessidade de ajuste apenas na integração.

A equipe de atendimento deverá enviar o patch, fornecido pelo time de integração, pro cliente e informar que este serviço de customização da integração terá custos associados (será cobrado um valor fixo de 4 horas para converter a integração e mudar o método de autenticação).

Para passar esta informação ao cliente, o agente do atendimento deverá aplicar a macro "Trâmite padrão de horas (4 horas)" e salvar o ticket como pendente, aguardando o aceite do cliente (o patch deverá ser enviado juntamente com este trâmite).

O aceite do cliente deverá estar por escrito no ticket, caso o cliente esteja de acordo, deverá seguir os passos abaixo:

Alterar o campo "Onda 3 Oficial | Tipo da Solicitação" para Consultoria Técnica (conforme abaixo);

Linha Microsiga Protheus > Boas Práticas no Atendimento Humanizado > image2022-1-12_10-46-4.png

Aplicar macro Proposta Aprovada (apague o texto inserido pela macro para aplicar a próxima macro);

Aplicar macro Script de serviços - Customização;

Validar com o Maestro;

Salvar em espera;

Criar um Issue do tipo Epic para o projeto Jira TOTVS CRM SFA - Evolução (TSFAFSWE), alterando o título do Issue para "Aplicação de Token na Integração Pentaho".

Observação: Caso o cliente não esteja de acordo com os custos associados, o ticket deverá ser resolvido.

2.6 - Se houver necessidade de ajuste apenas na aplicação.

Seguir conforme o item 2.4, sendo que, o título do Issue deve ser alterado para "Aplicação de token no GetImposto WEB e Mobile".

2.7 - Se não houver necessidade de ajuste na integração nem na aplicação.

Enviar o patch para o cliente, informando que não foi mapeada nenhuma necessidade de mudança no SFA. O cliente deverá ser orientado a realizar testes e abrir novo ticket com o suporte caso algum problema ocorra.

Ao enviar o trâmite para o cliente com as informações acima, o ticket deverá ser resolvido.

Foi criado um KCS público para informar os clientes sobre possíveis custos associados à alterações em código fonte da aplicação e/ou integração, este KCS poderá ser anexado nas respostas fornecidas aos clientes nos casos em que se aplicam.

Para mais informações, veja o artigo Cross Segmento - TOTVS CRM SFA - Configuração - Atualizações ERP.

3 - Atualização para outras versões que não a 33 (ex. da versão 23 para a versão 27).

O time de atendimento deve coletar as informações pertinentes sobre o caso e realizar a abertura de um Issue do tipo Apoio, para o projeto TOTVS CRM SFA - Sustentação Integração, repassando para a equipe de integração as informações sobre o caso.

3.1 - Ações da equipe de Integração.

A equipe de Integração, deverá abrir um ticket com a TOTVS Cascavel, solicitando o patch do plugin para o cliente. O Issue deverá ser resolvido quando o patch for recebido, para que seja repassado para a equipe de atendimento, que o fornecerá para o cliente.

3.2 - Ações da equipe do atendimento após conclusão do Issue.

O time de atendimento deverá enviar o patch para o cliente, informando que não foi mapeada nenhuma necessidade de ajuste no SFA. O cliente deverá ser orientado a realizar testes e abrir novo ticket com o suporte caso algum problema ocorra.

Ao enviar o trâmite para o cliente com as informações acima, o ticket deverá ser resolvido.

Caso o cliente solicite que a TOTVS realize os devidos testes em decorrência desta atualização, cada caso deverá ser analisado individualmente. Este tipo de solicitação está sujeito a cobrança de horas de consultoria técnica, o que acarretará em custos para o cliente. Para maiores informações, consulte seu líder.

Boas práticas - Protheus

5 - PROCESSO DE SOLICITAÇÃO DE APOIO AO MAESTRO

Objetivo:

Facilitar e organizar o atendimento oferecido pelo Maestro aos agentes dos times do suporte do SFA, fornecendo informações claras e bem definidas de como realizar a solicitação de apoio em caso de dúvidas sobre questões técnicas e validação de Issues (caso necessário).

1 - Função do Maestro.

O Maestro é uma posição de referência para os agentes que, dentre outras funções e atribuições, possui a função de oferecer apoio aos agentes sobre questões técnicas nas validações dos tickets. O Maestro trabalha em parceria com os líderes das equipes, partilhando algumas funções exercidas pela liderança e responde diretamente ao coordenador do projeto.

2- Quando solicitar o apoio do Maestro?

O apoio do Maestro deve ser solicitado quando são esgotadas todas as possibilidades de análise do caso e não há mais orientação ou direcionamento sobre como avançar na investigação e resolução do ticket. O agente deverá se certificar que realizou todas as validações pertinentes e consultou toda a informação ou documentação disponível sobre o caso, para que só então possa realizar a solicitação de apoio.

O apoio poderá ser solicitado também para a validação de envio de Issues para as equipes Jira, mesmo que este processo não seja obrigatório. Caso o Maestro tenha validado o envio de um Issue, o nome do Maestro deverá ser adicionado no campo "Reporter" no momento da criação do Issue em questão.

Para informações sobre o processo de criação de Issues, veja o item 1 - PROCESSO DE CRIAÇÃO DE ISSUES.

3 - Como realizar uma solicitação de apoio?

A solicitação de apoio deverá ocorrer através de agendamentos realizados na ferramenta de agenda do Google. Todos os agendamentos realizados serão solicitações de agendamento pré-aprovados, que estarão passíveis de análise pelo Maestro, pois podem ser rejeitados ou alterados conforme necessidade e disponibilidade do mesmo. As marcações devem ser feitas com pelo menos 10 minutos de antecedência em relação ao horário agendado e com duração de 15 minutos cada, ocorrendo ao longo de todo o dia. O Maestro irá avaliar cada agendamento e, caso haja necessidade, poderá recusar ou reagendar conforme cada situação.

Antes de realizar o agendamento, é necessário preencher e realizar as validações mencionadas no script disponibilizado na própria agenda. É recomendado adicionar o máximo possível de informações, realizando o preenchimento correto com informações concretas, objetivas e claras. Isto ajudará a tornar o processo de atendimento mais ágil e rápido. Nos casos onde o agente não sabe como proceder para continuar a investigação do ticket, preencha os script com as informações sobre o que já foi validado e informe o qual é a dúvida que impede o avanço no caso.

Para acessar as informações contidas no script e realizar o agendamento com o Maestro, clique aqui.

Importante: Mesmo realizando o agendamento com o Maestro, a responsabilidade do ticket continua sendo do analista ao qual o mesmo está atribuído, ainda sendo necessário realizar as validações pertinentes sobre o caso. Em situações de caráter urgente e que não podem aguardar a disponibilidade da agenda, o agente poderá contatar o Maestro diretamente via chat. É importante ter em mente que o contato via chat deve ser utilizado para casos de exceção e não deve ser utilizado como instrumento corriqueiro de solicitação de apoio, deve ser utilizada preferencialmente a ferramenta de agendamentos para solicitação de apoio. O Maestro irá analisar cada caso e priorizar o apoio conforme a necessidade. Em caso de contatos via chat de caráter não urgente, poderá ser solicitado que o agente realize o agendamento para receber o apoio necessário. Em caso de dúvidas, contate o seu líder imediato.

Observação: Caso a situação alvo do apoio seja mais complexa, e possa demandar mais tempo do que a duração do agendamento, é necessário realizar dois agendamentos (em sequência, se possível). Será necessário o preenchimento do script apenas na primeira agenda quando se tratarem de agendas sequenciais.

É importante mencionar que o Maestro possui outras atribuições para além do apoio aos agentes, uma vez que os agendamentos podem ser realizados ao longo de todo o dia, em alguns momentos será necessário conciliar estas agendas com outras e tarefas inerentes ao cargo. Tendo isso em vista, é necessário estar atento a possíveis realocações de agenda que podem ocorrer sem aviso prévio.

Boas práticas - Protheus

6 - PROCESSO PARA OCORRÊNCIAS RELACIONADAS AO TOTVS CONNECTOR

Objetivo:

Fornecer instruções claras e objetivas, facilitando a identificação dos casos e agilizar o atendimento de tickets relacionados ao produto Connector (sob a perspectiva do suporte do SFA).

1 - Sobre o Connector.

O Connector é uma ferramenta de ETL desenvolvida pela própria Totvs, para integração do ERP com o SFA. Funciona como uma ponte de transferência de informações que recebe, transforma e transmite informações entre ambos. A integração utilizando o Connector substitui a integração utilizando o Pentaho..

Para mais informações sobre o Totvs Connector, clique aqui.

2 - Recepção, identificação e tratamento de solicitações abertas incorretamente pelo cliente.

As ocorrências deverão ser reportadas diretamente ao time de suporte Connector e somente as situações sob o escopo correto serão redirecionadas para o time de suporte do SFA. Todos os tickets de clientes Connector onde for reportado problema de integração entre o ERP e o SFA, que forem abertos diretamente para o time de suporte do SFA, serão redirecionados para o time do suporte Connector. Segue abaixo, instruções das ações necessárias neste cenário:

O time de atendimento do SFA irá primeiramente identificar se o serviço API Builder está ativo, caso não esteja, deverá reiniciá-lo.
Deverá ser solicitado que o cliente refaça os testes após o serviço ser reestabelecido.
O cliente deverá ser informado sobre o canal correto para abertura de tickets diretamente com o time Connector. Em casos futuros, deverá enviar e-mail para [email protected].
Caso a questão persista mesmo com o serviço ativo o ticket deverá ser redirecionado para o time Connector, atribuindo-o ao grupo Vtex - Integrações.

3 - Recepção e tratamento dos tickets abertos conforme o fluxo correto mapeado.

O fluxo normal prevê que as ocorrências sejam reportadas diretamente com a equipe de suporte do Connector, que realizará o primeiro atendimento, as devidas validações e encaminhará para o suporte do SFA os casos que envolvam problemas de integração de informações entre o Connector e a API (SFA). Os tickets deverão ser encaminhados para o grupo TCRM SFA - Atendimento | Geral, contendo as informações abaixo:

Descrição do problema;
Em qual sentido está acontecendo o problema (SFA para o Connector ou do connector para ERP);
Log de erro do diagrama;
URL da API (que o diagrama utiliza para envar/receber dados da API);
Caso o registro já exista no SFA, informar o internalID do registro.

Caso o time do Connector encaminhe um ticket para o time do SFA sem as informações acima, o ticket poderá ser retornado solicitando as informações faltantes. Um vez recebidas todas as informações básicas, o chamado poderá ser validado.

O time de atendimento irá identificar se o serviço está ativo, caso não esteja, deverá reiniciá-lo. A questão persistindo mesmo com o serviço ativo, será criado um Issue para o projeto TCRM SFA - Sustentação Integração, aplicando a macro de texto criada exclusivamente para este processo: "Trâmite para Integração - Connector". A macro de texto deverá ser preenchida conforme as informações repassadas pelo time Connector, adicionando a informação sobre a checagem do status do serviço. O time de integração realizará as devidas validações e investigações necessárias para a resolução da questão.

Para criar Issues relacionados ao casos Connector, ainda deverão ser seguidas as etapas processo de criação de Issues já vigente, observando a aplicação da macro "Trâmite para Integração - Connector".

Para informações sobre o processo de criação de Issues, veja o item 1 - PROCESSO DE CRIAÇÃO DE ISSUES.

Boas práticas - Protheus

7 - INSTRUÇÃO DE TRABALHO - PROCESSO DAS EQUIPES DE ATENDIMENTO DO SUPORTE.

Objetivo:

Proporcionar melhoria nos ofensores de indicadores da equipe, tais como:

Cuidado com criticidades e processo de priorização;
Rodízios para aumento de conhecimento.
Tempo de envio de tickets do grupo responsável (SLA e Aging);
Acompanhamento de tickets pelos analistas (tempo de retorno);
Identificação de casos críticos para operação (Satisfação do cliente);
Adequação do tipo de ticket para analistas especializados (assertividade, tempo de resolução e evolução dos colaboradores);
Controle de metas e progresso assertivo dos analistas.

1 - Sobre o processo.

Um colaborador com senioridade na operação ficará encarregado por avaliar e distribuir os tickets, sem atribuição no grupo, a um responsável. Todo ticket, que estiver atribuído ao grupo, deverá ser validado pelo categorizador e encaminhado a um analista com disponibilidade para atendê-lo ou redirecioná-lo para o devido grupo de atendimento.

Observação: Ainda que os tickets sejam distribuídos de acordo com o conhecimento de cada agente, nem sempre o analista com mais conhecimento sobre o assunto terá disponibilidade para trabalho, fazendo com que o ticket seja redirecionado para outro agente que não tenha tanto conhecimento sobre o tema.

2 - Atendimento do categorizador.

O categorizador deverá monitorar a fila do grupo ao longo do dia. O mesmo realizará atendimentos que são entendidos como rápidos (20 à 30 Min.), para que seja possível manter o monitoramento da fila. Tickets que levam mais tempo para análise deverão ser enviados aos analistas do time, o categorizador deve se concentrar em situações de rápida intervenção, tais como envio como para integração, BI ou outros que não requeiram muito tempo.

3 - Responsabilidade do Analista.

Cada analista será responsável por verificar diariamente os tickets que estão em seu nome, cuidando de retornos, aging, SLA e resolução conforme metas estipuladas. Sempre que necessário, deverá solicitar mais demanda ou então avisar quando está tratando de um caso que não consegue evoluir ou requer priorização, observando sua criticidade e trabalhando com sinergia com o time. Reuniões diárias serão realizadas especificamente para comentar sobre as demandas. Toda alteração de atribuição de tickets deve ser acordada com o líder.

No início da jornada de trabalho, deverá realizar uma triagem dos tickets arruídos em seu nome, considerando os fatores abaixo na seguinte ordem:

Tickets a serem transferidos pra outros times (casos rápidos, sem necessidade de análise complexa);
Tickets que possuem retorno do cliente e precisam de alguma resposta/ação por parte do time de Suporte (manter prazo de até 2 dias para resposta/retorno ao cliente);
Tickets que demandam análise/execução mais complexa, ordenados por prazos de violação de SLA (serão tratados primeiro os tickets que terão o SLA vencido no menor prazo).

Observação: Todos os tickets devem ser visualizados todos os dias, pelo menos uma vez ao dia. Quando não houver possibilidade de oferecer resposta ao cliente dentro do prazo de dois dias, deverá ser deixada uma observação interna informando as razões/contexto do ocorrido.

Importante: Com base nas metas estabelecidas, o líder irá identificar quais tickets possuem indicadores que não estão de acordo com os objetivos e irá estudar, com cada analista individualmente, estratégias para alcançá-los.

4 - Destinos dos tickets.

Estes são os destinos previamente mapeados para envio pelo Categorizador:

Prioridades: Lucas Geovani Basse;
Assa Abloy: Alecio Vinicius Santana Koslowski;
JBS/ LP/ Seara: Usuário desconhecido (marhany.iori);
Integração (Time Jira);
Infraestrutura (Time Zendesk);
Versão (Time Jira);
BI (Time Jira);
Serviços (Time Jira);
Produto sustentação (Time Jira);
Devolução ao time de atendimento (Time Zendesk);
Nome dos analistas do grupo da Squad responsável (para este envio o categorizador deve realizar uma validação da distribuição de demanda atual para dividir a carga de tickets entre o time e também identificar a especialidade de cada analista para atendimento ágil. Estas especialidades serão tratadas em uma segunda fase. As demandas serão distribuídas entre os demais analistas).

5 - Pontos de atenção necessários.

Precisamos ter cautela com esses pontos iniciais para execução do processo, nossa metodologia atual demanda atenção com as seguintes situações:

Número de tickets em fila dos colaboradores (senso de urgência);
Tempo de atendimento do categorizador (disponibilidade para o processo);
Controle de indicadores pela fila do colaborador (Metas);
Controle do ‘Atribuído’ do ticket para distribuição e assertividades do indicadores;
Cuidado com criticidades e processo de priorização;
Rodízios para aumento de conhecimento.

Importante: Este processo descreve uma instrução geral de trabalho, em caso de dúvidas ou para qualquer situação de exceção, contate o seu líder.

Boas práticas - Protheus

Objetivo:

Documentar de forma clara e acessível o tempo gasto em atividades que não envolvem validação e investigação de tickets na ferramenta Zendesk, onde o tempo é registrado na ferramenta de controle de horas.

1 - O que deve ser contabilizado?

Toda e qualquer atividade produtiva realizada deverá ser registrada na planilha de produtividade.

Exemplos de atividades que devem ser contabilizadas:

Reuniões com o cliente;
Reuniões de equipe;
Agendas internas da TOTVS;
Toda e qualquer outra atividade realizada, solicitada pelos líderes e gestores, que não envolva validação e ou investigação de tickets.

2 - Como localizar a planilha?

Ainda que este seja um processo geral e obrigatório de todos os membros do time de Suporte do SFA, as planilhas podem estar separadas por equipes, contate o seu líder para solicitar informações sobre a sua planilha de produtividade.

3 - Como realizar o preenchimento da planilha?

A planilha deverá ser preenchida com informações como:

Data (de quando a tarefa ocorreu);
Hora de Início;
Hora de Término;
Nome do seu líder imediato;
Nome do Analista que exerceu/participou da atividade/tarefa;
Tipo de tarefa;
Duração;
Observações adicionais (caso necessário).

Em caso de dúvidas e/ou informações adicionais necessárias, contate o seu líder.

Boas práticas - Protheus

Objetivo:
Fornecer instruções claras sobre os passos para a tratativa correta dos tickets sinalizados como priorizados.

Passos do processo.

Ao tratar demandas priorizadas, o analista deve seguir os seguintes passos:

1 - Ao receber a notificação do ticket no grupo "Priorização de chamados Suporte SFA", o analista deve primeiramente avaliar se a situação se trata de fato de um caso prioritário. Caso o entendimento seja de que não se trata de uma prioridade, deverá contatar o líder da equipe para discutir o cenário.

2 - Após a análise do item 1, com o entendimento de que se trata de uma prioridade, deve responder que o ticket em questão será adicionado à fila de priorizações.

3 - Deve sempre ser verificar se o ticket atende os padrões de acordo com o processo de priorização de tickets:

Campo Solicitação Priorizada;
Motivo da priorização;
Data priorização;
Detalhamento;

É indispensável que estes campos estejam preenchidos, caso não estejam, o analista responsável pelo ticket deverá realizar seu preenchimento.

4 - Atribuir o ticket para a própria fila enviar um comentário público conforme abaixo:
"Bom dia/tarde [nome do requerente].
Este ticket encontra-se em nossa fila de prioridades, iremos analisar o caso e retornaremos o mais breve possível."

5 - Ler atentamente a questão reportada no ticket e tomar ciência sobre o caso, em seguida, fazer contato telefônico para coletar qualquer informação adicional pertinente e informar o cliente que o ticket já esta com a equipe responsável e o caso será tratado de imediato (recomenda-se ligar para o cliente, ainda que não haja necessidade de coleta de informação).

6 - Qualquer evolução relevante sobre o caso, deve-se realizar contato telefônico com o cliente para atualização e registrar a informação em um trâmite público:
Exemplo: "Caro cliente, conforme conversamos por telefone......"

7 - As ações de resolução do ticket priorizado devem sempre ser direcionadas para realizar ações de contorno, minimizando o caráter urgente da questão. Ao aplicar a solução paliativa, o ticket deverá ser resolvido e um novo ticket deverá ser aberto, pelo próprio agente responsável, para prosseguir com a investigação e solução da causa raiz. O cliente deverá ser informado, via contato telefônico (sempre que possível), de todas estas ações e deverá ser informado sobre o novo número de ticket aberto (caso haja).

8 - Caso seja aberto um Issue para os times Jira, realizar notificação no grupo de chat (Priorização de chamados Suporte SFA) e notificar o responsável conforme descrito no processo de priorizações.

Tickets com tipo de priorização classificados com a opção Operação Parada precisam ser resolvidos no mesmo dia em que ocorreu a priorização, seja tratando a causa raiz ou aplicando uma ação de contorno(que irá remover o caráter urgente da demanda). Caso a resolução não seja possível no mesmo dia, o prazo de resolução deve ser acordado com o cliente e registrado via observação pública no ticket. A nota deve informar claramente que a demanda será tratada prioritariamente no dia seguinte, que o cliente está ciente e concorda com este cenário.

Boas práticas - Protheus

8 - CRITÉRIOS de DoR e DoD - ZENDESK E JIRA - SFA

Nesta documentação estão definidos os padrões para a realização das entregas das equipes que utilizam o Zendesk e o Jira, em ambos os fluxos, Zendesk para o Jira (criação de Issues) e do Jira para o Zendesk (resolução, dúvidas ou rejeição de Issues).

Para acessar, clique aqui.

Boas práticas - Protheus

9 - PÁGINA DE CLIENTES - SFA

Nesta documentação estão presentes diversas informações técnicas a respeito dos clientes do SFA, que serão utilizadas durante o atendimento e resolução dos tickets. Para acessá-la, clique aqui.

Boas práticas - Protheus

Aqui estão informações sobre os diferentes processos exclusivos das equipes de suporte do Gestão de Clientes.

¶ - ÍNDICE

<ul><strong>
        <li style="color:#FF9900"><span><a href="#ProcessosSuporteTOTVSCRM-item_1"><font color=#000000>1 - GC - Processo Desenvolvimento Ágil | Critérios DoR e DoD - Suporte e Produto</font></a></span></li>
</strong></ul>

1 - GC - Processo Desenvolvimento Ágil | Critérios DoR e DoD - Suporte e Produto

Página de processos sobre os critérios DoR e DoD para os times de Suporte e Produto do GC. Para acessá-la, clique aqui.

Boas práticas - Protheus

Aqui estão informações sobre os diferentes processos a serem seguidos por todas as equipes de suporte da TOTVS CRM.

1 - PROCESSO DE ATENDIMENTO

Documentação com a estrutura de páginas do processo de atendimento, fluxos do processo de atendimento, fluxo do processo de suporte integrado boas práticas no atendimento, boas práticas na criação de documentação, instruções de trabalho e assuntos relacionados.

1.1.2 - Processo de Atendimento | Estrutura do atendimento de tickets.

Tabela com informações que envolvem o processo de atendimento e como os recursos da ferramenta Zendesk devem ser utilizados de acordo com cada necessidade.

Manual Zendesk.

EC - ZEN - Como acessar o Zendesk - Agente.

EC - ZEN - Funcionalidade do aplicativo Quickie.

EC - TOTVS Minha Senha - Envio de senha - Interno.

EC - ZEN - Prazo de SLA de Atendimento.

EC - ZEN - Campo Impacto no ticket.

EC - ZEN - Finalidade do FCR.

EC - ZEN - Visualizar Hierarquia de Atendimento - Ticket.

EC - ZEN - Status dos tickets - Zendesk x Portal do Cliente.

EC - ZEN - Entender o SLA através dos Eventos do ticket.

EC - Portal do Consultor - Solicitar Priorização de Ticket.

EC - ZEN - Pausa do SLA no ticket.

EC - ZEN - Campos Causa e Classificação no ticket.

EC - ZEN - Visualização (Criação e Alterações).

EC - ZEN - Abertura de Ticket manualmente em nome do cliente pelo Zendesk.

EC - ZEN - Como utilizar a transferência de ticket.

EC - ZEN - Como utilizar o aplicativo de compartilhamento de tickets.

EC - Zendesk - Fusão de Tickets.

EC - ZEN - Quando o cliente é Cloud.

EC - ZEN - Procedimento para contatos sem organização.

EC - ZEN - Solicitante sem vínculo com organização.

EC - ZEN - Retorno dos Clientes por E-mail não Registrado.

EC - ZEN - Prazo de alteração automática de status do ticket pendente com o cliente.

EC - ZEN - Atualização em massa de tickets.

EC - Zendesk - Aplicação de Macro para equipe Manutenção.

EC - ZEN - Aplicação de Macro para Manutenção Associação.

EC - ZEN - Como gerar uma issue de Rejeição Manutenção.

Tickets com Issue Vinculadas.

EC - ZEN - Tags Aplicadas nas Macros Padrões de Transferência.

EC - Jira - Erros no Processos Gerando Impacto Para o Cliente.

Atendimento - Base de Conhecimento.

Chat - Atendimento.

Metodologia e Processo KCS - Base de Conhecimento.

Macros Processo de Atendimento.

Jira Service Management.

Catálogo de Serviços.

Suporte RH Protheus - Procedimentos e Ferramentas do Atendimento (Apenas KCS Interno).

Base de Conhecimento - Interna Eng Corp Atendimento.

Template KCS.

2 - PROCESSO KCS

Tabela com informações que envolvem o processo KCS e como os recursos da ferramenta Zendesk devem ser utilizados de acordo com cada necessidade.

2.1.2 - Processo KCS | A Metodologia na TOTVS.

2.1.3 - Coletânea de principais artigos sobre o processo KCS.

EC - KCS - Treinamento / Vídeos do processo e ferramenta.

EC - KCS - O que pode ser incluído no Artigo.

EC - KCS - Quais são os objetivos do KCS.

EC - KCS - Competências KCS e seus direitos e deveres.

EC - KCS - Criar Artigo.

EC - KCS – Criar artigo pelo app Knowledge Capture.

EC - KCS - Melhores práticas para criar um Artigo.

Template | Padrão de Escrita de Artigos.

EC - KCS - Padrões de template para criar Artigo na Central de Atendimento.

EC - KCS - Inclui uma macro incorretamente como devo proceder antes de salvar o ticket.

EC - KCS - Alterar seção do artigo.

EC - KCS - Artigo duplicado.

EC - KCS - Labels / tags / rótulos obrigatórias em um Artigo.

EC - KCS - Formatação das labels / tags / rótulos nos artigos.

EC - KCS - Status de um artigo até a sua publicação a Central de Atendimento.

EC - KCS - Revisar e Publicar um Artigo.

EC - KCS - Processo para ajustar ou realizar uma manutenção em um Artigo.

2.1.4 - Metodologia e Processo KCS - Base de Conhecimento.

Listagem completa de artigos KCS sobre o produto SFA (públicos e internos)

Listagem completa de artigos KCS sobre o produto GC (públicos e internos)

Aqui estão informações sobre os diferentes processos exclusivos das equipes de suporte do SFA.

1 - PROCESSO DE CRIAÇÃO DE ISSUES

2 - PROCESSO DE ENVIO PARA DEV (SUSTENTAÇÃO APLICAÇÃO), P&D E INTEGRAÇÃO

3 - PROCESSO DE MELHORIA/CUSTOMIZAÇÃO

4 - PROCESSO DE SOLICITAÇÕES RELACIONADAS À ATUALIZAÇÃO DO PROTHEUS

5 - PROCESSO DE SOLICITAÇÃO DE APOIO AO MAESTRO

6 - PROCESSO PARA OCORRÊNCIAS RELACIONADAS AO TOTVS CONNECTOR

7 - INSTRUÇÃO DE TRABALHO - PROCESSO DAS EQUIPES DE ATENDIMENTO DO SUPORTE.

8 - CRITÉRIOS de DoR e DoD - ZENDESK E JIRA - SFA

9 - PÁGINA DE CLIENTES - SFA

Aqui estão informações sobre os diferentes processos exclusivos das equipes de suporte do Gestão de Clientes.

1 - GC - Processo Desenvolvimento Ágil | Critérios DoR e DoD - Suporte e Produto