Catálogo de serviçosNOVO
Quem precisa de algo interno hoje abre um chamado em branco e escreve o que lembra. Ninguém sabe o que dá para pedir, o chamado chega faltando a informação óbvia, o atendente pergunta, a pessoa responde no dia seguinte, e o prazo do SLA foi embora nessa ida e volta. O catálogo troca o chamado em branco por uma vitrine: cada serviço, do notebook novo ao acesso de sistema, é um item com o seu formulário, a sua fila e a sua prioridade. A pessoa escolhe o serviço, responde as perguntas daquele serviço, e o sistema abre um chamado de verdade, já preenchido e no lugar certo. Não existe um pedido paralelo: é o mesmo chamado que o console abre, o SLA cronometra, a automação move e a API enxerga. E, pela primeira vez, dá para responder quantas vezes cada serviço foi pedido no mês.
- Vitrine com busca por nome, descrição ou código, e categorias em árvore, para o item morar em TI e, dentro dela, em Acessos.
- Formulário por serviço: até 40 perguntas em nove tipos (texto, texto longo, seleção, e-mail, telefone, número, data, data e hora, sim ou não), cada uma obrigatória ou não, com texto de ajuda.
- Pergunta condicional: o campo só aparece quando outro campo tem determinado valor, e o que ficou escondido não é exigido nem gravado.
- Fila, prioridade e categoria padrão por item: o chamado nasce onde tem de nascer, sem triagem manual.
- Assunto composto: você marca quais respostas entram no assunto, então cem pedidos do mesmo serviço não chegam com cem assuntos idênticos.
- Aprovação por item, no mesmo motor de aprovação que a empresa já usa, sem um segundo motor.
- O pedido congela um retrato do formulário: mudar as perguntas hoje não faz o pedido de ontem mentir.
- Reenviar o mesmo formulário devolve o pedido que já existe, em vez de abrir um segundo chamado e comprar dois notebooks.
- Relatório de quantas vezes cada serviço foi pedido, contado pelo vínculo com o item, nunca por um contador mantido à mão.
- Cumprimento por plano: cada passo do serviço vira uma tarefa de verdade, com responsável, prazo, lembrete e lugar na lista do dia de quem faz, e "entregue" é marcado por gente, nunca deduzido.
De graça no Sellio, você só paga a máquina
Um catálogo de serviços com formulário próprio, fila e aprovação costuma ser um módulo de ITSM à parte. No Sellio ele vem junto do atendimento: você só paga a máquina.
O pedido chega completo
As perguntas do serviço são feitas na hora de pedir, então o atendente não perde um dia perguntando o óbvio e o prazo não vai embora na ida e volta.
Ninguém precisa adivinhar o que dá para pedir
A vitrine mostra os serviços por categoria, com busca por nome, descrição ou código, e cada um explica o que é antes de a pessoa preencher.
A fila recebe trabalho já triado
Fila, prioridade e categoria vêm do item, e o assunto já diz do que se trata, então ninguém precisa reclassificar o que acabou de chegar.
Dá para medir o que se pede
O relatório mostra quantas vezes cada serviço foi pedido, que é a pergunta que hoje simplesmente não tem resposta possível.
O pedido vira um chamado de verdade, com protocolo, fila, SLA, console, automação, API e histórico: tudo o que o produto já dá a qualquer chamado.
As respostas vão para dois lugares com propósitos diferentes: em texto legível dentro do chamado, para o atendente ler, e estruturadas no pedido, para o relatório contar.
A aprovação reusa o motor da casa, o mesmo das outras aprovações, então política, delegação e trilha valem aqui sem regra nova.
O catálogo nasce vazio: enquanto ninguém cadastrar um item, abrir chamado continua exatamente como era ontem.
Do chamado em branco para a vitrine
A pergunta que o catálogo responde é simples e hoje não tem resposta: o que dá para pedir? Sem vitrine, cada pessoa inventa o próprio jeito de pedir a mesma coisa. Sem formulário por serviço, o pedido chega sem a informação que o atendente vai ter de perguntar de volta, e é essa ida e volta que come o prazo. Com o catálogo, quem administra monta a lista uma vez, em Configurações: categorias, itens e as perguntas de cada item. Qualquer pessoa da empresa abre a mesma tela, escolhe e pede. Um catálogo que só o administrador enxerga não teria a quem servir.
O formulário é do serviço, não do chamado
Cada item carrega as perguntas que aquele serviço precisa: são até 40, em nove tipos, cada uma obrigatória ou não e com um texto de ajuda embaixo. A pergunta pode ser condicional, aparecendo só quando outra resposta tem determinado valor, e o campo que ficou escondido não é exigido nem gravado, porque cobrar resposta de pergunta que a pessoa nunca viu é o jeito mais rápido de tornar um formulário impossível de enviar. A leitura é tolerante no formato e estrita no significado: "3.300,00" e "35%" entram como número, a data aceita os formatos que gente escreve, mas 30 de fevereiro é recusado em vez de virar 2 de março sozinho. Duas perguntas com a mesma chave são recusadas na hora de salvar, senão a segunda sobrescreveria a resposta da primeira sem erro nenhum.
Onde o chamado nasce, e com que cara
O item define a fila de destino, a prioridade e a categoria do chamado, então o pedido já cai no time certo com o peso certo, sem triagem manual. O assunto é montado com o nome do serviço mais as respostas que você marcou como parte do assunto: sem isso, cem pedidos de "Acesso a sistema" chegam com cem assuntos idênticos e a fila fica ilegível. A descrição do chamado leva as respostas em pares de pergunta e valor, no mesmo formato que o portal já usa, para o atendente ler tudo sem abrir outra tela. E o canal do chamado sai do mapa de canais da sua empresa, não de um literal escrito no código.
Aprovação por item, sem um segundo motor
Um item pode exigir aprovação, e essa exigência é dado do item, não um motor novo: quem decide é o mesmo motor de aprovação que a empresa já usa em outras coisas, com as mesmas políticas, a mesma delegação e a mesma trilha. O chamado é aberto na hora, e a aprovação pendente bloqueia a resolução pelo caminho que o console já tem. Segurar o chamado até alguém aprovar deixaria o solicitante vendo o nada, sem protocolo, sem fila e sem SLA. O estado do pedido tem três valores, aguardando aprovação, aberto e rejeitado, e é lido da aprovação a cada consulta, nunca copiado para uma coluna: uma cópia divergiria em silêncio no primeiro caminho que decidisse a aprovação em outro lugar. Uma honestidade que a própria tela diz em voz alta: o motor responde "aprovado" quando nenhuma política casa, então marcar "exige aprovação" numa empresa sem política cadastrada não trava nada. Cadastre a política primeiro, a exigência depois.
Desativar não é cancelar, e excluir nem sempre é possível
Desativar um item quer dizer "não peça mais isto", nunca "cancele o que está em andamento". Os chamados já abertos por aquele serviço continuam abertos, com a mesma fila e o mesmo prazo, e os pedidos históricos continuam contando no relatório. Cancelar o trabalho de outra pessoa por um clique de configuração seria uma consequência que ninguém pediu e que a tela não avisa. Pela mesma razão, um item que já foi pedido não pode ser excluído, só desativado: excluir levaria junto o significado de todo pedido histórico e o relatório passaria a mentir em silêncio. E uma categoria com itens dentro também não é excluída, porque os itens ficariam sem taxonomia e a vitrine com uma seção fantasma. Mover os itens, ou desativar a categoria, é o caminho.
O retrato que impede o histórico de mentir
O item é editável para sempre, e é isso que torna o congelamento necessário. Cada pedido guarda um retrato das perguntas como estavam no momento em que a pessoa respondeu, com o número da versão do formulário, mais o código e o nome do serviço naquele dia. Renomear uma pergunta hoje, ou trocar o nome do serviço, não reescreve o que foi pedido em março. A versão do formulário sobe quando o formulário muda, e só quando ele muda: renomear o item ou trocar a fila não é mudança de formulário, e inflar o número a cada salvamento tiraria o sentido do número que o pedido congela. Do outro lado do vínculo sai a métrica que justifica o catálogo existir, quantas vezes cada serviço foi pedido, contada a partir dos próprios pedidos e não de um contador incrementado à mão.
Do pedido à entrega · o cumprimento
Pedir "notebook novo" abre o chamado, mas as cinco coisas que precisam acontecer depois (aprovar a compra, emitir a ordem, preparar a máquina, instalar os programas, entregar) não moravam em lugar nenhum. Agora o item carrega um plano: cada passo tem assunto, tipo de tarefa, prazo em dias contados do início, quem fica com ele e, quando importa, o passo anterior do qual depende. Não é uma segunda lista de tarefas: cada passo vira uma tarefa comum do CRM, com responsável, prazo, lembrete, notificação e lugar na lista do dia da pessoa, presa ao chamado, então aparece na linha do tempo do caso sem tela nova. Sem responsável escolhido, o roteamento de atribuição decide, com as regras que você já tem. O plano congela no pedido quando o cumprimento começa, não quando o serviço é pedido: corrigir o item hoje não reescreve a lista de trabalho de ninguém. Se o item exige aprovação, o cumprimento espera a decisão; sem aprovação a esperar, começa na hora. Quem coordena tem a fila de cumprimento: o que está pendente, com quem e há quanto tempo, com passo vencido primeiro e, logo depois, o pedido aprovado que ninguém iniciou, porque aprovar não inicia nada e esse é o pedido que dorme em silêncio. "Entregue" é um clique de gente quando o serviço chegou de fato, e o estado do pedido (aguardando aprovação, aberto, em cumprimento, entregue, rejeitado) é derivado a cada leitura, nunca copiado para uma coluna. Passo obrigatório aberto bloqueia a entrega, com o motivo à vista; passo marcado como não obrigatório nunca bloqueia. Marcou por engano? Estorne com uma nota: é um lançamento novo, a entrega anterior fica no histórico. E o passo cuja tarefa foi apagada aparece como abandonado: não trava a entrega, porque exigir que alguém recrie a tarefa que acabou de apagar é regra sem como cumprir, e nunca conta como concluído, porque dizer que um trabalho foi feito quando ninguém o fez é pior do que admitir que sumiu.
- 1
Em Configurações, catálogo de serviços, quem administra cria as categorias e os itens.
- 2
Cada item ganha as suas perguntas, a fila de destino, a prioridade e, se for o caso, a exigência de aprovação.
- 3
Qualquer pessoa da empresa abre a mesma tela, escolhe o serviço e responde o formulário.
- 4
O chamado é aberto na fila certa, com as respostas dentro, e o pedido fica registrado para o relatório.
- 5
Quem opera o caso inicia o cumprimento: as tarefas do plano nascem na ordem das dependências, cada uma com dono e prazo, e a entrega é marcada quando o serviço chega à pessoa.
Notebook novo para quem entrou
O item pergunta o modelo, o centro de custo e a data de início, exige aprovação da liderança e cai na fila de TI com prioridade alta.
Acesso a um sistema
A pergunta "qual sistema" é uma seleção, e o campo "qual perfil" só aparece depois que o sistema foi escolhido, então ninguém responde o que não interessa.
Segunda via de um documento
A mesma pessoa pode pedir duas vezes no mesmo dia, de propósito; o que não acontece é o duplo clique abrir dois chamados do mesmo pedido.
O serviço saiu do ar
Você desativa o item e ele some da vitrine na hora, sem tocar nos chamados que já estavam andando nem apagar o histórico de quem pediu.
O pedido é um chamado ou uma coisa à parte?
É um chamado de verdade, com protocolo, fila, SLA, console, automação, API e histórico. Não existe um pedido paralelo com ciclo próprio.
Quem pode montar o catálogo e quem pode pedir?
Montar é de quem administra, porque um item define fila, prioridade e aprovação, ou seja, define trabalho para os outros. Pedir é de qualquer pessoa da empresa.
Desativar um item cancela os pedidos em andamento?
Não. Desativar quer dizer "não peça mais isto": os chamados já abertos continuam abertos, com a mesma fila e o mesmo prazo.
Posso excluir um item que já foi pedido?
Não, só desativar. Excluir levaria junto o significado de todo pedido histórico e o relatório passaria a mentir. Vale o mesmo para categoria com itens dentro.
Se eu mudar as perguntas, os pedidos antigos mudam também?
Não. Cada pedido guarda um retrato das perguntas como estavam quando a pessoa respondeu, com a versão do formulário e o nome do serviço daquele dia.
Marcar "exige aprovação" já garante que alguém vai aprovar?
Só se existir uma política de aprovação que case com o caso. O motor responde "aprovado" quando nenhuma política casa, e a tela avisa isso onde você liga a exigência.
Um duplo clique abre dois chamados?
Não. Reenviar o mesmo formulário devolve o pedido que já existe. Pedir o mesmo serviço de novo, de propósito, continua valendo: duas segundas vias são dois pedidos.
Preciso configurar o catálogo para o atendimento continuar funcionando?
Não. Enquanto ninguém cadastrar um item, abrir chamado continua exatamente como era, o que deixa adotar isso um serviço de cada vez.
Como sei em que pé está o meu pedido?
Pelo painel do pedido no chamado: cada passo do plano, com quem está, o prazo e o que já foi feito. Quem coordena vê a mesma coisa na fila de cumprimento, ordenada pelo que mais dói: passo vencido primeiro, depois o pedido aprovado que ninguém iniciou.