Resumo Executivo
Visao Geral do N2
O N2 opera no modelo de especialistas por produto. A cada grupo de 2 ou 3 analistas e atribuida uma carteira especifica de produtos, responsavel por atendimento de incidentes e requisicoes.
Secao 01
Fluxo de Abertura de Incidentes
Ao investigar um chamado, caso o analista N2 identifique que se trata de um erro real, deve reportar a Tecnologia (N3). Se possivel aplicar contorno, o analista apenas registra a solucao e encerra o chamado. Se nao for possivel aplicar contorno ao cliente, o analista deve obrigatoriamente abrir um incidente.
Requisitos Criticos - Incidentes
Campos Obrigatorios no Formulario de Incidente
| Campo | Descricao | Obrigatorio |
|---|---|---|
| Descricao do chamado | Sintese do problema reportado | Sim |
| Analise tecnica | Diagnostico realizado pelo N2 | Sim |
| Erro geral ou especifico? | Erro Geral | Erro em apenas uma conta | Erro em determinadas circunstancias | Sim |
| Funcionalidade | Normal | Beta Feature | Sim |
| Contorno recusado pelo produtor? | Sem contorno | Contorno recusado (+ qual solucao foi recusada) | Sim |
| Exemplo de itens com erro | IDs, slugs, URLs, etc. | Sim |
| Erro reproduzivel? | Sim (+ evidencia) | Nao (+ anexo) | Sim |
| Versao | Versao do produto/sistema | Nao |
| Exemplo de locais | Escola, modulo, fatura, endpoints, etc. | Sim |
| Belt do produtor | Avatar/Belt do cliente | Sim |
Secao 02
Abertura de Problemas (Causa Raiz)
Para todo incidente, com ou sem contorno, e obrigatoria a abertura de um ticket de Problema (Causa Raiz) vinculado ao chamado original. Este processo e fundamental para garantir a organizacao e o acompanhamento das causas no backlog de tecnologia.
1. Abrir a Causa Raiz (Problema) ANTES da abertura do incidente
2. Abrir o Incidente e vincula-lo obrigatoriamente a causa raiz criada
3. Todo incidente deve possuir uma causa raiz associada
Campos Obrigatorios - Problema (Causa Raiz)
O ticket de Problema deve conter, de forma visivel para o N3 (Desenvolvimento):
| Campo | Tipo | Observacao |
|---|---|---|
| Produto afetado | Dropdown | Produto onde o erro ocorre |
| Analista responsavel | User | Especialista N2 que abriu o problema |
| Prioridade | Dropdown | Baixa | Media | Alta | Critica |
| Categoria | Dropdown | Categoria do erro |
| Data de abertura | Date | Auto-preenchida |
| Data prevista de solucao | Date | Calculada com base em SLA |
| Avatar/Belt | Text | Identificacao do cliente |
| Quantidade de chamados vinculados | Number | Contador automatico |
| Card No Jira | Text | ID do card criado via integracao |
Vinculacao de Chamados
Problemas abertos devem ter a possibilidade de vincular novos chamados (incidentes) a qualquer momento. Quando multiplos clientes reportam o mesmo erro, todos os tickets devem ser vinculados ao mesmo Problema (Causa Raiz).
Secao 03
Tratamento de Requisicoes
O N2 tambem recebe tickets de requisicao para atendimento. Esses tickets podem ser solicitacoes de consultores ou de clientes externos, envolvendo pedidos de relatorios, ajustes ou melhorias.
Escalonamento para Tecnologia
Para requisicoes que dependem de atuacao tecnica, o N2 deve, a partir do ticket em atendimento, abrir uma Requisicao para Tecnologia. O ticket de requisicao escalonado para N3 deve cair no BOARD do PO (Product Owner).
Permissoes Necessarias
- Abrir requisicoes para o board do PO
- Editar as informacoes da requisicao apos a abertura se necessario
Conteudo Minimo da Requisicao
| Campo | Obrigatorio |
|---|---|
| Descricao clara da solicitacao | Sim |
| Evidencias ou exemplos (quando aplicavel) | Recomendado |
| Contexto de impacto para o cliente | Sim |
Secao 04
Especialistas N2 por Produto
Configuracao de roteamento e escalonamento no HubSpot Service Hub. Cada analista e responsavel por uma carteira especifica de produtos.
| Colaborador | Produtos de Atendimento | |
|---|---|---|
| Aline | aline.oliveira@eduzz.com.br |
MyEduzz, Next, DevHub, Blinket, AppEduzz, Analytics / FIDC, Nutror, AlpaClass |
| Ana | ana.madruga@eduzz.com.br |
Checkout Sun, OrbitPages, Next |
| Ayrton | ayrton.cesar@eduzz.com.br |
FIDC, Checkout Sun, Blinket, MyEduzz, Next, Analytics / BackOffice, AppEduzz, OrbitPages |
| Caique | caique.prudencio@eduzz.com.br |
Checkout Sun, OrbitPages, Next, Analytics / Nutror |
| Daniela | daniela.alves@eduzz.com.br |
AlpaClass, Nutror, Store, SafeVideo, Heycamp, Depoimentus, App Nutror / BackOffice |
| Edson B. | edson.barros@eduzz.com.br |
BackOffice, MyEduzz / DevHub, Next, Blinket, AppEduzz, Analytics |
| Gislaine | gislaine.molina@eduzz.com.br |
Checkout Sun, Store, SafeVideo, Heycamp, Depoimentus, App Nutror |
| Hiroshi (Guilherme) | guilherme.kadoo@eduzz.com.br |
AlpaClass, Nutror, Store, SafeVideo, Heycamp, Depoimentus, App Nutror |
| Luy | luy.domingues@eduzz.com.br |
Next, AlpaClass, Nutror, SafeVideo, Store, Analytics / MyEduzz, DevHub, Blinket, AppEduzz |
Secao 05
Encerramento Automatico de Tickets
Feature CRITICA que elimina trabalho manual e acelera resposta ao cliente atraves de integracao bidirecional entre HubSpot e Jira.
Como Funciona
Atraves da integracao HubSpot ↔ Jira, o sistema deve:
Sincronizacao de Status HubSpot ↔ Jira
A integracao deve manter sincronismo bidirecional entre os status do ticket no HubSpot e o card no Jira:
| Status Jira | Status HubSpot | Acao |
|---|---|---|
| Open | Processando (Aguardando Problema) | Manter ticket processando |
| Pendente Informacoes | Pendente | Aplicar modelo de tarefa + devolver para N2 |
| Em desenvolvimento | Processando | Manter status |
| Em code review | Processando | Manter status |
| Pronto p/ testar | Processando | Manter status |
| Testando | Processando | Manter status |
| Aguardando Deploy | Processando | Aplicar modelo de tarefa + pendente |
| Closed + Resolution FEITO | Solucionado | Aplicar modelo de solucao + encerrar |
| Closed + Outros Resolution | Pendente | Aplicar modelo de tarefa + devolver para N2 |
| - | Fechado | Alterar status Jira para ENCERRADO |
Secao 06
Implementacao Tecnica - Referencia GLPI x Jira
Documentacao da implementacao atual no GLPI para servir como referencia para o HubSpot.
O metodo solveGlpiTicket em TicketService.php executa as seguintes acoes:
1. Incidentes e Requisicoes Resolvidos (Status "Done/Feito")
- Incidente: GlpiSolutionTemplates.php (linhas 7-10)
- Requisicao: GlpiSolutionTemplates.php (linhas 12-15)
Template de Mensagem Atual (GLPI)
2. Cards Cancelados (Resolution ≠ "Done")
-
updateTicketAssignedGroup
- ou
updateProblemAssignedGroup
Regras Criticas para Replicar no HubSpot
Metodos de Referencia (GLPI)
| Metodo/Arquivo | Linha | Funcao |
|---|---|---|
TicketService.php |
379 | Reabertura de tickets |
TicketService.php |
396 | Reabertura de tickets |
Glpi.php |
304 | Atualizacao de grupo atribuido |
Glpi.php |
343 | Atualizacao de grupo atribuido |
GlpiSolutionTemplates.php |
7-10 | Template de solucao para Incidentes |
GlpiSolutionTemplates.php |
12-15 | Template de solucao para Requisicoes |
Proximos Passos
Implementacao no HubSpot
Com base nesta documentacao, sera necessario revisar a configuracao atual do HubSpot Service Hub para garantir que todos os processos N2 estejam implementados corretamente.
Itens a Revisar
- Configuracao de pipelines e status de tickets
- Propriedades customizadas para Incidentes e Problemas
- Permissoes de edicao para o time N2
- Roteamento automatico por especialista/produto
- Integracao bidirecional HubSpot ↔ Jira
- Modelos de tarefa e solucao automatizados
- Formularios de abertura de Incidente e Problema
- Workflow de encerramento automatico