Politica de Atendimento - Histórico de revisão

Gustavo em 13h02min de 7 de janeiro de 2021

2021-01-07T13:02:04Z

Gustavo em 12h57min de 10 de dezembro de 2018

2018-12-10T12:57:45Z

Maicon: /* SUSTENTAÇÃO - BUGs E ERROS */

2017-02-24T12:25:10Z

‎SUSTENTAÇÃO - BUGs E ERROS

Maicon: /* SUSTENTAÇÃO - BUGs, ERROS E SOLICITAÇÕES */

2017-02-24T12:21:17Z

‎SUSTENTAÇÃO - BUGs, ERROS E SOLICITAÇÕES

Maicon: /* SUSTENTAÇÃO - BUGs, ERROS E SOLICITAÇÕES */

2017-02-24T12:20:32Z

‎SUSTENTAÇÃO - BUGs, ERROS E SOLICITAÇÕES

Maicon: /* SUSTENTAÇÃO - BUGs, ERROS E SOLICITAÇÕES */

2017-02-24T12:17:24Z

‎SUSTENTAÇÃO - BUGs, ERROS E SOLICITAÇÕES

Maicon: /* SUSTENTAÇÃO - BUGs, ERROS E SOLICITAÇÕES */

2017-02-24T12:16:47Z

‎SUSTENTAÇÃO - BUGs, ERROS E SOLICITAÇÕES

Maicon: /* SUSTENTAÇÃO - BUGs, ERROS E SOLICITAÇÕES */

2017-02-24T12:14:25Z

‎SUSTENTAÇÃO - BUGs, ERROS E SOLICITAÇÕES

Maicon: /* SUSTENTAÇÃO - BUGs, ERROS E SOLICITAÇÕES */

2017-02-24T12:13:55Z

‎SUSTENTAÇÃO - BUGs, ERROS E SOLICITAÇÕES

Maicon em 12h13min de 24 de fevereiro de 2017

2017-02-24T12:13:40Z

@@ Linha 1: / Linha 1: @@
-==<b>DEFINIÇÕES</b>==
+=='''DEFINIÇÕES'''==
- <b>BUGS –</b> Tem-se um bug quando algum processo do sistema está sendo executado de maneira incorreta, porém não está impedindo o usuário de continuar a trabalhar com o sistema. Por exemplo, um cálculo errado de uma tela, ou algum relatório desalinhado ou não condizente com a tela.
+* <b>BUGS –</b> Tem-se um bug quando algum processo do sistema está sendo executado de maneira incorreta, porém não está impedindo o usuário de continuar a trabalhar com o sistema. Por exemplo, um cálculo errado de uma tela, ou algum relatório desalinhado ou não condizente com a tela.
- <b>ERROS – </b>Tem-se um erro quando algum processo do sistema não está executando alguma ação. Por exemplo, ao finalizar uma nota o sistema apresenta erro null, ou numeric overflow. Lembrando que erros de mensagens não tratadas não devem ser considerados erros e sim solicitações. Por exemplo, ao excluir algum registro de uma tela e o sistema apresenta erro de chave estrangeira. Isso não é um erro, pois o sistema não permitiu o usuário excluir o registro, porém um tratamento pra que a mensagem seja diferente deve ser criado.
+* <b>ERROS – </b>Tem-se um erro quando algum processo do sistema não está executando alguma ação. Por exemplo, ao finalizar uma nota o sistema apresenta erro null, ou numeric overflow. Lembrando que erros de mensagens não tratadas não devem ser considerados erros e sim solicitações. Por exemplo, ao excluir algum registro de uma tela e o sistema apresenta erro de chave estrangeira. Isso não é um erro, pois o sistema não permitiu o usuário excluir o registro, porém um tratamento pra que a mensagem seja diferente deve ser criado.
- Qualquer outra alteração que modifique os processos do software, disposição de campos, mensagens, bem como seu funcionamento, deve ser encaminhado para a equipe de '''Produto & Inovação''' para um diagnóstico correto da necessidade.
+Qualquer outra alteração que modifique os processos do software, disposição de campos, mensagens, bem como seu funcionamento, deve ser encaminhado para a equipe de '''Produto & Inovação''' para um diagnóstico correto da necessidade.
- <b>FLUXO DE ATENDIMENTO</b>
+==='''FLUXO DE ATENDIMENTO'''===
- O fluxo de atendimento, seja ele via Chat ou Telefone, segue o diagrama abaixo. Inicia-se no '''Suporte''', onde o problema é reportado, se não for resolvido a equipe de '''Produtos & Inovação''' é envolvida e fará um contato com o cliente para diagnosticar o problema, caso um Bug e/ou Erro seja identificado esse diagnóstico com a solução é enviado a equipe de '''Desenvolvimento''', onde uma versão com a correção será disponibilizado de acordo com o prazo de SLA para equipe de produtos que fará um novo contato para atualização do software.
+O fluxo de atendimento, seja ele via Chat ou Telefone, segue o diagrama abaixo. Inicia-se no '''Suporte''', onde o problema é reportado, se não for resolvido a equipe de '''Produtos & Inovação''' é envolvida e fará um contato com o cliente para diagnosticar o problema, caso um Bug e/ou Erro seja identificado esse diagnóstico com a solução é enviado a equipe de '''Desenvolvimento''', onde uma versão com a correção será disponibilizado de acordo com o prazo de SLA para equipe de produtos que fará um novo contato para atualização do software.
- [[Arquivo:Diagrama-ticket2.png]]
+[[Arquivo:Diagrama-ticket2.png]]
- <b>SLA's (desenvolvimento)</b>
+==='''SLA's (desenvolvimento)'''===
- Após concluída a fase de diagnóstico, pelo setor de '''Produto & Inovação''', os bugs devem ser classificados considerando o impacto que está gerando na operação do cliente. De acordo com este impacto é determinada a Urgência conforme a tabela abaixo, e são definidos os prazos máximos para disponibilização da versão com a correção
+Após concluída a fase de diagnóstico, pelo setor de '''Produto & Inovação''', os bugs devem ser classificados considerando o impacto que está gerando na operação do cliente. De acordo com este impacto é determinada a Urgência conforme a tabela abaixo, e são definidos os prazos máximos para disponibilização da versão com a correção
-  [[Arquivo:tabela_sustentacao1.png]]
+  {| class="wikitable"
- <font color='red'><b>*</b></font> Os dias estão sendo considerados com base em 8 horas.
+====<b>EXEMPLOS</b>====
- <font color='red'><b>**</b></font> Os tickets referentes a SPED/SEF/EDoc sempre serão classificados como Baixa urgência e os tickets devem ser abertos com no mínimo 8 dias uteis de antecedência a entrega do arquivo.
+* <b>Alta:</b> VRPdv sem vender, VRConcentrador não enviando preço, VRAutorizador off-line, erros na emissão de NF (exception), erro ao encerrar o dia, etc.
- <b>EXEMPLOS</b>
+Todas as regras descritas anteriormente nesse documento têm por objetivo auxiliar no cumprimento desses prazos. Dessa forma, manteremos a satisfação do cliente por ter o seu problema resolvido rapidamente.

@@ Linha 1: / Linha 1: @@
-==<b>SUSTENTAÇÃO - BUGs E ERROS</b>==
+==<b>DEFINIÇÕES</b>==
   <b>BUGS –</b> Tem-se um bug quando algum processo do sistema está sendo executado de maneira incorreta, porém não está impedindo o usuário de continuar a trabalhar com o sistema. Por exemplo, um cálculo errado de uma tela, ou algum relatório desalinhado ou não condizente com a tela.
   <b>ERROS – </b>Tem-se um erro quando algum processo do sistema não está executando alguma ação. Por exemplo, ao finalizar uma nota o sistema apresenta erro null, ou numeric overflow. Lembrando que erros de mensagens não tratadas não devem ser considerados erros e sim solicitações. Por exemplo, ao excluir algum registro de uma tela e o sistema apresenta erro de chave estrangeira. Isso não é um erro, pois o sistema não permitiu o usuário excluir o registro, porém um tratamento pra que a mensagem seja diferente deve ser criado.
-  Qualquer outra alteração que modifique os processos do software, disposição de campos, mensagens, bem como seu funcionamento, deve ser enviado para comitê para a aprovação, e posteriormente arquitetura e desenvolvimento.
-  Existirão casos onde um Bug ou Erro, devido a sua complexidade ou custo (em horas de desenvolvimento), possa ser enviado para arquitetura.
+  Qualquer outra alteração que modifique os processos do software, disposição de campos, mensagens, bem como seu funcionamento, deve ser encaminhado para a equipe de '''Produto & Inovação''' para um diagnóstico correto da necessidade.
-  <b>SLA's</b>
+  <b>SLA's (desenvolvimento)</b>
-  Os bugs devem ser classificados pelos responsáveis do setor de desenvolvimento ou suporte, considerando o impacto que está gerando na operação do cliente. De acordo com este impacto é determinada uma “Urgência” conforme a tabela abaixo, e são definidos os prazos máximos para a solução do problema
+  Após concluída a fase de diagnóstico, pelo setor de '''Produto & Inovação''', os bugs devem ser classificados considerando o impacto que está gerando na operação do cliente. De acordo com este impacto é determinada a Urgência conforme a tabela abaixo, e são definidos os prazos máximos para disponibilização da versão com a correção
   [[Arquivo:tabela_sustentacao1.png]]
@@ Linha 21: / Linha 24: @@
   <b>EXEMPLOS</b>
+  - <b>Alta:</b> VRPdv sem vender, VRConcentrador não enviando preço, VRAutorizador off-line, erros na emissão de NF (exception), erro ao encerrar o dia, etc.
- <b>Alta:</b> VRPdv sem vender, VRConcentrador não enviando preço, VRAutorizador off-line, erros na emissão de NF (exception), erro ao encerrar o dia, etc.
+  - <b>Média:</b> cálculo errado ao formular preço de um produto, erro ao importar xml de nota fiscal de entrada, problema ao consistir uma nota de saída, etc
-  <b>Média:</b> cálculo errado ao formular preço de um produto, erro ao importar xml de nota fiscal de entrada, problema ao consistir uma nota de saída, etc
+  - <b>Baixa:</b> valores divergentes entre telas, total em relatório não bate com a soma dos itens, nomenclatura de parâmetro incorreto, erros de ortografia, etc.
   Todas as regras descritas anteriormente nesse documento têm por objetivo auxiliar no cumprimento desses prazos. Dessa forma, manteremos a satisfação do cliente por ter o seu problema resolvido rapidamente.

@@ Linha 11: / Linha 11: @@
   Existirão casos onde um Bug ou Erro, devido a sua complexidade ou custo (em horas de desenvolvimento), possa ser enviado para arquitetura.
-  <b>SLA’s</b>
+  <b>SLA's</b>
   Os bugs devem ser classificados pelos responsáveis do setor de desenvolvimento ou suporte, considerando o impacto que está gerando na operação do cliente. De acordo com este impacto é determinada uma “Urgência” conforme a tabela abaixo, e são definidos os prazos máximos para a solução do problema
@@ Linha 17: / Linha 17: @@
   [[Arquivo:tabela_sustentacao1.png]]
-  <font color='red'><b>*</b></font>Os dias estão sendo considerados com base em 8 horas.
+  <font color='red'><b>*</b></font> Os dias estão sendo considerados com base em 8 horas.
-  <font color='red'><b>**</b></font>Os tickets referentes a SPED/SEF/EDoc sempre serão classificados como Baixa urgência e os tickets devem ser abertos com no mínimo 8 dias uteis de antecedência a entrega do arquivo.
+  <font color='red'><b>**</b></font> Os tickets referentes a SPED/SEF/EDoc sempre serão classificados como Baixa urgência e os tickets devem ser abertos com no mínimo 8 dias uteis de antecedência a entrega do arquivo.
   <b>EXEMPLOS</b>

@@ Linha 1: / Linha 1: @@
 <font color=#999999><b>No momento, nossa política de atendimento está sendo atualizada. Para evitar transtornos deixamos as informações desta página parcialmente off-line e estamos trabalhando para que possamos retornar as novas informações o mais breve possível.</b></font>
-==<b>SUSTENTAÇÃO - BUGs, ERROS E SOLICITAÇÕES</b>==
+==<b>SUSTENTAÇÃO - BUGs E ERROS</b>==
   <b>DEFINIÇÕES</b>

@@ Linha 17: / Linha 17: @@
   [[Arquivo:tabela_sustentacao1.png]]
-  <font color='red'>*</font>Os dias estão sendo considerados com base em 8 horas.
+  <font color='red'><b>*</b></font>Os dias estão sendo considerados com base em 8 horas.
-  <font color='red'>**</font>Os tickets referentes a SPED/SEF/EDoc sempre serão classificados como Baixa urgência e os tickets devem ser abertos com no mínimo 8 dias uteis de antecedência a entrega do arquivo.
+  <font color='red'><b>**</b></font>Os tickets referentes a SPED/SEF/EDoc sempre serão classificados como Baixa urgência e os tickets devem ser abertos com no mínimo 8 dias uteis de antecedência a entrega do arquivo.
   <b>EXEMPLOS</b>

@@ Linha 1: / Linha 1: @@
 <font color=#999999><b>No momento, nossa política de atendimento está sendo atualizada. Para evitar transtornos deixamos as informações desta página parcialmente off-line e estamos trabalhando para que possamos retornar as novas informações o mais breve possível.</b></font>
-.	Definições:
+ ERROS – Tem-se um erro quando algum processo do sistema não está executando alguma ação. Por exemplo, ao finalizar uma nota o sistema apresenta erro null, ou numeric overflow. Lembrando que erros de mensagens não tratadas não devem ser considerados erros e sim solicitações. Por exemplo, ao excluir algum registro de uma tela e o sistema apresenta erro de chave estrangeira. Isso não é um erro, pois o sistema não permitiu o usuário excluir o registro, porém um tratamento pra que a mensagem seja diferente deve ser criado.
 Qualquer outra alteração que modifique os processos do software, disposição de campos, mensagens, bem como seu funcionamento, deve ser enviado para comitê para a aprovação, e posteriormente arquitetura e desenvolvimento.
 Existirão casos onde um Bug ou Erro, devido a sua complexidade ou custo (em horas de desenvolvimento), possa ser enviado para arquitetura.
-.	SLA’s
+ <font size='5'>SLA’s</font>
 Os bugs devem ser classificados pelos responsáveis do setor de desenvolvimento ou suporte, considerando o impacto que está gerando na operação do cliente. De acordo com este impacto é determinada uma “Urgência” conforme a tabela abaixo, e são definidos os prazos máximos para a solução do problema
-Urgência	Aplicação	Suporte (Horas)	Desenvolvimento (Horas)	Total (Horas)	Dias Uteis*
+ [[Arquivo:tabela_sustentacao1.png]]
-Alta	Parada de Operação	2	6	8	1
-Média	Operação Prejudicada	8	16	24	3
+ <font color='red'>*</font>Os dias estão sendo considerados com base em 8 horas.
-Baixa**	Sem impacto na operação	8	56	64	8
+ <font color='red'>**</font>Os tickets referentes a SPED/SEF/EDoc sempre serão classificados como Baixa urgência e os tickets devem ser abertos com no mínimo 8 dias uteis de antecedência a entrega do arquivo.
-−
-* Os dias estão sendo considerados com base em 8 horas.
+ EXEMPLOS
 ** Os tickets referentes a SPED/SEF/EDoc sempre serão classificados como Baixa urgência e os tickets devem ser abertos com no mínimo 8 dias uteis de antecedência a entrega do arquivo.
+ Alta: VRPdv sem vender, VRConcentrador não enviando preço, VRAutorizador off-line, erros na emissão de NF (exception), erro ao encerrar o dia, etc.
-Exemplos:
+ Média: cálculo errado ao formular preço de um produto, erro ao importar xml de nota fiscal de entrada, problema ao consistir uma nota de saída, etc
-•	Alta: VRPdv sem vender, VRConcentrador não enviando preço, VRAutorizador off-line, erros na emissão de NF (exception), erro ao encerrar o dia, etc.
+ Baixa: valores divergentes entre telas, total em relatório não bate com a soma dos itens, nomenclatura de parâmetro incorreto, erros de ortografia, etc.
-•	Média: cálculo errado ao formular preço de um produto, erro ao importar xml de nota fiscal de entrada, problema ao consistir uma nota de saída, etc
-•	Baixa: valores divergentes entre telas, total em relatório não bate com a soma dos itens, nomenclatura de parâmetro incorreto, erros de ortografia, etc.
+ Todas as regras descritas anteriormente nesse documento têm por objetivo auxiliar no cumprimento desses prazos. Dessa forma, manteremos a satisfação do cliente por ter o seu problema resolvido rapidamente.