Tickets

Cada seção da tela é ilustrada com uma figura e contém indicações de onde inserir capturas de tela para facilitar a diagramação.

Legenda: ✅ Campo obrigatório · ⚠️ Campo opcional (ou de uso específico)

1) Acesso ao cadastro de Ticket ServiceDesk

Para acessar a tela de tickets do ServiceDesk no BomControle: no menu superior, clique em ServiceDesk e em seguida selecione Tickets. A tela de listagem de tickets será exibida mostrando os chamados já cadastrados. Nessa tela é possível pesquisar, filtrar e visualizar os tickets existentes, além de incluir um novo ticket através do botão Novo ticket.

2) Tela de pesquisa e listagem de Tickets

Ao entrar em ServiceDesk > Tickets, você verá a tela de pesquisa/listagem de tickets. Essa tela é dividida em três partes principais: os filtros de busca no topo, a área de visualização dos tickets (que pode ser em formato Cards ou Tabela), e a barra de ações fixa no rodapé. A seguir, detalhamos cada parte:

Figura 1 — Tela de pesquisa de tickets ServiceDesk 

2.1 Filtros e opções de visualização

Logo no topo da tela encontram-se diversos filtros que permitem localizar e segmentar os tickets desejados:

Figura 2 — Filtros da tela de pesquisa de tickets 

• Data: filtro de período para criação do ticket. Pode-se selecionar um intervalo de datas (Data inicial e final) para listar apenas tickets abertos nesse período. ⚠️ Opcional – se não preenchido, o sistema usa um período padrão (por exemplo, últimos 12 meses). Esse filtro não impacta outros módulos, apenas limita os resultados pela data de abertura dos tickets.

• Meus Filtros: permite aplicar filtros personalizados salvos. O usuário pode salvar combinações frequentes de filtros (por exemplo, “Tickets urgentes do último mês”) e selecioná-las aqui. Também é possível marcar um filtro como favorito (estrela) e adicionar ou editar filtros salvos pelo botão “+”. ⚠️ Opcional – se nenhum filtro salvo for selecionado, a busca considera os critérios definidos manualmente nos demais campos. Observação: Para salvar um novo conjunto de filtros, configure os campos desejados e clique no ícone de salvar (disquete) ao lado deste campo, atribuindo um nome.

• Pesquisar: campo de busca textual livre. Digite palavras que estejam no título ou descrição dos tickets para filtrar resultados. ⚠️ Opcional – se preenchido, o sistema buscará tickets cujo título ou descrição contenham o texto inserido. Exemplo: buscar por "instalação" trará todos os tickets relacionados a instalação. (Não há impacto em outros módulos; é apenas uma busca textual.)

• Fluxo de Trabalho: filtro para escolher o fluxo de trabalho (processo) cujos tickets serão exibidos. ✅ Obrigatório – sempre deve haver um fluxo selecionado. Por padrão, o BomControle traz o fluxo de trabalho padrão do ServiceDesk configurado para a empresa, mas você pode trocar usando este filtro. Cada fluxo de trabalho corresponde a um conjunto de etapas/status pelos quais um ticket pode passar (por exemplo: Aberto > Em Andamento > Resolvido). Impacto: os tickets listados abaixo serão apenas os pertencentes ao fluxo selecionado. Se nenhum fluxo for selecionado, não há como exibir tickets (o sistema requer um fluxo). (O fluxo de trabalho em si não afeta diretamente estoque/financeiro, mas determina o ciclo de vida do atendimento.) Campos configuráveis: os fluxos de trabalho e suas etapas são cadastrados previamente na configuração do ServiceDesk (menu de Cadastro de Fluxo de Trabalho – ServiceDesk).

• Prioridade: permite filtrar os tickets por prioridade. É possível selecionar uma ou mais prioridades (por exemplo, Baixa, Normal, Alta, Crítica). ⚠️ Opcional – se nada for marcado, traz tickets de todas as prioridades. As prioridades servem para indicar a urgência do ticket. Observação: a prioridade não afeta outros módulos diretamente – por exemplo, não movimenta estoque nem gera cobranças –, mas pode estar ligada a prazos de SLA (acordos de nível de serviço) e aparece em relatórios de atendimento. Campos configuráveis: os níveis de prioridade são padrão do sistema (Baixa, Normal, Alta, Crítica).

• Cliente: filtra os tickets por cliente específico. Você pode selecionar um ou mais clientes (da base de clientes cadastrados). ⚠️ Opcional – se preenchido, serão listados apenas tickets ligados ao(s) cliente(s) selecionado(s). Por padrão, se você tem acesso a uma única empresa, este campo lista os clientes dessa empresa; em ambientes multi-empresa, é filtrado pela empresa escolhida. Impacto: este filtro ajuda a localizar chamados de um determinado cliente. Não afeta estoque ou financeiro diretamente, mas é útil para, por exemplo, ver todos os tickets abertos por um cliente que também pode ter pedidos ou contratos nos módulos de Vendas/Financeiro. (O cliente de um ticket é o mesmo cadastro de cliente usado nos módulos de vendas e financeiro, garantindo integração de informações.)

• Status: filtra por status específicos dos tickets. Aparece apenas quando a visualização está em modo Tabela. Você pode selecionar um ou mais status (ex.: A Fazer, Fazendo, Parado, Feito, Fechado). ⚠️ Opcional – se não selecionado, considera todos os status (exceto possivelmente os fechados, dependendo do filtro “Visualizações” abaixo). Observação: Este filtro é habilitado somente após escolher um Fluxo de Trabalho, pois os status disponíveis dependem do fluxo selecionado. (No modo Cards, esse filtro não é exibido, já que as colunas já representam cada etapa.)

• Etapa: permite filtrar tickets que estejam em uma determinada etapa do fluxo de trabalho. Disponível somente no modo Tabela (no Kanban de cards, as colunas já segregam por etapa). ⚠️ Opcional – se não selecionado, exibe tickets em todas as etapas. Se selecionado, mostra apenas os tickets na etapa escolhida (dentro do fluxo filtrado). Observação: Assim como o filtro de Status, este campo depende da seleção de um fluxo para habilitar as etapas correspondentes.

• Agente: permite filtrar por responsável específico (agente de atendimento). Você pode selecionar um ou mais agentes (usuários responsáveis pelo ticket). ⚠️ Opcional – se não preenchido, traz tickets de todos os agentes (ou sem agente atribuído), dentro do escopo definido no filtro de visualização (próximo item). Isso é útil, por exemplo, para um gerente ver tickets de um técnico específico. (Não afeta outros módulos; é apenas um filtro interno. Os agentes de atendimento são usuários do BomControle com permissão para o ServiceDesk, configurados em Cadastros de Agentes.)

• Empresa: em ambientes com múltiplas empresas/filiais, este filtro permite selecionar de quais empresas deseja ver os tickets. Pode marcar uma ou várias. ⚠️ Opcional – por padrão, se o usuário tem acesso a uma única empresa, esse filtro já vem preenchido com ela e não pode ser alterado; em ambientes multi-empresa, é necessário escolher pelo menos uma empresa para visualizar os tickets correspondentes. Impacto: garante que você visualize apenas tickets da(s) empresa(s) escolhida(s). Isso é importante pois cada empresa pode ter seu próprio fluxo de trabalho, clientes e agentes. (A empresa do ticket determina em qual contexto corporativo aquele atendimento está ocorrendo. Embora um ticket em si não movimente estoque ou finanças, associá-lo à empresa correta é fundamental para qualquer ação posterior que possa envolver outros módulos, como emitir uma cobrança de serviço – que ocorreria no módulo Financeiro da mesma empresa.)

• Ocorrência: filtra por tipo de ocorrência do ticket. Esse campo exibe uma lista em formato de árvore (categorias e subcategorias de ocorrência). Você pode selecionar um ou mais tipos de ocorrências específicos (marcando inclusive múltiplos itens nas subcategorias). ⚠️ Opcional – se nada for selecionado, lista tickets de todos os tipos de ocorrência. Exemplo: você pode filtrar apenas “Suporte > Erro no Sistema” para ver tickets classificados nessa categoria. Campos configuráveis: os tipos de ocorrência são definidos previamente no menu de Cadastro de Tipo de Ocorrência, permitindo à empresa personalizar as categorias de chamados (por exemplo: Suporte Técnico, Solicitação de Melhorias, Financeiro > Faturamento, etc.). (O tipo de ocorrência não impacta diretamente estoque ou financeiro, serve para classificação e relatórios. Porém, ele pode indicar a natureza do ticket – por exemplo, “Troca de Produto” – o que indiretamente relaciona-se a procedimentos de estoque externos ao ticket.)

• Visualizações: determina o escopo de tickets exibidos em relação ao usuário logado e aos responsáveis. Por padrão vem selecionada a opção “Meus e sem responsável”, ou seja, mostra tickets onde o usuário atual é o agente responsável ou tickets que ainda não têm responsável atribuído. Outras opções comuns incluem “Todos” (todos os tickets, conforme permissões do usuário) ou “Meus” (somente aqueles em que o usuário é responsável), podendo haver configurações adicionais conforme o sistema (como visualizar tickets da minha equipe, etc.). ✅ Obrigatório – sempre deve haver um tipo de visualização selecionado. Impacto: este filtro controla quais tickets o usuário vê: por exemplo, técnicos normalmente visualizam apenas seus próprios tickets abertos (Meus), enquanto um supervisor pode ver Todos. (Não afeta outros módulos; é apenas uma restrição de exibição de registros conforme responsabilidades.)

Ao lado dos campos de filtro, há três botões de ação rápida:

• Aplicar filtros: (botão Aplicar). Aplica imediatamente os filtros selecionados e atualiza a listagem de tickets. Fica habilitado quando há alterações nos filtros não aplicadas ainda (o sistema indica internamente quando filtros estão “pendentes” de aplicação). Clique em Aplicar sempre que ajustar os filtros para ver os resultados atualizados.

• Recarregar (Atualizar): (botão Atualizar). Reexecuta a busca com os filtros atuais, útil para atualizar a lista manualmente (por exemplo, para ver novos tickets que possam ter sido criados por outros enquanto você está na tela). Fica ativo apenas quando não há mudanças pendentes nos filtros (ou seja, repete a última consulta realizada). Se você alterar algum filtro, este botão fica desabilitado até aplicar as mudanças.

• Limpar filtros: (botão Limpar filtros). Restaura todos os filtros aos valores padrão. Ao clicar, o sistema remove seleções de cliente, agente, ocorrências etc., e retorna os campos ao estado inicial (por exemplo, visualização = “Meus e sem responsável”, data = último ano, fluxo = fluxo padrão, etc.). Só fica habilitado se algum filtro tiver sido modificado pelo usuário. Dica: use para voltar rapidamente à visão inicial padrão após fazer várias filtragens.

À direita da barra de filtros, há duas opções de apresentação dos resultados:

Figura 3 — Opções de visualização (Card/Tabela) 

• Modo Cards (Kanban): exibe os tickets em formato de quadro Kanban, organizados em colunas por etapa do fluxo de trabalho. Cada coluna representa uma etapa/status e contém cartões para os tickets nessa etapa.

• Modo Tabela: exibe os tickets em formato de grade (linhas e colunas), listando detalhes de cada ticket em cada linha.

Você pode alternar entre Cards e Tabela clicando nesses botões de modo. O modo selecionado fica destacado (botão com cor diferenciada, indicando ativo).

2.2 Visualização em Cards (Kanban)

No modo Cards, os tickets são apresentados como cartões dispostos em colunas, permitindo uma visão geral tipo Kanban do fluxo de atendimento. Cada coluna corresponde a uma etapa do fluxo de trabalho selecionado no filtro (por exemplo: Aberto, Em Andamento, Pendente, Concluído, etc., conforme definido no fluxo):

• Coluna por Etapa: No topo de cada coluna aparece o nome da etapa (ex.: Aberto, Em Andamento, Resolvido) acompanhado de um ícone representativo e de um badge com a contagem de tickets naquela etapa. Isso permite ver quantos chamados estão em cada estágio do processo. Nota: Tickets marcados como Fechados (atendimentos finalizados) não são exibidos nas colunas Kanban, pois já saíram do fluxo ativo.

• Adicionar Ticket na Etapa: Ao lado do título de cada coluna, há um pequeno botão “+”. Clique no “+” de uma coluna para adicionar um novo ticket diretamente nessa etapa do fluxo. Isso abrirá o formulário de Novo Ticket já com a etapa pré-selecionada (ver seção 3). Observação: normalmente, novos tickets começam na primeira etapa do fluxo (ex.: “Aberto”). O sistema permite criar já em etapas posteriores, caso necessário, usando esse atalho – por exemplo, registrar diretamente como “Em Andamento” se o atendimento já começou.

Figura 4 — Visualização em cards (Kanban) dos tickets, agrupados por etapa. 

• Cartões de Ticket: Cada ticket é representado por um cartão com informações resumidas:

• Identificador e Título: o topo do card mostra o ID do ticket (precedido por “#”) e o título do ticket. Exemplo: #123 – Computador não liga. O ID é numérico, único e gerado pelo sistema; o título é definido pelo usuário ao criar o ticket, indicando o assunto do chamado.

• Cliente: logo abaixo do título, aparece o nome do cliente associado ao ticket (ou solicitante principal). Caso não haja um cliente (todo ticket requer um cliente, então geralmente sempre haverá), esse campo pode repetir o título ou ficar vazio – mas em regra o cliente está definido. (Impacto: o nome do cliente aqui é apenas informativo; conhecer o cliente pode remeter o atendente a verificar informações dele em Vendas/Financeiro, mas não há integração automática nesta visualização.)

• Ícone de Comentários: um ícone de balão de diálogo Ícone Comentário
  indica quantos comentários existem no ticket. O número é exibido em um badge sobre o ícone. Ex.: “3” significa que há três comentários registrados. Dica: Isso dá uma ideia de quanto diálogo já ocorreu no chamado. Clicando no card, é possível ver os comentários na tela de detalhes.

• Indicador de Prioridade: um pequeno círculo colorido indica a prioridade do ticket. As cores correspondem a cada nível de prioridade (por exemplo: azul para Baixa, verde para Normal, amarelo para Alta, vermelho para Crítica). Ao passar o mouse, aparece a palavra da prioridade (ex.: “Alta”). Isso ajuda a identificar visualmente chamados urgentes. (Impacto: priorização visual apenas; mudar a prioridade no card — arrastando ou editando no detalhe — não movimenta outros módulos, apenas pode afetar prazos de SLA acordados.)

• Responsável (Agente): no canto do card é exibida a foto ou avatar do agente responsável pelo ticket. Se um responsável estiver atribuído, aparece a imagem do usuário; caso contrário, aparece um avatar genérico indicando “Sem responsável”. Ao passar o cursor, é mostrado o nome do responsável (ou a frase "Sem responsável"). Isso permite rapidamente ver quem está cuidando daquele chamado (ou se ninguém ainda assumiu).

• Data de Abertura e Tempo decorrido: geralmente exibido em texto como “Há X dias” (ou horas, minutos) indicando quanto tempo se passou desde a abertura do ticket. Ao passar o mouse, aparece a data exata de abertura (por exemplo, "Aberto em 10/10/2025"). Esse indicador ajuda a monitorar o tempo de atendimento. Impacto: esse tempo não afeta módulos externos, mas é útil para controle de SLA e prazos de atendimento.

• Data Prevista de Conclusão: se foi definida uma data prevista para resolução do ticket, ela aparece no card como “Previsto: DD/MM/AAAA”. Caso não haja data definida, pode constar a informação “Sem data prevista”. Isso permite ao atendente e ao cliente terem uma expectativa de quando o chamado deverá ser concluído. (Definir a data prevista não gera compromissos automáticos em outros módulos, mas pode estar alinhado a contratos do módulo Financeiro que definem prazos de SLA.)

• Ações no Card: Ao clicar em qualquer parte de um card, abre-se a tela de detalhes do ticket (ver seção 4) para visualizar informações completas e executar ações (comentar, editar campos, etc.). Além disso, é possível arrastar e soltar os cards entre colunas para atualizar a etapa do ticket de forma rápida:

• Drag & Drop: Para mudar um ticket de etapa, clique e arraste o cartão para a coluna desejada. Ao soltar na nova coluna, o sistema atualizará o status/etapa do ticket. Uma mensagem de sucesso confirmará a mudança, e uma entrada de Transição será registrada no histórico do ticket (ver seção 4.3). Regras: Só é possível arrastar se você tiver permissão de editar tickets. Algumas transições podem exigir confirmação ou dados adicionais – por exemplo, se tentar mover para uma etapa final de Fechamento, o sistema pode pedir uma confirmação. (No caso do ServiceDesk, o fechamento completo do ticket geralmente é feito via botão específico “Fechar”, conforme veremos, em vez de drag & drop.)

• Limitações de arraste: Não é permitido arrastar um ticket para um “estado inválido”. Por exemplo, não faz sentido mover manualmente para um estado inicial A Fazer se o fluxo não permitir retorno, ou mover para uma etapa fechada via Kanban. O sistema pode bloquear tais ações e exibir um aviso. De modo geral, arraste é usado para avançar o andamento normal (ex.: de Aberto para Em Andamento, etc.).

• Contador e Paginação: Na parte inferior do quadro Kanban, se houver muitos tickets, o sistema exibe o número de tickets carregados e, se houver mais além dos visíveis, um botão “Ver mais”. Clicando em Ver mais, as próximas tickets são carregados e adicionados nas colunas correspondentes.

(Os tickets fechados não aparecem aqui; para visualizar chamados já fechados, use o modo Tabela com filtro de status ou relatórios específicos.)

2.3 Visualização em Tabela

No modo Tabela, os tickets são listados em formato de grid, com cada ticket em uma linha e colunas de informações detalhadas. Esse modo permite ordenar e comparar atributos de múltiplos tickets facilmente. 

Figura 5 — Visualização em Tabela dos tickets

A tabela apresenta as seguintes colunas por padrão:

• (Selecionar): uma coluna inicial (sem título) com caixas de seleção para selecionar tickets. Permite marcar um ou vários tickets para ações em massa (como atualização simultânea – ver seção 2.4). No cabeçalho dessa coluna há uma caixa de seleção que seleciona/deseleciona todos os itens atualmente visíveis.

• Ticket (Título): coluna que combina o identificador e o título do ticket, junto com um resumo da descrição:

Exibe o ID do ticket precedido por # e o Título. Se o título for muito longo, ele é truncado (cortado) para caber, mas passando o mouse é possível ver o título completo.

Logo abaixo, em fonte menor, aparece um trecho da descrição do ticket (também truncado para uma linha). Se não houver descrição, é exibido “Sem descrição”.

O título é um link: você pode clicar no ID ou título para abrir a tela de detalhes do ticket.

Exemplo: #1234 · Impressora não imprime seguido abaixo por Trocar cartucho e testar em outra porta USB.... Nesse caso, o trecho da descrição sugere a última interação ou instrução registrada.

• Impacto: essas informações textuais não têm efeito em outros módulos, mas o título e descrição adequados facilitam o entendimento e a busca do ticket.

• Data Abertura: mostra a data de abertura do ticket. Apresenta o dia, mês e ano em que o chamado foi criado (formato DD/MM/AAAA). Essa data é importante para controle de tempo de atendimento e possíveis SLAs. (Não interage com outros módulos, mas pode ser usada em relatórios gerenciais para medir tempos de resolução.)

• Cliente: exibe o nome do cliente associado ao ticket. Se o cliente for uma pessoa jurídica, ao passar o mouse pode ser exibido também o nome fantasia e o documento (CNPJ); se pessoa física, o nome e CPF. Abaixo do nome, a coluna também mostra diretamente o documento do cliente (ou “Sem documento” se não houver CPF/CNPJ cadastrado).

Exemplo de célula:

• XYZ Corp (nome do cliente)
  Documento: 12.345.678/0001-99

Essas informações ajudam a identificar exatamente qual cliente (útil se há clientes homônimos, por exemplo).

• Impacto: o cliente em si pode remeter a informações nos módulos de Financeiro (faturas pendentes, contratos) e Vendas (pedidos relacionados), mas aqui é apenas indicativo. Se um ticket for do cliente X, qualquer venda ou cobrança deverá ser feita manualmente no módulo apropriado; o ticket não cria movimentações automáticas.

• Agente (Responsável): mostra o nome do agente responsável pelo atendimento. Na linha de baixo, exibe o e-mail do agente ou “E-mail não cadastrado” caso não haja e-mail registrado para o usuário.

Exemplo:

• João Silva
  joao.silva@empresa.com

Se nenhum responsável estiver atribuído, pode aparecer “Sem agente” e sem e-mail.

• Impacto: atribuir um responsável não impacta diretamente estoque ou finanças, mas garante que haja um dono pelo atendimento, o que é essencial para acompanhamento interno. Em relatórios de desempenho (no próprio módulo de ServiceDesk ou CRM), o responsável é usado para calcular métricas por técnico/usuário, mas não afeta outros módulos.

• Fluxo de Trabalho (Etapa): exibe em qual fluxo de trabalho e etapa o ticket está. A primeira linha mostra o nome do fluxo de trabalho (p. ex. “Suporte TI”), e abaixo é exibido o nome da etapa atual dentro desse fluxo (p. ex. “Em andamento” ou “Aguardando Peças” etc., conforme configuração).

Se não houver fluxo/etapa (o que não ocorre, já que são obrigatórios), apareceria “Sem fluxo de trabalho” ou etapa “...”.

Essa coluna permite entender rapidamente o estágio do chamado no processo definido.

• Impacto: o fluxo e etapa são internos do módulo ServiceDesk. Mudar de etapa não produz efeitos diretos em outros módulos, mas indica o progresso do atendimento. Por exemplo, um ticket na etapa “Aguardando Aprovação do Cliente” pode sugerir que em vendas uma proposta foi enviada – mas isso depende da ação do usuário, não ocorre automaticamente.

• Prioridade: indica a prioridade do ticket em texto e cor. É apresentada como uma etiqueta colorida com o nome da prioridade em letras maiúsculas (por exemplo: “ALTA”, “NORMAL”). As cores seguem um padrão:

• Baixa prioridade aparece em azul claro (rótulo informativo),

• Normal em cinza/neutro,

• Alta em laranja/âmbar (rótulo de atenção),

• Crítica em vermelho (rótulo de urgência).

• Essa visualização facilita identificar chamados críticos na lista.

• Impacto: como mencionado, a prioridade isoladamente não altera nada em estoque/financeiro. Entretanto, um ticket crítico pode demandar, por fora, ações mais rápidas como comprar peças urgentes (estoque) ou acionar contratos de suporte premium (financeiro). Essas consequências são gerenciadas pelo time de suporte manualmente; o sistema em si não movimenta estoque por mudar a prioridade, por exemplo.

• Status: mostra o status atual do ticket (A Fazer, Fazendo, Parado, Feito, etc. – são as etapas-chave do fluxo, geralmente com nomes amigáveis). Além do texto do status, essa coluna inclui indicadores de situação:

  • Ícones à direita podem aparecer: um ícone de lixeira vermelha Ícone Excluído se o ticket foi marcado como Excluído (nesse caso o registro estaria apenas visível em listagens administrativas), ou um ícone de setas circulares Ícone Reaberto se o ticket foi Reaberto após ter sido fechado anteriormente. Esses ícones aparecem somente quando aplicáveis, com tooltip explicativo (“Excluído” ou “Reaberto”).

• Barra de progresso: logo abaixo do nome do status, há uma barra de progresso indicando o percentual de tempo decorrido em relação ao SLA (se houver um SLA definido para o ticket). Por exemplo, pode mostrar uma barra preenchida 50% em azul, indicando que 50% do tempo de resolução acordado já se passou. Ao passar o mouse, aparece a porcentagem exata. Se o ticket não tiver SLA ou prazo definido, essa barra pode permanecer vazia ou em 0%. Observação: Em alguns contextos, essa barra pode também indicar porcentagem de subtarefas concluídas, mas no ServiceDesk do BomControle geralmente está ligada ao tempo do SLA.

• Impacto: o status em si é informativo do andamento do ticket. Estar “Feito” ou “Fechado” indica conclusão, mas não gera nenhuma baixa de estoque ou financeiro automaticamente – significa apenas que o atendimento foi finalizado no âmbito do suporte. Qualquer ação decorrente (como faturar horas de serviço, ou movimentar um item substituído em estoque) deve ser feita manualmente nos módulos apropriados. A barra de SLA não interage com outros módulos; serve para controle interno de cumprimento de prazos de atendimento.

• Ações: a última coluna contém botões para ações rápidas em cada ticket:

  • Editar: abre diretamente a tela de detalhes do ticket em modo de edição. É equivalente a clicar no título do ticket.

  • Histórico: abre um modal com o histórico de alterações do ticket (quem mudou status, prazos, responsável, etc., e quando). Essa funcionalidade permite ver um log resumido de alterações de campos do ticket, sem precisar entrar na timeline detalhada. Útil para auditoria rápida.

• Permissões: se o usuário não tiver permissão de editar tickets, o botão Editar não executará a ação (um aviso “Não Autorizado” é exibido). O botão Histórico pode estar disponível para consulta mesmo sem permissão de edição.

• Impacto: essas ações são restritas ao módulo ServiceDesk. Ver o histórico ou editar um ticket não toca nos módulos de estoque/financeiro – exceto pelo fato de que editar certos campos (como cliente, responsável, etc.) muda informações que podem constar em relatórios gerenciais e dashboards, mas nada é lançado fora do sistema de tickets.

A visualização em tabela suporta rolagem e paginação automática. Você pode ordenar os tickets clicando nos cabeçalhos de algumas colunas (se habilitado – por padrão, muitos campos de texto e status não são ordenáveis diretamente no cliente; a ordenação principal segue o filtro/pesquisa ou ordenação padrão por data de criação). Para encontrar tickets específicos, muitas vezes o modo Tabela aliado ao campo de busca textual é o mais eficaz.

2.4 Barra de ações no rodapé da listagem

No rodapé da tela de listagem há uma barra de ações fixa, que disponibiliza algumas funções úteis:

Figura 6 — Barra de ações da listagem de tickets

• Exportar: botão de exportação (aparece como Exportar ou um ícone de download) – permite exportar a listagem de tickets para um arquivo, geralmente em formato Excel (XLS/CSV). Disponível apenas no modo Tabela. Ao clicar em Exportar, o sistema gera um arquivo contendo as colunas e dados atualmente filtrados. Você pode usar isso para análises externas ou relatórios personalizados. Observação: respeita os filtros aplicados – por exemplo, se estiver filtrado para “Aberto este mês, Alta prioridade”, o Excel conterá somente esses registros. Impacto: a exportação é apenas leitura de dados; não modifica nada no sistema nem em outros módulos.

• Atualização em massa: botão Atualização em massa – permite editar vários tickets simultaneamente. Disponível apenas no modo Tabela. Para utilizá-lo, selecione dois ou mais tickets marcando as caixas na coluna de seleção; em seguida, o botão ficará ativo. Ao clicar, abre-se o modal de Atualização de tickets em massa.

No modal de atualização, você terá opções de alterar certos campos para todos os tickets selecionados de uma só vez. É possível, por exemplo, marcar que deseja mudar o Responsável e selecionar um novo usuário – ao confirmar, todos os tickets selecionados terão o responsável alterado para aquele usuário. Os campos disponíveis para alteração em massa incluem: Título, Tipo de Ocorrência, Prioridade, Responsável (Agente), Solicitante, Cliente, Seguidores e Etapa.

Para cada campo, há uma caixa de seleção “Mudar X” que você deve marcar e então escolher o novo valor. Os valores não marcados permanecem inalterados nos tickets.

Exemplo: Você selecionou 5 tickets e quer atribuir todos ao agente João e marcá-los como Prioridade Alta. No modal, marca “Mudar Responsável” e escolhe João; marca “Mudar Prioridade” e escolhe Alta; deixa os demais campos desmarcados. Ao salvar, os 5 tickets são atualizados de uma vez com essas mudanças.

• Regras e impactos: a alteração em massa respeita as mesmas validações de quando você edita cada ticket individualmente. Por exemplo, não é permitido remover o cliente de um ticket – portanto o modal nem oferece essa opção, apenas trocar para outro. Ao alterar a Etapa em massa, todos os tickets vão para aquela nova etapa (desde que pertençam ao mesmo fluxo de trabalho; o sistema usa o fluxo filtrado como base). Vale destacar que nenhuma dessas mudanças aciona processos externos automaticamente – por exemplo, se você definir vários tickets para etapa "Fechamento", isso não gera uma nota fiscal nem nada assim, apenas move os atendimentos de fase. Contudo, use com cuidado, pois pode impactar prazos internos (vários tickets fechados juntos podem indicar finalizações simultâneas, etc.). Todas as alterações feitas aparecem no histórico de cada ticket individual (com indicação de que foi uma atualização em massa).

Permissões: somente usuários com permissão de edição de tickets conseguem usar essa função. Se um ou mais tickets selecionados não puderem ser editados (ex.: estiverem fechados e seu perfil não permita reabrir), o sistema informará ou ignorará essas entradas.

• Novo ticket: botão Novo ticket (verde, ícone de “+”) – adiciona um novo ticket. Este botão está sempre disponível (tanto no modo Cards quanto Tabela, inclusive é duplicado no topo direito da listagem em modo Cards para conveniência). Clicando nele, abre-se o modal de cadastro de um novo ticket (veja detalhes na seção 3). Use-o para registrar um novo chamado de suporte/serviço.

3) Tela de Cadastro de Novo Ticket

Ao clicar em Novo ticket, abre-se o formulário para cadastrar um novo ticket do ServiceDesk. Esse formulário geralmente aparece em formato de modal (janela sobreposta) ao conteúdo da listagem. Ele está dividido em duas seções: Dados Básicos do ticket e Detalhes do ticket. 

Figura 7 — Tela para criação do novo ticket 

Na coluna da esquerda (Dados Básicos), preenchemos as informações principais de identificação e descrição; na coluna da direita (Detalhes), definimos informações adicionais como datas, vinculações e responsáveis. A seguir, detalhamos cada campo do formulário de novo ticket, incluindo regras de preenchimento, impactos e se o campo é configurável:

3.1 Dados Básicos do Ticket

• Título do Ticket: campo de texto para o título ou assunto do chamado. ✅ Obrigatório – deve ser preenchido com um resumo claro do problema ou solicitação. É recomendável algo breve e descritivo (por exemplo: “Erro ao emitir NF-e” ou “Solicitação de upgrade de plano”). Validação: até 256 caracteres; não pode ficar vazio. Impacto: o título identifica o ticket em listagens e notificações. Não há efeito em estoque/financeiro, mas um bom título facilita a busca e o entendimento do chamado. (Dica: Use palavras-chave do problema no título. O título pode ser usado como referência em conversas com o cliente, mas não gera ações automáticas.)

• Descrição: campo de texto rico (aceita formatação) para detalhamento do ticket. ✅ Obrigatório – deve conter a descrição completa do ocorrido, erro ou solicitação. Aqui o usuário pode inserir todas as informações relevantes, passo a passo do problema, prints (copiando e colando imagens, se suportado, ou anexando separadamente), códigos de erro, etc. Não há limite rígido de caracteres, porém textos muito longos podem ser menos objetivos; tente ser claro e conciso. Validação: o sistema exige que haja algum conteúdo na descrição – se você tentar salvar sem descrição, exibirá um erro “A Descrição é obrigatória.” Impacto: a descrição não interage automaticamente com outros módulos, mas é o coração do atendimento – base para o técnico entender e solucionar. Se o ticket estiver relacionado a um item de estoque ou financeiro, é bom mencionar aqui (por exemplo: “Produto XYZ com número de série 123 apresentando defeito” ou “Fatura 456 com valor incorreto”). Essa informação contextual ajudará o atendente a agir nos módulos pertinentes, embora o BomControle não extraia dados automaticamente do texto.

• Anexos: seção para adicionar arquivos/imagens ao ticket. Você pode arrastar e soltar arquivos ou clicar em “procurar” para selecionar um arquivo do seu computador. ⚠️ Opcional – use para incluir capturas de tela do erro, PDFs, planilhas ou qualquer documento relevante ao chamado.

Ao adicionar, as miniaturas dos arquivos aparecem listadas. Você pode remover um anexo clicando no ícone de lixeira no thumbnail antes de salvar.

Tamanho e tipo: O sistema pode impor um limite de tamanho por arquivo (por exemplo, se imagens ultrapassarem certo MB, aparecerá um alerta “A(s) imagem(ns) ultrapassam o tamanho limite!”). Também somente tipos permitidos podem ser anexados (se tentar um formato inválido, verá “Tipo de arquivo inválido!”). Tipos comuns permitidos: imagens (PNG, JPG, etc.), PDF, documentos do Office, texto, etc.

• Impacto: anexos ficam associados ao ticket e visíveis na timeline dele. Não há efeito externo, mas, por exemplo, um PDF anexado de uma nota fiscal pode requerer que o financeiro olhe aquela nota – isso é um processo manual. Observação: Por padrão, anexos adicionados via formulário são considerados internos (visíveis apenas para a equipe) até que você eventualmente compartilhe no comentário. Mas no ServiceDesk, anexar aqui no cadastro inicial os tornará disponíveis no ticket e possivelmente visíveis ao cliente se o cliente acessar o portal do ticket (dependendo da política de privacidade do chamado). Na dúvida, trate anexos como potencialmente compartilháveis. Você sempre poderá marcar um anexo como privado ou público após salvar, na timeline do ticket (ver seção 4.4).*

(A seção de Dados Básicos foca no que está sendo solicitado ou reportado, por quem e com quais evidências. Preencha essas informações com cuidado, pois elas serão usadas pelos agentes e também podem ser enviadas ao cliente em confirmações de abertura de chamado.)

3.2 Detalhes do Ticket

• Data de Abertura: data em que o ticket foi aberto/registrado. Por padrão, ao criar um novo ticket, este campo já vem preenchido com a data e hora atual (momento do cadastro). ⚠️ Opcional (editável) – normalmente você não precisa alterar; contudo, se estiver cadastrando no sistema um chamado que na prática chegou anteriormente (por exemplo, um e-mail recebido ontem que você está formalizando agora), é possível ajustar a Data de Abertura para a data real de início do chamado. Isso garante que métricas de SLA considerem o momento correto. Como alterar: clique no campo para abrir o seletor de data e escolha a data desejada; pode também ajustar a hora se necessário (um campo de hora aparecerá ao lado quando uma data é selecionada). Impacto: essa data é usada para calcular tempos de resolução e aparece nas listagens. Alterar a data de abertura não tem efeito em módulos externos, mas impacta relatórios do ServiceDesk (um ticket com data retroativa contará como aberto na data passada). Use com critério – geralmente apenas para fidelidade histórica. (Este campo não pode ser alterado após salvar o ticket, a não ser que você tenha permissões especiais via banco de dados; na interface, uma vez criado, a data de abertura fica fixa.)

• Empresa: seleção da empresa à qual o ticket pertence. Se você tem apenas uma empresa no sistema, ela já estará selecionada e o campo pode nem permitir mudança. Em cenário multi-empresa, escolha a empresa correta antes de prosseguir. ✅ Obrigatório – um ticket sempre deve estar vinculado a uma empresa (mesmo que você atenda múltiplas empresas, cada chamado pertence a uma unidade empresarial específica). Impacto: define o contexto corporativo do chamado. Isso afeta quais clientes e agentes estarão disponíveis para seleção (o combo de Cliente filtra por empresa). Além disso, qualquer ação decorrente (por exemplo, emissão de nota fiscal se for um serviço faturável) deverá ser feita na empresa indicada aqui. Nota: Após o ticket criado, a empresa não deve ser alterada, por isso revise antes de salvar. Campos configuráveis: as empresas são cadastradas na base do BomControle (módulo Empresas); aqui apenas selecionamos entre as que o usuário tem acesso.

• Cliente: o cliente para o qual o ticket está sendo aberto. ✅ Obrigatório – selecione o cliente solicitante do atendimento. Ao clicar, será exibida a lista de clientes cadastrados (do CRM do BomControle). Você pode digitar para buscar pelo nome. Regra: esse campo só é habilitado após escolher a Empresa, pois lista apenas clientes daquela empresa. Impacto: o cliente define quem está solicitando o serviço/problema. Isso é fundamental porque vincula o ticket a contratos de suporte (se houver), ao histórico daquele cliente e permitirá enviar comunicações.

Se o cliente selecionado estiver marcado como inadimplente (possui pendências financeiras no BomControle), o sistema exibirá um ícone de alerta vermelho (⚠️) ao lado do nome no rótulo “Cliente”. Isso serve para alertar o atendente de que o cliente tem alguma pendência (por exemplo, faturas vencidas). Impacto: não impede a abertura do ticket, mas é uma informação relevante – a equipe de atendimento pode priorizar diferente ou cobrar a regularização. (Esse status de inadimplência vem do módulo Financeiro; não muda nada automaticamente no atendimento, mas talvez haja políticas internas de suspender suporte para inadimplentes, a critério da empresa.)

• Campos configuráveis: os clientes são gerenciados no módulo de Cadastro de Clientes do BomControle. Caso precise adicionar um novo cliente rapidamente, clique no botão de adicionar (geralmente um “+”) ao lado do campo – isso abrirá um cadastro rápido de cliente, desde que você tenha permissão. Após cadastrar, selecione-o para o ticket.

• Observação: Este campo não pode ser deixado em branco. Todos os tickets precisam ter um cliente – mesmo que o solicitante seja um anônimo inicialmente, recomenda-se cadastrar um cliente genérico ou o próprio nome da pessoa. Isso porque futuramente, se for necessário gerar uma cobrança ou referenciar esse atendimento em uma venda, haverá um cliente vinculado.

• Responsável: o agente responsável pelo ticket (também chamado de técnico ou atendente designado). ⚠️ Opcional – você pode atribuir desde já um responsável interno ou deixar em branco (nesse caso, o ticket fica “sem responsável”, acessível para que alguém assuma depois).

Ao clicar, é listada a equipe de agentes disponíveis. Por padrão, lista todos os usuários do ServiceDesk (ou equipe designada) da empresa selecionada. Se você escolheu um cliente primeiro, o sistema pode filtrar os agentes vinculados a atender aquele cliente (dependendo da parametrização), mas via de regra exibe todos os agentes de suporte.

Você pode cadastrar um novo agente rapidamente via botão “+” se habilitado (isso abre um cadastro rápido de usuário do tipo agente).

• Impacto: definir um responsável não aciona nada automaticamente fora do módulo de ticket, porém internamente significa que aquela pessoa agora “deve” atender o chamado. Notificações de novo ticket podem ser enviadas ao responsável (conforme configuração de alertas por e-mail), e ele passa a ver esse ticket em sua lista de “Meus Tickets”. Não há reflexo em estoque ou financeiro. (Entretanto, se o atendimento requer alguma ação nesses módulos, o responsável será quem provavelmente executará ou solicitará – ex.: o responsável decide que precisa acionar compras/estoque para enviar uma peça ao cliente.)

Dica: Se você deixar sem responsável, o ticket ficará visível para todos no filtro “sem responsável” – é bom atribuir alguém o quanto antes para não cair no esquecimento.

• Solicitante: a pessoa (usuário final) que solicitou ou abriu o chamado, associada ao cliente. ⚠️ Opcional – use este campo quando o cliente (empresa) tiver um contato específico que fez a solicitação.

Ao clicar, o sistema lista os usuários convidados do portal do cliente ou contatos do cliente. Ou seja, pessoas vinculadas ao cadastro daquele cliente que podem interagir via portal de atendimento.

Se o cliente for uma empresa com vários contatos, você pode escolher qual pessoa reportou o problema. Se for um cliente pessoa física, muitas vezes o solicitante será o próprio.

• Impacto: o solicitante, se definido, será considerado o contato para comunicação. Por exemplo, se o sistema envia notificações de atualização de ticket, elas podem ser endereçadas ao e-mail do solicitante. Além disso, no Portal do Cliente (caso sua empresa utilize), o solicitante pode acompanhar o ticket com seu login. Esse campo não afeta módulos como Financeiro diretamente – serve para gestão do relacionamento dentro do atendimento.

Observação: Este campo só é habilitado após escolher um Cliente. Se nenhum cliente for selecionado (o que não pode acontecer porque é obrigatório), ou se o cliente não tiver usuários de portal cadastrados, você pode deixar sem preenchimento – nesse caso, assume-se que o contato é o próprio responsável pelo cliente ou o contato padrão. Você pode cadastrar um novo usuário solicitante (convidado) se necessário, em geral através do módulo de clientes ou via botão rápido se disponível.

• Tipo da Ocorrência: categoria do chamado dentro da classificação de ocorrências. ⚠️ Opcional – indique aqui a natureza do ticket conforme as categorias definidas pela empresa.

Ao clicar, abre-se uma seleção em árvore (categorias e subcategorias). Escolha o tipo que mais se aproxima do tema do ticket. Por exemplo: Suporte Técnico > Software > Erro Sistema.

Você deve selecionar um item de nível mais baixo (folha) – a interface só permite concluir a seleção em subcategoria, não em pastas de nível superior. Então, expanda as categorias até encontrar a opção específica e clique nela.

• Impacto: essa classificação é usada para relatórios e possivelmente para direcionamento interno. Por exemplo, tickets do tipo “Infraestrutura > Servidor” podem ser automaticamente atribuídos a um time específico via regras internas (automação), ou gerar estatísticas de quantos chamados de cada tipo ocorrem. Não há integração direta com estoque ou financeiro; porém, alguns tipos podem indicar ligação indireta – e.g., um tipo “Solicitação de Reposição de Peça” pode implicar que haverá um pedido de peça no estoque, mas isso não acontece sozinho: o agente terá que realizar a ação no módulo de Estoque separadamente.

• Campos configuráveis: a árvore de tipos de ocorrência é definida no cadastro de Tipos de Ocorrência do ServiceDesk. Novos tipos podem ser adicionados pelo administrador conforme a necessidade do negócio. Durante o cadastro de um ticket, você também pode ter a opção de adicionar rapidamente um novo tipo (caso tenha permissão) ao digitar um nome não existente – o sistema perguntará se deseja criar. Essa facilidade é controlada por permissão; se você não puder criar, limite-se aos tipos existentes.

• Prioridade: nível de urgência do ticket. ⚠️ Opcional – se não alterado, o sistema atribui uma prioridade padrão (geralmente Normal).

Selecione a prioridade entre as opções: Baixa, Normal, Alta, Crítica. Cada uma indica a importância e/ou tempo de resposta esperado: Crítica é algo urgentíssimo, Baixa é algo sem pressa, etc.

• Impacto: a prioridade pode estar associada a SLAs diferentes. Por exemplo, contratos de suporte podem prever que chamados Críticos sejam resolvidos em até 4 horas, enquanto Baixos podem em 48 horas. O BomControle pode calcular a data limite de atendimento (SLA) com base nisso se houver essa configuração no módulo de contratos. Mesmo que não haja automação de SLA configurada, a prioridade serve para fila de trabalho – agentes priorizam críticos primeiro. (Não gera movimentação automática em outros módulos – ex.: não faz compra emergencial no estoque sozinho, mas um ticket marcado como Crítico pode levar um gerente a tomar ações rápidas manualmente em outras frentes.)

Você pode mudar a prioridade depois de criar o ticket também, caso reavalie a urgência.

Observação: este campo não aceita nulo – sempre há uma prioridade definida (se você não escolher, ficará a padrão Normal). Então do ponto de vista de preenchimento é tratado como obrigatório pelo sistema, embora o usuário possa não interagir com ele.

• Fluxo de Trabalho: seleção do fluxo de trabalho específico que será seguido por este ticket. ✅ Obrigatório – deve ser escolhido antes de salvar. Por padrão, se você não selecionar nada, o sistema automaticamente atribui o fluxo de trabalho padrão do ServiceDesk para a empresa (ao abrir o formulário, ele já tenta carregar esse padrão).

Se houver mais de um fluxo disponível (por exemplo, fluxos diferentes para tipos de atendimento distintos: Suporte Técnico, ServiceDesk Financeiro, Projetos, etc.), escolha aquele apropriado ao ticket.

• Impacto: definir o fluxo determina quais etapas/status o ticket terá. Não afeta outros módulos diretamente, mas é crucial internamente – o fluxo define as “regras do jogo” daquele chamado (que etapas até fechar, quem aprova o quê, etc.). Escolher um fluxo errado poderia desorientar o processo (ex.: não use o fluxo “Financeiro” para um problema de TI, pois as etapas não farão sentido). Campos configuráveis: fluxos de trabalho são configurados pelo administrador no Cadastro de Fluxo de Trabalho – ServiceDesk. Cada fluxo tem um conjunto de etapas vinculado. Aqui, o usuário final só escolhe dentre os existentes; não pode criar fluxos novos na hora.

• Nota: Este campo, uma vez salvo, não era editável nas versões antigas; contudo, atualmente o BomControle permite alterar o fluxo em tickets já abertos (no detalhe, se necessário, ver seção 4.6). No cadastro inicial, garanta selecionar o mais adequado para evitar retrabalho.

• Etapa: a etapa inicial do ticket dentro do fluxo selecionado. ⚠️ Opcional – normalmente ao escolher o fluxo, o ticket já assume a primeira etapa do fluxo automaticamente (por exemplo, “Aberto” ou “Novo”). Você pode, se tiver necessidade, selecionar manualmente outra etapa inicial aqui.

O campo de Etapa lista as etapas pertencentes ao fluxo escolhido. Ele agrupa por seções (pode aparecer o nome do fluxo ou fases agrupadoras) mas essencialmente você verá os nomes das etapas.

Caso você esteja cadastrando o ticket diretamente a partir de uma coluna Kanban (via botão "+" do card em determinada etapa), repare que o sistema já veio com o fluxo e a etapa preenchidos conforme aquela coluna. Você pode manter ou alterar antes de salvar.

• Impacto: definir a etapa de partida diferente da inicial padrão pode indicar que o ticket já está entrando no processo em um ponto avançado. Por exemplo, se você marcar “Em andamento” ao criar, significa que o ticket não passou pelo estado Aberto -> Em andamento; ele já nasce em andamento (talvez porque você já começou o trabalho antes mesmo de registrar formalmente). Isso não aciona nada externo, mas no histórico do ticket será registrado nessa etapa desde o início. Atenção: algumas etapas posteriores podem exigir campos extras preenchidos – o sistema normalmente pediria durante uma transição. Se você criar já nessa etapa via formulário, certifique-se de fornecer as informações necessárias de outra forma para não violar o processo. (Ex.: se existe uma etapa "Aguardando Peças" que requer indicar qual peça, o sistema pode não deixar mover sem a informação. Criando direto nela, possivelmente você terá que editar o ticket após salvar para incluir esses dados).

Geralmente, recomenda-se deixar o ticket iniciar na primeira etapa padrão e evoluir naturalmente. Utilize a seleção manual de etapa inicial somente em casos justificados.

• Últimos tickets deste cliente: logo abaixo dos campos acima, o formulário exibe uma listagem dos últimos tickets abertos para o mesmo cliente selecionado.

Figura 8 - Últimos ticket do cliente 

Se nenhum cliente foi selecionado ainda, é mostrada uma mensagem: “Selecione um cliente”. Assim que você escolher o cliente, o sistema busca os últimos, por exemplo, 5 tickets desse cliente.

Se o cliente não tem histórico de chamados, aparece a mensagem “Cliente sem histórico de tickets”. Caso tenha, cada linha exibirá um link resumido de um ticket anterior: mostra um badge de prioridade colorido (indicando a prioridade daquele chamado histórico), o ID e o título do ticket anterior. Você pode passar o mouse para ver detalhes (um tooltip pode mostrar informações adicionais) e pode clicar em um desses itens – ele será aberto em outra aba do navegador para sua consulta, sem fechar o cadastro atual.

• Utilidade: isso permite que, ao registrar um novo chamado, você saiba rapidamente se aquele cliente teve problemas recentes semelhantes. Por exemplo, você pode notar que há 2 tickets anteriores sobre “Impressora não imprime” para o mesmo cliente. Isso pode indicar um padrão ou fornecer pistas para a solução.

• Impacto: esta seção é apenas informativa. Consultar ou não os últimos tickets não muda nada no ticket que você está abrindo. Mas em termos de atendimento ao cliente, é uma ótima prática verificar histórico para evitar respostas duplicadas ou entender o contexto (especialmente se o chamado atual for reincidência de outro já resolvido).

Dica: se um ticket anterior relacionado estiver Fechado e o cliente abriu novamente o mesmo problema, você talvez queira, em vez de criar um totalmente novo, reabrir o antigo. Porém, isso depende da política da empresa; muitas preferem um novo ticket mesmo. De toda forma, saber do histórico ajuda na decisão.

Após preencher todos os campos necessários (lembrando: Título, Descrição, Empresa e Cliente são obrigatórios; os demais conforme necessidade), clique em Salvar. O sistema realizará validações: - Campos obrigatórios vazios serão destacados em vermelho e impede o salvamento. - Se tudo OK, o ticket será criado e você verá uma mensagem de sucesso (ex.: “Ticket #1234 salvo com sucesso!”). O modal fechará, retornando à listagem (e o novo ticket já aparecerá na lista conforme os filtros).

No formulário há também um botão Cancelar, que fecha o modal sem criar o ticket (descarta os dados inseridos).

Figura 9 - Opção “Criar Outro”

Por fim, note a opção “Criar outro” com uma caixa de seleção ao lado do botão Salvar. Se você marcar Criar outro antes de salvar, ao clicar em Salvar o sistema salvará este ticket e automaticamente limpará o formulário para permitir cadastrar um novo, mantendo o modal aberto. Isso é útil quando você precisa lançar vários tickets em sequência. Se esta opção não estiver marcada (comportamento padrão), ao salvar um ticket o modal será fechado.

Regras de preenchimento e impactos gerais no cadastro: Nenhum campo do cadastro de ticket dispara ações automáticas fora do módulo de ServiceDesk no momento da criação. Ou seja, criar um ticket não gera movimentação de estoque, financeiro ou vendas por si só. O que importa é registrar corretamente as informações para que o atendimento possa ser conduzido. Qualquer impacto em outros módulos ocorrerá indiretamente, pela atuação dos agentes conforme o que foi registrado: - 

Exemplo: se no Tipo de Ocorrência você indicar “Pedido de peça em garantia”, possivelmente o agente terá que abrir um processo no Estoque para enviar uma peça. Mas isso será feito manualmente no módulo de Estoque (por meio de uma saída de estoque ou RMA) e não automaticamente pelo ticket. - Exemplo 2: se o Cliente possui um contrato de suporte válido no Financeiro, a existência do ticket pode consumir horas desse contrato – mas o controle desse consumo é feito via relatórios ou apontamentos manuais. O ticket em si não debita nada do contrato de forma automática, a não ser que haja alguma integração configurada (por ora, não há cobrança gerada só por abrir o chamado).

Após o cadastro, o próximo passo normalmente é acompanhar e gerenciar o ticket na tela de detalhes, onde há recursos de comunicação e atualização do chamado. Veremos isso a seguir.

4) Tela de Detalhamento do Ticket

A tela de detalhes do ticket é acessada quando você clica em um ticket (seja pelo card no Kanban ou pelo link/ícone na lista em tabela). Nessa tela, você pode ver todas as informações do chamado, atualizar campos, adicionar comentários, interagir com o cliente (via e-mail) e realizar outras ações até o fechamento do ticket. 

Figura 10 - Tela de detalhamento do Ticket

A tela de detalhe é dividida em várias seções e áreas funcionais:

• Cabeçalho do ticket: informações principais no topo, incluindo ID, título editável, dados do cliente/contato, datas e botão para novo ticket.

• Linha de status e participantes: logo abaixo do cabeçalho, mostrando solicitante, responsável, SLA, seguidores e prioridade, com possibilidade de ações rápidas (como mudar prioridade).

• Barra de etapas (status): representação do fluxo de trabalho em formato de botões, permitindo alterar o status/etapa do ticket.

• Timeline (Histórico de interações): painel central esquerdo listando todas as atividades do ticket (comentários, e-mails, mudanças de status, etc.), com filtros para visualizar tipos específicos de interação.

• Botões de ação de interação: acima da timeline, botões para inserir Comentário, Enviar E-mail, Adicionar Tarefa (Evento) e Anexar Arquivo, e possivelmente Adicionar Proposta.

• Painel de detalhes à direita: painel lateral (que pode ser ocultado/exibido) com seções de Dados Básicos do ticket (campos similares aos do cadastro, que podem ser revisados e editados após criação) e Últimos tickets do cliente (histórico resumido, como já visto).

• Barra de ações no rodapé: botões para Voltar, Imprimir, Excluir, Reabrir ou Fechar, e Concluir.

A seguir, explicaremos cada uma dessas partes em detalhes, incluindo a origem das informações apresentadas e as ações disponíveis em cada seção.

4.1 Cabeçalho e informações iniciais do ticket

No topo da tela de detalhes, há uma barra com o título do módulo e as principais identificações do ticket:

Figura 11 — Cabeçalho do ticket mostrando ID, título editável, contato do cliente, data de criação e data prevista.

• Título com ID: é exibido como Ticket #X – [Título do Ticket]. Por exemplo: Ticket #1024 – Computador não liga. O ID é o número único do ticket e o título é editável inline. Ao lado do título há um ícone de lápis que indica a possibilidade de edição:

Clique no ícone de editar (lápis) para permitir a edição do título. O título se torna um campo de texto editável. Faça a alteração desejada e então você terá duas opções ao lado: um botão de Salvar alteração e um de Cancelar alteração .

• Validações: o título continua com limite de 256 caracteres e não pode ficar vazio. Se tentar salvar em branco, o sistema não permite.

Ao salvar, o novo título será atualizado e o ID permanece o mesmo. Uma entrada de Histórico será registrada indicando que o título foi alterado (ex.: “Título alterado de ‘Computador não liga’ para ‘Computador não liga - fonte queimada’ em 11/10/2025 por Maria”).

• Impacto: mudar o título não afeta outros módulos; é meramente uma correção ou atualização descritiva. Pode ajudar o cliente (se ele tem acesso via portal, verá o novo título) e relatórios internos. Não gera notificações automáticas a não ser que esteja configurado (geralmente não para título). Em todo caso, evite mudanças drásticas que possam confundir – se alterar, comente no ticket explicando, se for relevante.

• Contato (Cliente): ao lado do título (se o layout comportar em uma mesma linha ou próximo) pode aparecer um campo de seleção de Contato por Cliente. Esse é o campo Contato vinculado ao cliente do ticket, que permite escolher um contato específico do cliente relacionado a este atendimento.

Ele aparece como um dropdown mostrando possivelmente o nome de uma pessoa de contato. Por exemplo, se o cliente é “Empresa XYZ”, pode estar selecionado “João (TI Empresa XYZ)”.

Você pode alterar esse contato se necessário – por exemplo, suponha que inicialmente o solicitante era João, mas agora quem está tratando pelo cliente é Maria, você pode trocar o contato para Maria. Essa lista de contatos puxa do cadastro de contatos associados ao cliente (no CRM do BomControle).

• Impacto: esse contato é usado principalmente ao enviar e-mails pelo sistema (ver seção de E-mail). Quando você clicar em Enviar Email dentro do ticket, por padrão o destinatário será o contato selecionado aqui. Portanto, mantenha atualizado para garantir que as comunicações vão para a pessoa certa. Fora isso, serve como referência interna de com quem do lado do cliente estamos lidando. Não gera ações em módulos externos.

• Data de criação: no cabeçalho é exibida a data e hora em que o ticket foi criado. Aparece como “Data de criação: DD/MM/AAAA HH:MM” em um pequeno texto. É somente leitura, para referência. (Impacto: nenhum além de informação; útil para calcular tempos.)

• Data Prevista (SLA): também no cabeçalho, costuma haver um campo Previsto com uma data (e possivelmente hora) que representa o prazo de solução estimado para o ticket.

Inicialmente, pode estar vazio (indicado por “Sem data prevista”). Se um SLA automático foi calculado (por exemplo, devido à prioridade e a um contrato, o sistema pode preencher aqui um prazo), ele será exibido.

Você pode editar a data prevista clicando no ícone de lápis próximo a ela. Assim como no título, surgem campos para escolher uma data e hora. Ajuste para o novo prazo e salve (ícone ✔️).

Alterar a data prevista insere um Histórico do tipo “Histórico” indicando a mudança de data prevista.

• Impacto: a data prevista é uma indicação para o cliente e para a equipe de suporte sobre até quando o chamado deve ser resolvido. Não aciona nada por si só (o sistema não fecha automaticamente nem gera multa se passar do prazo – isso seria gerenciado via contratos offline). Contudo, essa data é considerada no cálculo de SLA cumprido/violado. Por exemplo, se passar do previsto e não fechado, o sistema marca internamente como SLA vencido (indicando em vermelho o SLA na linha de participantes, ver a seguir). Portanto, atualizar esse campo pode ser necessário se houve renegociação de prazo com o cliente. *(Nenhum módulo externo é afetado diretamente, mas honrar ou não o prazo pode ter implicações contratuais que o financeiro cobra separadamente, caso previsto em contrato.)

• Botão "Novo ticket": no canto superior direito, há um botão verde + Novo ticket. Esse atalho permite abrir o formulário de novo ticket diretamente a partir da tela de detalhe atual, caso você precise registrar um outro chamado enquanto consulta este. Ao clicar, o modal de novo ticket aparece (sem fechar a tela atual). É útil para multitarefa. (Não confunda: não cria nada automaticamente relacionado; é apenas conveniência de navegação.)

4.2 Linha de participantes e status do atendimento

Logo abaixo do cabeçalho, há uma linha com informações de participantes do ticket e indicadores de status:

Figura 12 — Indicadores de participantes e status do atendimento

• Solicitante: exibe “Solicitante:” seguido do avatar e nome do solicitante do ticket (se definido). O avatar é uma pequena imagem em círculo:

Se o cliente/solicitante possui foto no portal (ou associada ao usuário convidado), essa foto aparece. Caso contrário, aparece um ícone genérico de usuário.

Ao passar o mouse sobre a imagem, aparece o nome completo do solicitante. Se não houver um solicitante especificado, pode aparecer apenas “Solicitante: -” ou nenhum nome (nesse caso possivelmente o avatar genérico sem tooltip significativo).

Uso: esse campo é informativo, lembrando quem, dentro do cliente, abriu o chamado. Não é editável aqui (para alterar solicitante, edite no painel de detalhes do ticket, seção Dados Básicos, ou no portal do cliente).

• Impacto: Nenhum direto fora do ServiceDesk. Serve para comunicação – por exemplo, ao responder via e-mail, saber para quem dirigir. Também no portal do cliente apenas o solicitante (ou usuários autorizados) consegue visualizar o ticket, então atenção a isso: se precisar trocar o solicitante para outro usuário do cliente ter acesso, pode ser necessário (mas isso não costuma ser comum; geralmente não se troca solicitante após abertura, exceto erro).

• Responsável: exibe “Responsável:” seguido do avatar e nome do agente responsável pelo ticket.

Similarmente, mostra a foto de perfil do usuário interno se houver, caso contrário um ícone padrão. Tooltip ao passar o cursor revela o nome (ou "Sem responsável" se não atribuído).

Se o ticket está Sem responsável, o avatar pode mostrar um ícone neutro e realmente indicar que ninguém pegou o chamado ainda.

Para atribuir ou mudar o responsável, você pode clicar diretamente sobre essa área (na maioria das vezes, clicando na foto ou nome abrirá a possibilidade de selecionar um usuário). Alternativamente, há um campo Responsável editável no painel de detalhes (Dados Básicos) à direita – as mudanças feitas lá refletem aqui.

Quando você, usuário logado, não é o responsável e decide assumir o ticket, muitas empresas configuram para que você simplesmente altere o responsável para si mesmo. Isso pode ser feito clicando no nome e escolhendo o seu usuário.

• Impacto: Internamente, mudar o responsável atualiza quem deve trabalhar no ticket e pode enviar notificação ao novo responsável. Não impacta outras partes do sistema fora do módulo de atendimento. Contudo, ter um responsável definido é importante para métricas de produtividade e para quem receberá eventuais alertas. Em geral, mantenha sempre um responsável ativo nos tickets em andamento. (Não há integração automática: ex. não gera tarefa no calendário do agente – a não ser que utilize ferramentas de agenda manualmente.)

• SLA: é indicado pela etiqueta “SLA:” seguida de uma data/hora ou um texto:

Se o ticket tem uma Data SLA (Data de vencimento do acordo de serviço) definida, ela aparece aqui em destaque. Por exemplo: “SLA: 12/10/2025 às 15:30”. Isso geralmente reflete a Data Prevista de conclusão calculada com base no SLA do contrato e prioridade.

Caso esse prazo já tenha expirado e o ticket ainda não esteja fechado, o sistema pode destacar em vermelho (e o tooltip ou texto pode indicar “SLA vencido”). O estilo muda (por ex., o campo fica com texto/vermelho e classe sla-vencido).

Se não houver SLA aplicável, aparece “SLA não aplicada”. Isso ocorre, por exemplo, se o cliente não tem contrato com SLA ou se é um chamado de cortesia sem prazo definido.

• Impacto: esse é um indicador importante para gestão do atendimento. Um SLA não cumprido pode gerar penalidades contratuais ou pelo menos requer escalonamento. Internamente, o BomControle não dispara nada quando o SLA estoura além de sinalizar em vermelho e possivelmente listar em relatórios de SLA. Caberá à equipe tomar ações (como informar o cliente, renegociar prazo ou priorizar urgentemente). Não há ligação direta com módulos externos – porém, se SLA não cumprido implicar desconto financeiro automático, isso seria tratado manualmente no Financeiro.

Observação: O SLA geralmente é calculado no momento da abertura (considerando horário comercial, feriados, etc., se configurado). Alterações de prioridade ou data prevista podem ajustar esse valor.

• Seguidores: é indicada pela palavra “Seguidores:” seguida pelos avatares de usuários que estão seguindo o ticket.

Seguidores são colaboradores (usuários internos) que optaram por acompanhar o andamento do ticket, embora não sejam o responsável principal. Eles recebem notificações de atualizações e podem visualizar o chamado facilmente.

Até 3 seguidores são mostrados diretamente como pequenos avatares. Se houver mais de 3, aparece uma reticência “...”. Passando o mouse nessa área possivelmente mostra todos os nomes ou pelo menos indica quantos são.

Para adicionar seguidores, há um ícone de “+” logo após os avatares. Clicando nele, abre-se uma pequena interface (um popover) permitindo selecionar usuários da lista para adicionar como seguidor. Pode também haver a opção de remover seguidores existentes nesse popover.

Exemplo de uso: Um gerente pode se colocar como seguidor de tickets críticos para receber cópias das notificações. Ou um membro de outra equipe pode seguir um ticket que depende de uma ação dele.

• Impacto: adicionar ou remover seguidores não influencia outros módulos; serve apenas para comunicação interna. Os seguidores receberão notificações por e-mail (se configurado) das movimentações do ticket, assim como o responsável recebe. Isso ajuda na colaboração multi-equipe. (Não confundir com “Participantes” ou “Contatos do cliente”; seguidores são sempre usuários internos do sistema.)

• Indicador de Fechamento: se o ticket estiver Fechado, no canto direito dessa linha aparece uma etiqueta destacada “Fechado”. Geralmente em cor azul ou verde, para sinalizar status finalizado, com um ícone de cadeado ou check.

Ao passar o mouse, pode exibir uma dica (tooltip) indicando quando e por quem foi fechado.

Se o ticket não está fechado (ou seja, está em algum status aberto como A Fazer/Em Andamento/Parado/Feito), esse indicador não aparece. Então a ausência dessa etiqueta significa ticket em andamento.

• Impacto: etiqueta meramente visual. O status real de fechado também aparece na Barra de etapas e no campo Status, mas essa tarja de Fechado aqui no topo facilita identificação imediata.

• Botão de Prioridade: ainda nessa área, à direita, você verá um badge de Prioridade (muito parecido com o que aparece na listagem em tabela). Ele mostra a palavra da prioridade atual do ticket (BAIXA, NORMAL, ALTA, CRÍTICA) e tem uma cor de fundo correspondente.

Esse badge é interativo: se você clicar nele, abre-se um menu suspenso com as quatro opções de prioridade. Você pode então selecionar uma nova prioridade para o ticket diretamente.

Isso é uma forma rápida de escalonar ou desescalonar a urgência do chamado. Por exemplo, se durante o atendimento percebe-se que o problema é mais sério, você pode clicar e mudar de Normal para Alta ou Crítica. Ou vice-versa.

Ao selecionar outra prioridade, o badge muda de cor e texto imediatamente, e o sistema salva a alteração. Uma entrada de Histórico será adicionada (ex.: “Prioridade alterada de Normal para Alta por [usuário] em [data]”).

• Impacto: trocar a prioridade aqui é equivalente a editá-la nos detalhes. Pode afetar o SLA (se houver lógica de SLA, possivelmente o Data Prevista é recalculado ao mudar prioridade, se a empresa configurou tempos diferentes). Não aciona ações externas. Contudo, como mencionado, a prioridade pode estar vinculada a contratos – se você aumentou para Crítica e o contrato do cliente prevê atendimento 24x7 para críticos, isso deve ser cumprido pela equipe (mas o sistema não “force” nada além de sinalizar). Fique atento, pois mudar para Crítica pode disparar alertas extras configurados (ex.: notificações para gestores).

• Dica: use esse recurso com critério; se tudo virar Crítico, perde-se o sentido da prioridade. Siga as definições de gravidade da empresa.

4.3 Barra de etapas (status do ticket)

Logo abaixo da linha de participantes, a tela exibe a Barra de etapas do fluxo de trabalho, representando os status pelos quais o ticket pode passar. Esta barra é composta por uma série de botões dispostos em sequência horizontal, geralmente com o nome de cada status/etapa. Ela funciona como um “trilho” do workflow:

Figura 13 — Barra de etapas do ticket, indicando as fases do fluxo

• Todos os status definidos para o fluxo de trabalho do ticket aparecem ali, na ordem do processo. Por exemplo, suponha um fluxo de ServiceDesk com as etapas: Aberto -> Em Atendimento -> Pendente -> Resolvido -> Fechado. Você verá um botão para cada um, possivelmente com pequenos ícones ou indicadores de etapa atual.

• A etapa atual do ticket é destacada visualmente (por exemplo, com cor diferente, ou um ícone apontando). Etapas já concluídas podem estar marcadas de outra forma (às vezes esmaecidas ou com um check).

• Você pode clicar nos botões de etapa para mudar o status do ticket manualmente.

• Por exemplo, quando começa a trabalhar no chamado, você clica em Em Atendimento para alterar o status de Aberto para Em Atendimento. O botão Em Atendimento então ficará ativo e as etapas anteriores/concluídas (Aberto) podem ficar marcadas como concluídas.

Ou, se por algum motivo precisa voltar o ticket para Aberto (reabertura antes de fechar), você poderia clicar em Aberto novamente (se permitido).

• Regras de transição: O sistema pode impor regras – alguns fluxos são lineares e você não pode pular etapas arbitrariamente. No entanto, nessa interface, se a permissão permitir, você consegue clicar em qualquer etapa seguinte ou anterior. Ao clicar, o BomControle executa a transição:

Se a transição violar alguma regra (ex.: pular para Fechado sem preencher campos obrigatórios de resolução), o sistema pode abrir um modal exigindo informações. Exemplo: ao clicar em Fechado, talvez abra o modal “Fechar Ticket” para você confirmar e inserir uma mensagem de resolução.

Se não houver impedimentos, ao clicar o status muda imediatamente. Uma entrada de Transição é registrada no histórico (por ex.: “Status alterado de Em Atendimento para Pendente por [usuário] em [data]”).

• Atenção: Para marcar como Fechado definitivamente, muitas implementações preferem usar o botão Fechar no rodapé (ver seção 4.7). Em alguns fluxos, clicar na última etapa Fechado faz o mesmo que o botão Fechar. De qualquer forma, o resultado é o status indo para fechado e o ticket sendo considerado concluído.

Os nomes dos status podem ter estilização, e possivelmente setas indicando progresso (por exemplo, um ícone “>” dentro do botão). Isso é apenas visual.

• Status fechados: Se um ticket já está fechado, a barra de etapas geralmente mostra todos os botões, com Fechado destacado. Poderá haver restrição de clique – isto é, não deixar você alterar etapas de um ticket fechado via barra. Nesse caso, para reabrir, existe o botão Reabrir (rodapé).

• Impacto das transições: Mudar a etapa é fundamental para o controle do atendimento, mas não gera impacto fora do módulo:

Por exemplo, mover para Resolvido não envia automaticamente nada ao cliente (exceto se configurado para notificar via e-mail, internamente). Nem gera fatura; é apenas mudança de fase.

O Histórico dessas transições fica no timeline para auditoria.

• Observação: Certas etapas podem ser configuradas para integração com CRM. Por exemplo, se houvesse uma etapa Aguardando Aprovação de Orçamento, talvez no CRM esse status sinalize algo – mas no contexto padrão, não há integração automática.

• Exemplo prático: Ticket inicia em Aberto. O atendente pega e clica em Em Atendimento. Depois descobre que precisa de informação do cliente, então clica em Pendente (indicando aguardando resposta). Quando cliente responde, volta a trabalhar e clica Em Atendimento de novo. Após resolver, clica Resolvido. Finalmente, confirma com o cliente e clica Fechado. Cada clique registrou transição e possivelmente notificou o cliente/agentes conforme regras definidas (e-mails configurados para certas transições, etc., não detalhado aqui pois depende da automação).

4.4 Timeline do histórico de atividades

A parte central da tela de detalhes é ocupada pela Timeline do ticket – um histórico completo de tudo o que aconteceu no chamado, em ordem cronológica inversa (eventos mais recentes no topo, típicamente). 

Figura 14 — Histórico (timeline) de atividades do Ticket

Cada interação (comentário, e-mail, alteração de status, anexos, etc.) é registrada aqui como um item da linha do tempo. Essa seção é crucial para a comunicação entre atendentes e cliente, e para manter registro das ações realizadas. Vamos detalhar seus elementos:

Filtros da Timeline: No topo da timeline, há um botão rotulado “FILTRO”. Ao clicar, expande um menu de filtragem dos tipos de eventos a visualizar. As opções comuns de filtro são: 

Figura 15 — Filtros do Histórico (timeline) de atividades do Ticket

- Todos: exibe todos os eventos em ordem cronológica. (Esta é a visualização padrão.)

- Comentários: mostra apenas os eventos de tipo Comentário (mensagens trocadas, seja do agente ou do cliente via portal). 

- Histórico: mostra apenas eventos de tipo Histórico (mudanças de campos do ticket, por exemplo alterações de título, responsável, prioridades, datas). 

- Anexos: mostra apenas eventos onde houve anexos adicionados/removidos. 

- Deletados: mostra eventos que foram marcados como deletados (itens excluídos da timeline). 

- Transições: mostra apenas eventos de Transição de Etapa (mudanças de status). - Tarefas (Agenda): mostra apenas eventos do tipo Agenda (tarefas ou compromissos agendados). 

- Emails: mostra somente os eventos de e-mail (enviados ou recebidos). (Algumas implementações podem separar Emails Enviados de Recebidos, mas no BomControle ServiceDesk é comum agrupar ambos em “Emails”). 

- Conversas: (se aplicável) em alguns contextos, se há integração com chat ou telefone e transcrição, poderia aparecer uma categoria Conversas, mas por padrão não há.

Você pode clicar em um desses filtros para ativá-lo. A timeline então se atualiza para mostrar apenas aquele tipo de registro. Isso é útil quando um ticket tem um histórico muito extenso e você quer isolar, por exemplo, só os comentários (excluindo logs técnicos e transições). Para voltar a ver tudo, selecione Todos.

Botões de ação de interação: Logo abaixo dos filtros (ou acima da lista de eventos) há uma série de botões para adicionar novas interações: 

- Comentário + : botão geralmente com ícone de balão de diálogo e um +, e texto “Comentário”. Ao clicar, abre-se o editor de comentário. 

- Email + : botão com ícone de envelope  e +, texto “Email”. Serve para enviar um email a partir do ticket. 

- Tarefa + : botão com ícone de calendário e +, texto “Tarefa” (ou “Evento”). Permite agendar um evento relacionado ao ticket. 

- Arquivo + : botão com ícone de clipe  e +, texto “Arquivo”. Permite anexar um novo arquivo diretamente.

Cada um desses ao ser clicado abre a interface correspondente: 

• Comentário: Abre uma janela/modal (ou expande um editor embutido) onde você pode digitar uma mensagem. Esse editor suporta formatação (negrito, listas, etc.) semelhante ao do campo Descrição. Você pode também anexar arquivos junto do comentário através dele. Uma vez submetido, o comentário aparece na timeline. 

Figura 16 — Inserindo Comentário no Ticket

- Você pode marcar um comentário como interno/privado ou público. No BomControle, por padrão, comentários adicionados pelo agente podem ser considerados internos (visíveis só internamente) até que você decida torná-los públicos. Há um botão de cadeado para alternar isso (veja abaixo em ações sobre os itens). 

- Se público, o cliente poderá ver esse comentário no portal e/ou receber por email notificação. 

- Impacto: comentários são comunicação – não mudam estados ou módulos, mas são registrados. Um comentário público é enviado por e-mail ao cliente (normalmente o sistema dispara notificação). Comentários internos não são enviados ao cliente.

• Email: Ao clicar em Email +, abre-se o modal de composição de e-mail. Os campos típicos: - Para: já preenchido com o e-mail do solicitante ou contato principal (aquele selecionado no cabeçalho como contato). Você pode editar ou adicionar CC se necessário (algumas implementações mostram CC/BCC). 

Figura 17 — Inserindo E-mail no Ticket

- Assunto: normalmente o sistema sugere um assunto padrão como “Re: [ID Ticket] [Título]”, mas você pode editar. 

- Corpo: um editor de texto para escrever o conteúdo do e-mail. Pode incluir formatação e imagens embedadas (inline). - Você pode anexar arquivos ao e-mail (há opção de inserir anexos no modal). 

- Ao enviar, uma cópia do e-mail Enviado será registrada na timeline como um evento de Email Enviado. 

- Impacto: o cliente receberá esse e-mail em sua caixa de entrada. Se o cliente responder ao e-mail (e se a caixa de e-mail do ServiceDesk estiver configurada para captura), a resposta dele entrará no sistema como um evento de Email Recebido na timeline, e aparecerá para o agente. Assim, a troca de e-mails fica documentada no ticket. Isso evita precisar usar caixas externas – toda conversa via e-mail fica vinculada ao chamado. 

- Nota: O envio de e-mail utiliza configurações de servidor de e-mail definidas no BomControle (por exemplo, pode usar um remetente padrão ou o e-mail do agente, conforme paramétrico). 

• Tarefa (Evento): Ao clicar em Tarefa +, surge o modal para agendar uma atividade: - Campos comuns: Título da Tarefa, Data e Hora, Duração ou Repetição (pode agendar recorrente), Responsável pela tarefa (pode ser você ou outro usuário), Participantes (outros envolvidos internos ou até externos, se integrarem com agendas, mas tipicamente internos). 

Figura 18 — Inserindo Tarefa no Ticket

- Descrição da Tarefa: campo para detalhar o que será feito. - Ao salvar, a tarefa é criada e aparece na timeline como um evento tipo Agenda. Ex: “Tarefa agendada: Reunião com cliente – 15/10/2025 10:00, Responsável: João”. 

- Além disso, essa tarefa entra na Agenda do BomControle (módulo de Agenda/Compromissos) do responsável e dos participantes. O responsável possivelmente recebe um convite/alerta. 

- Impacto: é uma forma de vincular compromissos ao ticket. Não interage com estoque/financeiro, mas garante que atividades offline (como uma visita técnica, um agendamento de call) fiquem registradas. Cumprir ou não essa tarefa é monitorado manualmente. Quando concluída, você pode editar o evento ou marcar no histórico (o sistema não marca automaticamente como concluída – você poderia inserir um comentário “Evento realizado conforme agendado” e talvez editar a tarefa para não ficar pendente). 

• Arquivo: Ao clicar em Arquivo +, abre-se um seletor de arquivo (similar ao do cadastro). Você escolhe um ou mais arquivos para anexar. Imediatamente eles são carregados e inseridos na timeline como eventos de Anexo. - Você verá então algo como “arquivo X.png anexado”. Esses arquivos ficam também listados na seção de Anexos do ticket. 

Figura 19 — Inserindo Arquivo no Ticket

- Impacto: anexos adicionados em qualquer momento podem ser baixados pelo cliente se forem públicos. Quando você anexa via Arquivo +, por padrão o anexo entra como interno ou público? Geralmente, anexos subidos ficam visíveis a todos (equivalem a se você tivesse enviado um arquivo num comentário público). Mas no BomControle, há a distinção: se você anexar um arquivo sem um comentário, ele entra como um evento “Anexo” – possivelmente visível para cliente no portal. Caso queira anexar algo apenas internamente, você poderia anexar dentro de um comentário marcado como interno. - Você pode controlar a visibilidade do anexo após adicioná-lo: há ações para torná-lo privado ou público (ver próximo item, ações em cada histórico). 

- Exemplo: Você recebe um log confidencial do servidor e quer guardar no ticket sem o cliente ver – após anexar, marca aquele evento como interno. - Nenhum efeito em outros módulos; é armazenamento de documentos relativo ao chamado.

Figura 20 - Ícones dos eventos inseridos no ticket

Eventos da Timeline (estrutura): Cada entrada na timeline aparece em um formato específico, com ícone, descrição, autor e data:

• Visualmente, é comum mostrar um ícone à esquerda indicando o tipo do evento:

• Comentário de agente: ícone de balão de fala com seta para a direita (indicando saída/do agente para o cliente).

• Comentário de cliente: ícone de balão com seta para a esquerda (entrada do cliente).

• Anexo: ícone de clipe.

• Histórico: ícone de relógio.

• Deletado: ícone de lixeira.

• Transição: ícone de duas setas trocando.

• Agenda: ícone de calendário.

• Email enviado: ícone de envelope com seta para a direita.

• Email recebido: envelope com seta para a esquerda.

• Ao lado do ícone, o conteúdo do evento é exibido dentro de um “cartão” ou painel:

• Título do evento: Em negrito costuma vir uma breve identificação:

• Para Comentários: “Comentário do Agente” ou “Comentário do Cliente”.

• Para Anexo: “Anexo”.

• Para Histórico: “Histórico”.

• Para Transição: “Transição de Etapa”.

• Para Tarefa: “Tarefa”.

• Para Email: “E-mail Pendente/Enviado/Recebido/Lido/Erro de Envio” dependendo do status do email.

• Ao lado desse título, às vezes vem um rótulo indicativo se o item foi excluído (um ícone de X vermelho e palavra “Excluído” se for o caso).

• Depois, é mostrado quem realizou e quando:

• Exemplo: | João Silva – 10/10/2025 15:30 (isso indica autor e data/hora do evento).

• Esse formato aparece geralmente em uma linha pequena logo abaixo do título do evento ou junto dele.

• Corpo do evento: Abaixo disso, o conteúdo do evento em si:

• Para Comentário: o texto do comentário, com formatações, imagens, etc. (Se for muito longo, pode ser truncado com um link “Ver mais”).

• Para Email Enviado: primeiro exibe o Assunto em negrito, seguido por De: [remetente] → Para: [destinatários] em itálico pequeno. Abaixo disso, o corpo do e-mail (pode ser parcialmente mostrado, com opção de “Ver mais” para expansão completa).

• Para Email Recebido: similar, mostra De: [cliente] → Para: [endereço do suporte] e o corpo do email recebido.

• Para Transição: geralmente algo como “Ticket alterado para Em Atendimento” ou “Responsável alterado de Maria para João” dependendo do tipo de transição. O BomControle registra ou a mudança de etapa ou outras mudanças relevantes sob histórico.

• Para Histórico: por exemplo “Prioridade alterada de Alta para Crítica”, “Data Prevista definida para 12/10/2025”, “Título alterado de ...” etc.

• Para Tarefa (Agenda): exibe os detalhes da tarefa criada. Geralmente uma listinha: Título, Repetição, Data, Responsável, Participantes, Descrição. Assim o agente pode ver o compromisso sem precisar abrir outra tela.

• Para Anexo: mostra o nome do arquivo anexado. O nome é um link – ao clicar, baixa ou abre o arquivo. Pode ter um botão/ver link “Ver anexo” que ao clicar exibe uma prévia se for imagem ou formato reconhecido.

• Se um anexo é imagem, muitas vezes a timeline incorpora uma thumbnail ou pré-visualização.

• Se o item foi excluído, o corpo pode ser escondido e substituído por “[conteúdo removido]” ou simplesmente ficar sem conteúdo, apenas marcando que foi deletado.

• Ações sobre cada evento: No canto superior direito de cada evento, ao passar o mouse, aparecem botões de ação (conforme permissões):

Figura 21 - Ações disponíveis nos eventos do ticket 

• Editar: Pode aparecer em comentários (permitindo editar o texto do comentário após postado). Somente agentes podem editar seus próprios comentários, e geralmente dentro de um intervalo de tempo ou se não enviado já ao cliente. Em BomControle, normalmente há opção de editar comentários do agente enquanto o ticket não está fechado.

• Excluir: Um ícone de lixeira para deletar o item. Agentes podem excluir comentários e anexos inseridos por engano, etc. Ao clicar, o sistema pede confirmação (por exemplo: “Tem certeza que deseja excluir este comentário/anexo?”). Se confirmar, o item é marcado como excluído: ele some da timeline normal, mas fica visível no filtro “Deletados” para auditoria. (Ou fica visível mas com indicação de deletado.)

• Obs: Excluir não apaga completamente do banco; mantém para histórico. Assim nenhum dado crítico se perde totalmente.

• Bloquear/Desbloquear: um botão de cadeado para marcar o item como interno (privado) ou público.

• Se o ícone é um cadeado fechado, indica que o item é interno (visível só para a equipe). Clicando muda para cadeado aberto (que representaria público). E vice-versa.

• Isso se aplica a comentários e anexos principalmente. Um comentário interno (cadeado fechado) não aparece para o cliente no portal e não foi enviado por e-mail. Torná-lo público (cadeado aberto) poderia, por exemplo, enviar então para o cliente ou passar a mostrar no portal, dependendo da configuração.

• Para anexos, similar: se marcado interno, o cliente não consegue baixar do portal; marcando público, passa a conseguir.

• Obs: Comentários do cliente obviamente são sempre públicos (eles escreveram via portal ou e-mail). Esses não terão opção de cadeado porque pertencem a cliente – todos os clientes envolvidos no ticket podem vê-los.

• O atendimento deve tomar cuidado: por padrão, o BomControle tende a postar agente->cliente comunicações via E-mail como já públicas (pois foram enviadas pro cliente), e possivelmente comentários diretos via portal como privados até se decidir tornar público (depende de como o agente usa a ferramenta – alguns sistemas permitem escolher antes de enviar o comentário se é interno ou público).

• Responder: Em eventos de Email recebido (mensagem vinda do cliente), costuma aparecer um botão “Responder” (ícone de setinha indicando resposta). Clicá-lo abre diretamente a janela de Enviar Email pré-endereçada ao remetente daquele e-mail, e possivelmente com a citação do e-mail original. Isso facilita dar sequência à conversa por e-mail dentro do ticket.

• Editar Evento: Para eventos do tipo Tarefa/Agenda, aparecem botões de editar e excluir também (um lápis e uma lixeira). Com eles, você pode reabrir o modal da tarefa para alterar detalhes (ex: reagendar data) ou remover a tarefa se não for mais necessária.

• Nem todos itens terão todas ações – por exemplo, Transição e Histórico dificilmente terão editar/excluir, pois são logs do sistema (talvez um admin poderia, mas interface não dá opção para agentes). Eles são permanentes para auditoria.

• Permissões: Tipicamente, agentes podem editar/excluir seus próprios comentários e anexos. Agentes com perfil de supervisor podem editar/excluir de outros agentes, talvez. Clientes não têm essas ações, obviamente, no portal eles só podem comentar e ver.

• Ordem e agrupamento: Os eventos são listados do mais recente ao mais antigo, cada um dentro de um “bloco” temporal. O BomControle às vezes agrupa eventos de mesmo timestamp – mas geralmente, cada ação é um item separado em ordem vertical.

• Linha do tempo invertida: Por padrão, timeline invertida (mais novo em cima). Você pode percorrer para baixo para ver os iniciais. Em alguns sistemas, rolar muito carrega mais antigo (lazy load); no BomControle possivelmente todos eventos já listados, ou um “Ver mais” se forem demais.

Exemplo de sequência de timeline visual:

[Ícone Comentário] Comentário do Agente
          (🔒 Interno) | Maria – Há 2 horas
          Cliente ainda não retornou.
          (Editar)(Excluir)(Tornar público)
--------------------------------------------------------------------------------
[Ícone Email] E-mail Enviado
          | De: suporte@empresa.com → Para: joao@cliente.com | 08/10/2025 16:00
          Assunto: Re: [1024] Computador não liga
          Olá João,
          Realizamos o procedimento X...
          (conteúdo do email)
          (Responder)
--------------------------------------------------------------------------------
[Ícone Email] E-mail Recebido
          | De: joao@cliente.com → Para: suporte@empresa.com | 08/10/2025 15:30
          Assunto: Re: [1024] Computador não liga
          Prezados, segue o log em anexo.
          (Arquivo "log.txt" mencionado)
          (Responder)
--------------------------------------------------------------------------------
[Ícone Anexo] Anexo
          | log.txt (32KB)
          (Baixar) (Excluir) (Tornar privado)
--------------------------------------------------------------------------------
[Ícone Comentário] Comentário do Cliente
          | João (Cliente) – 08/10/2025 14:00
          Estou enfrentando esse problema desde ontem...
--------------------------------------------------------------------------------
[Ícone Transição] Transição de Etapa
          Ticket passou para Em Atendimento
          | Sistema – 08/10/2025 13:50
--------------------------------------------------------------------------------
[Ícone Histórico] Histórico
          Responsável atribuído para Maria Souza
          | Sistema – 08/10/2025 13:45
--------------------------------------------------------------------------------
[Ícone Transição] Transição de Etapa
          Ticket criado na etapa Aberto
          | Sistema – 08/10/2025 13:40 

(Exemplo ilustrativo; no sistema real a formatação é similar a isso.)

Uso da timeline no dia a dia: - O agente deve registrar na timeline todas as ações tomadas: se fez uma ligação telefônica, ele pode adicionar um Comentário interno relatando "Liguei para o cliente às 10h, orientado a verificar cabos". Isso fica documentado. 

- O cliente por sua vez, se tiver acesso ao Portal do Cliente, consegue ver os comentários públicos, anexos públicos, e enviar comentários (que aparecerão marcados como do cliente). Assim, a timeline serve como canal de comunicação assíncrono similar a um chat/email integrado. 

- Cada atualização relevante também pode disparar notificação por e-mail: Ex: quando o agente posta um comentário público, o sistema manda um e-mail ao cliente com aquele comentário; quando o cliente posta via portal, o sistema notifica os agentes ou responsável. 

- Acompanhamento: Supervisores podem ver se os agentes estão atualizando adequadamente (ex.: se há longos períodos sem comentário do agente, pode indicar inatividade). 

- Auditoria: Em caso de questionamentos (“Por que meu chamado demorou?”), a timeline conta toda a história – ex.: “Cliente demorou 5 dias para responder em tal ponto”.

Impressão da timeline: O botão Imprimir (ver rodapé) gera um relatório que geralmente inclui toda a timeline e detalhes, para arquivar ou entregar ao cliente se necessário.

Exclusão e privacidade cautela: Uma vez enviado um comentário público, mesmo que você exclua depois, o cliente já recebeu por e-mail. Então apagar da timeline limpa registro interno, mas o cliente tem a mensagem. Use exclusão para correções no log interno, mas não se baseie nela para “apagar” informação já comunicada externamente.

4.5 Painel de detalhes do ticket (informações à direita)

Na visualização de detalhes, há um painel lateral direito que exibe informações adicionais do ticket e permite editar certos campos após a criação. Esse painel pode ser mostrado ou ocultado usando um botão com ícone de “seta” (» ou «). Ao ocultar, o conteúdo principal (timeline) se expande para toda a largura; ao exibir, você vê os campos do ticket.

Esse painel é dividido em abas ou seções, geralmente duas principais: - Dados Básicos - Últimos tickets desse cliente

No topo do painel, há botões de navegação (no nosso caso dois botões horizontais justificados: Dados Básicos e Últimos tickets). Você pode clicar entre eles para trocar a visão dentro do painel.

Dados Básicos (no detalhe)

A seção Dados Básicos no detalhe traz os campos principais do ticket para revisão e eventual edição. Ela reflete o que foi preenchido na abertura, mas aqui você pode atualizar alguns campos se necessário. Os campos apresentados incluem:

Figura 22 - Dados Básicos do Ticket

• Data de Abertura: mostrado novamente aqui. É apresentado em um campo de data (mas geralmente desabilitado para edição após o ticket criado). Você pode notar que está em formato de entrada mas não editável caso a política seja não permitir alteração. (No nosso exemplo de código, até permitiam editar com date picker e atualizarTicket, mas normalmente Data de Abertura não se muda após o fato, a menos que haja um engano). Portanto, considere-o somente leitura aqui.

• Impacto: serve só de referência interna. Como dito, alterar seria atípico.

• Empresa: mostrado e possivelmente editável se você realmente precisasse (mas atenção: no trecho de código do BomControle havia possibilidade de alterar empresa e reatribuir a outro?). Em geral, a empresa fica fixa depois que o ticket é criado – até porque mudar de empresa sem mudar de cliente não faz muito sentido (clientes pertencem a uma empresa no contexto multi-tenant). No interface, pode até aparecer habilitado, mas se tentar salvar talvez não deixe se já tinha cliente selecionado. A interface do detalhe do BomControle possuía esse campo habilitado mas convém não alterar a empresa de um ticket depois de criado.

Se por algum motivo foi no cliente errado, possivelmente o correto seria fechar/cancelar e abrir em outro cliente, não trocar empresa aqui.

Então encare a Empresa no detalhe como informativa.

• Impacto: caso fosse alterado (procedimento não recomendado), haveria confusão com o cliente vinculado. O sistema possivelmente não atualiza cliente sozinho, então não mude.

• Fluxo de Trabalho: exibido e editável. Ao clicar, você pode selecionar um novo fluxo para migrar o ticket.

Isso pode ser necessário se, por exemplo, o ticket foi classificado no fluxo errado. Ao mudar o fluxo, note que:

• O campo Etapa logo abaixo irá se atualizar para as etapas do novo fluxo.

• Provavelmente será exigido escolher a nova etapa também (o sistema pode já posicionar na primeira etapa do novo fluxo).

• Ao confirmar a mudança de fluxo (geralmente clicando fora ou salvando outro campo, já chama atualizarTicket), o ticket é agora movido para um processo diferente. Ele aparecerá na listagem do outro fluxo e sumirá do anterior.

• Histórico: uma entrada de histórico será adicionada (talvez como “Fluxo de trabalho alterado de X para Y”).

• Qualquer etapa/histórico antigo permanece registrado, mas note que as etapas antigas podem não ter mais significado no novo fluxo. Entretanto o ticket conserva ID, comentários, etc.

• Impacto: trocar o fluxo não afeta nada fora do ServiceDesk, mas internamente você está praticamente “transfigurando” o ticket em outro pipeline. Tome cuidado ao usar – idealmente fluxos são pensados para tickets distintos. Use se estritamente necessário.

• Observação: se o novo fluxo tem campos extras ou campos obrigatórios não presentes antes, ao tentar mudar o sistema pode pedir preenchimento desses campos (no BomControle, campos customizados do ticket, se existirem, aparecem possivelmente no painel ou em outra seção “Outras Informações” – aqui em nosso manual não há menção de campos customizados específicos do ServiceDesk, mas o sistema suporta).

• Etapa: exibido e editável. Este campo reflete a etapa atual do ticket no seu fluxo. Você pode usá-lo como alternativa à barra de etapas para mudar o status:

Selecionar uma etapa diferente aqui é equivalente a executar uma transição. Por exemplo, você pode escolher manualmente “Em Atendimento” ou “Feito”.

Na prática, muitos usuários preferirão clicar na barra Kanban de etapas. Mas a opção de alterá-la via dropdown existe e tem o mesmo efeito (chama a função alterarEtapaFluxo()).

Impacto: igual ao da barra de etapas (muda status, gera histórico transição).

Nota: o campo Etapa aqui é útil principalmente se você mudou o fluxo – porque aí precisará definir qual etapa no novo fluxo. Também pode ser útil se a barra de etapas estiver oculta (em casos de tela estreita ou mobile, talvez a barra seja substituída por este dropdown).

• Cliente: o cliente associado. Aqui ele é apresentado possivelmente como um campo de seleção desabilitado (no código, select-disabled="ticket.cliente || !ticket.empresa" – isso indica que se já há cliente ele mantém travado). Isso significa: após criado, não se pode trocar o cliente via interface. O cliente está travado no que foi escolhido no cadastro.

Isso é bom, pois mudar cliente de um chamado não faz muito sentido no atendimento (seria outro chamado então).

Portanto, o Cliente aqui é somente leitura (apesar de graficamente ser um dropdown).

Ele exibe também o indicador de inadimplente (o ícone de alerta caso haja pendência financeira, como no cadastro tinha).

Há um link “Ver Contratos” ao lado do rótulo Cliente se o sistema estiver integrado com contratos do módulo Financeiro:

• Clicando em “Ver Contratos”, possivelmente abre um resumo financeiro do cliente – faturas em aberto, contratos de suporte ativos, etc.

• Isso permite ao atendente consultar rapidamente se o cliente tem um contrato de suporte válido e qual o nível (por exemplo, horas disponíveis, se está dentro do SLA pago, etc.).

• Esse link não altera nada no ticket, só é uma referência. Útil se, por exemplo, o cliente exigir um atendimento mas está inadimplente ou sem contrato – o atendente tem embasamento para informar condições.

• Responsável: campo de seleção do agente responsável. Você pode alterar o responsável por aqui também (é outra forma de fazer o que você pode fazer clicando no avatar na linha de participantes).

Este dropdown lista usuários disponíveis (como no cadastro).

Ao mudar e salvar, o sistema atualiza e registra no histórico (“Responsável alterado de X para Y”).

Impacto: interna coordenação. Já discutido antes, designa quem deve tocar o chamado.

Está desabilitado se o ticket está fechado (veja select-disabled="statusTicket.fechado == ticket.status" no código – isso indica se status atual é Fechado, bloqueia mudança de responsável).

Ou se não há cliente? (tem também !ticket.cliente no disabled – mas sempre tem cliente).

Então se o ticket estiver ativo, você pode reatribuir a outro agente aqui.

• Solicitante: similar ao cadastro, permite alterar o solicitante (usuário do cliente).

Por exemplo, se você descobriu que quem deveria acompanhar pelo cliente é outra pessoa, ou o cliente pediu “coloque também o fulano como contato do chamado”.

Ao mudar aqui, o novo solicitante passa a ter acesso no portal e receberá emails.

Este campo provavelmente lista todos os usuários convidados associados ao cliente.

Você não consegue adicionar alguém que não esteja cadastrado – para adicionar um novo solicitante, precisaria cadastrar um novo usuário convidado via Clientes -> Contatos ou via botão rápido se existisse (no code do modalTicketController havia cadastroRapidoSolicitante, mas não vimos botão).

Impacto: melhora a comunicação – a partir de então, emails podem ir ao novo solicitante. Internamente, logs podem registrar se quem respondeu via portal foi a nova pessoa etc.

Também desabilitado se ticket fechado ou se cliente não existe (que não ocorre).

Figura 23 - Dados Básicos e últimos Tickets do cliente 

• Tipo de Ocorrência: mostra e permite alterar a categoria do ticket.

Se durante o atendimento verificar que a classificação estava errada (ex.: inicialmente marcaram como “Software > Bug” mas descobriram que era “Hardware > Defeito físico”), você pode mudar.

Ao clicar, abre a árvore de categorias e deixa selecionar outra. Ao escolher, salva automaticamente no histórico (“Tipo de Ocorrência alterado de X para Y”).

Impacto: apenas analítico – garante que relatórios por tipo fiquem corretos. Não muda nada processualmente, embora se sua empresa roteasse tickets pelo tipo, talvez tenha implicações de pessoas envolvidas. Mas não automático.

Como esse campo é interno, pode ser alterado a qualquer momento, inclusive após fechado (mas durante fechado talvez interface bloqueie edição? No code não havia disabled, então talvez permitam editar mesmo fechado – mas trocas depois do fechamento são raras).

Quem viu este ticket (visualizações): há uma seção que lista os usuários (internos) que visualizaram o ticket e quando.

Aparece como um label “Quem viu este ticket (N)” seguido por uma lista de entradas com nome do usuário e data/hora.

Exemplo:

• Maria Souza (10/10/2025 16:22)
  João Silva (08/10/2025 09:10)

Isso indica que Maria abriu a tela do ticket em 10/10 e João em 08/10. O número (N) indica quantos usuários viram.

Essa funcionalidade é útil para monitorar se tickets estão sendo de fato lidos/pesquisados. Um supervisor pode ver que um ticket foi aberto mas nenhum técnico sequer visualizou – sinal de problema.

Impacto: nenhuma automática, só auditoria. Não editável; é gerado pelo sistema a cada abertura da tela de detalhe do ticket (ou possivelmente se visualizou via lista de tickets? Mas geralmente no detalhe).

(Campos adicionais possivelmente presentes: se a sua empresa configurou Campos Customizados para o ServiceDesk, eles aparecerão ou aqui em Dados Básicos ou em uma seção separada “Outras Informações”. Por exemplo, um campo “Número do Patrimônio” do equipamento, etc. Esses campos seriam editáveis também. Como são específicos por cliente, não detalharemos além de dizer que aparecem e podem ser preenchidos/editados conforme necessário, influindo possivelmente em integração com Inventário ou outros sistemas se houver, mas não por padrão.)

Essa seção Dados Básicos permite assim corrigir ou atualizar informações cadastrais do ticket ao longo do ciclo. Lembre-se de que algumas alterações (fluxo, etapa, responsável) também são possíveis via outras partes da interface, mas estão centralizadas aqui para conveniência.

Últimos tickets desse cliente (no detalhe)

A segunda aba do painel lateral reproduz a lista de histórico de chamados do cliente, igual à exibida no momento do cadastro (seção 3.2). Mostra os últimos tickets daquele cliente (por exemplo, os 5 mais recentes fechados ou em andamento, excluindo possivelmente o atual):

• Cada item mostra:

• Um badge colorido de prioridade do ticket histórico (dando ideia se eram chamados críticos ou não).

• O ID do ticket antigo e o título resumido (cortado se longo).

• Você pode clicar em um desses itens para abrir aquele ticket antigo em uma nova janela/aba do navegador (o link geralmente tem target _blank).

• Essa seção é útil no detalhe caso você queira consultar, durante o atendimento, algum detalhe de ticket passado sem precisar sair do atual. Por exemplo: "Esse problema já ocorreu antes, vi que tem um chamado #980 similar no mês passado" – você clica ali e revisa o que foi feito.

• Impacto: nenhum direto, apenas referência.

• Se não houver tickets anteriores, será indicado (“Cliente sem histórico de tickets”).

• Esta seção se atualiza automaticamente se, por exemplo, você fechou um ticket e abriu outro para mesmo cliente – ela vai refletir agora incluindo o que acabou de fechar (porque se tornou um dos últimos).

• Navegação: no topo do painel, você pode alternar de volta para Dados Básicos quando terminar de olhar históricos.

4.6 Botões de ação no rodapé do ticket

No rodapé da tela de detalhes do ticket (fixo no canto inferior) há uma barra com botões de ações gerais para o ticket:

Figura 24 - Botões de ação no rodapé do ticket

• Voltar: um botão Voltar (geralmente cinza, à esquerda) – retorna à tela anterior ou lista de tickets.

• Se você entrou no ticket a partir da listagem, clicar Voltar leva de volta para a listagem exatamente com os filtros que estavam aplicados.

• É útil para navegar sem perder contexto de busca.

• Se você veio de um link externo, Voltar pode simplesmente levar para a listagem padrão de tickets.

• Atalho: também pode ser acionado via tecla de atalho se disponível (depende do sistema).

• Impacto: nenhum além de navegação. Se houver edições não salvas (por ex., se estivesse no meio de edição inline e não confirmou), o sistema pode alertar ou simplesmente descartar as alterações. No BomControle, campos como título ou datas salvam imediatamente ao confirmar, então não costuma ter “modo edição” pendente; portanto Voltar é seguro de usar a qualquer momento.

• Imprimir: botão Imprimir (ícone de impressora). Ao clicar:

• O sistema gera uma versão imprimível do ticket – normalmente um relatório contendo:

• Cabeçalho com ID, título, cliente, etc.

• Todos os detalhes (campos básicos e valores).

• E a timeline completa (comentários, emails, etc.), geralmente marcando internos vs públicos.

• Abre a caixa de diálogo de impressão do navegador para você escolher imprimir fisicamente ou salvar em PDF.

• Uso típico: gerar um PDF do chamado para anexar em um relatório, ou para guardar evidências, ou até para entregar ao cliente como resumo formal.

• Impacto: nenhuma mudança no ticket; apenas extrai as informações em outro formato.

• Observação: Itens internos talvez sejam marcados ou omitidos conforme configurações de impressão (em alguns sistemas, a impressão exibe tudo para fins internos; se for para entregar a cliente, convém antes marcar internos como públicos ou retirá-los).

• Excluir (Ticket): botão Excluir (vermelho). Essa opção permite excluir o ticket inteiro.

• É restrita a usuários com permissão (geralmente administradores ou técnicos seniores).

• Ao clicar, o sistema pedirá confirmação (ex: “Tem certeza que deseja excluir este ticket? Esta ação é irreversível.”).

• Se confirmado, o ticket é marcado como excluído. Isso geralmente retira o ticket da listagem normal:

• Ele talvez fique acessível apenas filtrando por “Mostrar excluídos” se houver tal opção para admins.

• Todos os dados permanecem no banco (para compliance), mas invisíveis para usuários comuns.

• Impacto: nenhum módulo externo é afetado automaticamente (excluir um ticket não reverte nada fora, pois ticket não lançava nada fora).

• Quando usar: apenas para remoção de registros lançados por engano ou duplicados. Não é comum excluir tickets reais, preferindo-se eventualmente marcar como cancelado (o que poderia ser uma etapa ou status).

• Atenção: Uma vez excluído, o cliente não vê mais no portal, e não deve mais responder a emails (respostas via email talvez não entrem mais, ou se entrarem o sistema não associará a um ticket ativo).

• Alternativa: O BomControle não tem um status "Cancelado" padrão, então exclusão acaba sendo a forma de remover. Use com parcimônia.

• Reabrir: botão Reabrir (amarelo ou laranja). Aparece somente se o ticket está Fechado (caso contrário fica oculto).

• Serve para reabrir um ticket que foi fechado, caso o problema não tenha sido realmente resolvido ou voltou a ocorrer.

• Ao clicar, o sistema muda o status do ticket de Fechado para um status ativo. Provavelmente volta para a etapa imediatamente anterior ao Fechado (por exemplo, se tinha Resolvido antes de fechar, ou Feito).

• Se não souber qual etapa por padrão voltar, o sistema pode usar um status específico “Reaberto” ou simplesmente marcá-lo novamente como “Em Atendimento”. No código, não vimos detalhe, mas possivelmente:

• ng-if="statusTicket.fechado != ticket.status && statusTicket.feito == ticket.status" fazia Reabrir visível erroneamente. Vamos supor que a intensão era mostrar Reabrir quando status = Fechado.

• Ao reabrir, insere histórico “Ticket Reaberto por X em data”.

• O ticket volta a aparecer nas filas de abertos.

• Impacto: retoma o ciclo de atendimento. Reabrir não notifica diretamente ninguém externo, a menos que se configure (geralmente se reabrir, pode notificar o responsável).

• O cliente no portal voltará a ver como aberto (ou resolvido pendente).

• Nota: Ao reabrir, pode ser interessante também adicionar um comentário explicando por que reabriu (ex.: cliente ligou dizendo problema voltou).

• Permissão: normalmente qualquer agente pode reabrir um ticket fechado. Em algumas empresas, só supervisão reabre; outras permitem cliente reabrir via portal (por exemplo, se ele responde um ticket fechado, o sistema reabre automaticamente ou cria outro – varia).

• Fechar: botão Fechar (azul). Visível enquanto o ticket não está fechado.

• Esse é o meio principal de finalizar um ticket. Ao clicar em Fechar:

• Se houver alguma condição pendente (por ex., alguns fluxos pedem selecionar um “Motivo de Fechamento”, ou confirmar se houve solução), o sistema apresentará o modal de confirmação de fechamento.

• Um típico modal “Fechar Ticket” poderia ter: campo Solução aplicada para você descrever brevemente a solução final e talvez um dropdown Motivo de fechamento (p. ex.: Resolvido com solução, Resolvido sem solução, Duplicado, etc., configuráveis).

• Em BomControle CRM, por exemplo, fechar oportunidade requer motivo de perda ou ganho; no ServiceDesk pode haver motivo de cancelamento ou afins se previsto.

• Se houver campo requerido, o sistema não fechará até preencher.

• Confirmando fechar, o ticket:

• Tem seu status alterado para Fechado.

• Data de fechamento registrada (pode não ser exibida na interface normal, mas fica em banco e possivelmente nos relatórios).

• Histórico: registra “Ticket Fechado por X em data, Motivo: Y (se houver)”.

• Notificação: Geralmente, fecha chamado dispara e-mail ao cliente dizendo “Ticket #X foi finalizado/fechado. Estamos à disposição...” etc., e possivelmente solicitação de avaliação de satisfação (se o sistema tiver essa funcionalidade).

• O ticket sai das filas ativas e aparece apenas se filtrar status Fechado ou nos relatórios.

• Após fechar, os campos se tornam não editáveis (como vimos a interface bloqueia vários).

• O cliente pode ver no portal o ticket marcado como Fechado. Muitas vezes, portais permitem ainda que o cliente reabra respondendo ou criando um follow-up, mas isso volta ao caso de reabrir.

• Impacto fora: ao fechar, se sua empresa tem métricas de SLA, esse é o momento de calcular se foi dentro do prazo. O sistema já calculou internamente se SLA foi atendido ou não e pode marcar o ticket com essa info (ex.: “Fechado em 5h, SLA 8h – OK” ou “Fechado atrasado 2h” nos relatórios).

• Se a política da empresa prever faturamento de horas de suporte, agora que o ticket fechou, possivelmente um responsável vai lançar no Financeiro as horas gastas, mas isso é um processo manual. O BomControle possivelmente tem Integração de tempo e faturamento via contrato, mas não detalhamos aqui. Em geral, fechar o ticket não gera cobrança automaticamente – a não ser que a empresa contrate esse customization. O agente deveria descontar as horas do contrato do cliente manualmente ou via apontamento no contrato (existe no Financeiro do BomControle o conceito de “consumo de contrato de suporte”, mas não entraremos nisso).

• Em suma, Fechar é fim do ciclo do chamado neste módulo.

• Concluir: botão Concluir (verde, possivelmente com ícone de check ou só texto).

• No BomControle CRM, “Concluir” servia para terminar a edição e salvar. Aqui, contudo, percebemos que Concluir faz a mesma função de Voltar – sai da tela.

• Pelo código dado, Concluir chama voltar():

• Isso sugere que o termo “Concluir” neste contexto significa “feche a tela de detalhe e volte”, não que finalize o ticket (pois fechar ticket é outro botão).

• Provavelmente, Concluir está aí para o fluxo de trabalho do atendente: após finalizar seu trabalho (comentários, fechamento, etc.), ele clica Concluir para sair do ticket.

• Também possivelmente serve para quem entrou em modo edição inline de vários campos (por ex., CRM usa Concluir para sair do modo edição, mas aqui cada campo salva de imediato).

• Então, Concluir aqui é redundante com Voltar, mas a interface do BomControle opta por manter ambos: Voltar (à esquerda) e Concluir (à direita, verde) – talvez para enfatizar ação final.

• Use Concluir como um “Voltar com intuito de tudo pronto”.

• Impacto: nenhum, navegação somente.

(Observação: a dualidade Voltar/Concluir pode confundir. Pensa-se assim: Voltar é cancelar se estivesse em edição, e Concluir é salvar e sair. Mas como as edições são instantâneas, ambos fazem parecido. De qualquer forma, no uso, o atendente ao acabar clica Concluir por hábito, ou Voltar, ambos o levarão de volta à lista.)

Resumo do fluxo de trabalho de um ticket ServiceDesk (do ponto de vista do usuário final):

1. Usuário (cliente) solicita suporte – o agente cria um Ticket registrando título, descrição e informações pertinentes.

2. O ticket aparece na lista, possivelmente o agente ou outro é atribuído como Responsável.

3. O agente trabalha no chamado, comunicando-se via Timeline:

4. Envia Emails ou posta Comentários públicos para manter o cliente informado ou pedir informações.

5. Registra Comentários internos para log técnico ou lembretes, que o cliente não vê.

6. Anexa Arquivos (log, screenshots) e agenda Tarefas (visita técnica, etc.) conforme necessário.

7. Atualiza o status (etapa) conforme o andamento: por ex., Em Atendimento, Pendente cliente, etc., usando a Barra de etapas.

8. O cliente pode interagir respondendo aos e-mails (que entram como Emails recebidos na timeline) ou pelo portal do cliente adicionando Comentários.

9. O sistema notifica as partes a cada interação (reduz necessidade de ligações).

10. Se necessário, o agente pode Reatribuir a outro responsável (ex.: escalonar para nível 2).

11. Durante o processo, campos podem ser ajustados: prioridade aumentada se virou urgente, tipo de ocorrência refinado se diagnosticado diferente, etc. Tudo fica no Histórico.

12. Ao resolver, o agente marca como Resolvido (uma etapa, ou indica de alguma forma). Muitas equipes preferem não fechar imediatamente, mas aguardar confirmação do cliente:

13. O agente informa o cliente da solução e coloca o ticket em status Resolvido/Pendente confirmação.

14. Se o cliente concorda que está ok, então o agente clica Fechar para encerrar.

15. Se o cliente retorna dizendo "Ainda não funciona", o agente Reabre (ou continua aberto se não tinha fechado).

16. Quando fechado, o ticket é dado por concluído. O cliente recebe comunicado de encerramento (e possivelmente uma pesquisa de satisfação).

17. O ticket fechado é arquivado, podendo ser consultado no futuro (pela aba de Últimos tickets, ou busca de históricos).

18. Estatísticas: esse fluxo alimenta relatórios de tempo de atendimento, cumprimento de SLA, volume de tickets por cliente/tipo, etc., que a equipe do ServiceDesk usa para melhoria contínua e o gerente para demostrar valor do suporte.

Em todos esses passos, o usuário final deve saber: - Como verificar o status e interações via portal (se aplicável), - Que ele pode receber e enviar e-mails e que isso fica registrado, - E principalmente como fornecer informações e acompanhar a resolução.

Concluindo, o módulo de Ticket ServiceDesk do BomControle integra-se aos demais módulos apenas conceitualmente: - Quando um ticket requer movimentações de Estoque (peças, substituições), o agente deverá registrá-las no módulo de Estoque (por exemplo, baixando peça do estoque para envio) – o ticket pode mencionar isso, mas não faz sozinho. - Se a solução envolveu uma venda adicional (um upgrade de produto), o agente possivelmente abrirá uma Oportunidade CRM ou um Pedido de Venda no módulo Vendas – mas manualmente. O ticket pode ser referenciado nesses registros, mas não há vínculo automático. - Se o atendimento for faturável (cobrança de horas ou visita), ao fechar o ticket o financeiro deverá gerar uma fatura ou descontar de um contrato – isso também é externo ao ticket, porém o ticket fornece evidência do atendimento prestado. O botão "Ver Contratos" auxilia a ver se deve-se cobrar extra ou está coberto.

Assim, o impacto em Estoque, Financeiro, Vendas e NF-e depende da ação do usuário: 

- Exemplo: Ticket de instalação de equipamento – após resolver, o atendente pode emitir uma Nota Fiscal de serviço ou de remessa pelo módulo Financeiro/Nota Fiscal, se contratualmente previsto. O ticket em si não emite NF-e. 

- Outro exemplo: Ticket de garantia – pode implicar movimentar estoque (receber peça defeituosa, enviar peça nova). O atendente terá que lançar uma movimentação de entrada/saída no Estoque. Ele pode registrar no ticket "Peça X substituída, série Y, NF 123 emitida", mas a NF é feita no módulo de NF-e do BomControle. - Em suma, o ticket serve como controle e comunicação, enquanto as ações operacionais nos outros módulos são executadas separadamente, ainda que baseadas nas informações coletadas no ticket.

Este manual apresentou todas as telas e funcionalidades do cadastro de Ticket ServiceDesk no BomControle. Com ele, o usuário (atendente) deverá ser capaz de: 

- Navegar pela lista de tickets, aplicando filtros e encontrando os chamados relevantes. 

- Criar novos tickets de forma completa e correta, preenchendo campos conforme as regras. - Entender e usar a tela de detalhes para conduzir o atendimento, adicionando comentários, enviando e-mails, anexando arquivos, agendando tarefas e atualizando status. 

- Finalizar o ticket apropriadamente, fechando-o somente quando resolvido e sabendo reabrir se necessário. - Perceber onde certas informações interagem com outros módulos (como contrato do cliente e inadimplência) para tomar ações fora do ServiceDesk quando preciso. - Manter um registro claro no sistema de tudo que foi feito para resolver o chamado, garantindo transparência e histórico para consultas futuras.

Dica final: use sempre o bom senso ao lidar com tickets. Mantenha os clientes informados, documente bem as soluções na timeline e fique atento aos prazos (SLA). O BomControle ServiceDesk é uma ferramenta para facilitar esse processo – quando usada plenamente, melhora a organização do suporte e a satisfação dos clientes. Conclua cada atendimento apenas quando tiver certeza de que o cliente concordou com a solução, e então feche o ticket e registre a conclusão adequadamente.