A maioria das operações de TI que tenta montar um catálogo de serviços comete o mesmo erro de origem: trata o catálogo como uma lista única, voltada ao mesmo tempo para o usuário que vai abrir o chamado e para o técnico que vai executá-lo.
O resultado é um documento que não serve bem a nenhum dos dois públicos. A gestão do catálogo de serviços no ITIL 4 resolve esse problema separando duas camadas com propósitos diferentes, e entender essa separação é o que faz a prática funcionar de verdade.
As duas camadas do catálogo que a maioria ignora
O ITIL 4 distingue o catálogo de serviços completo do catálogo de requisição de serviços, e a confusão entre os dois é a raiz da maioria dos catálogos que ninguém usa.
O catálogo de serviços completo é o documento técnico, voltado para dentro da operação de TI. Ele lista cada serviço com profundidade: SLA (Acordo de Nível de Serviço) associado, dependências técnicas, custo de manutenção, responsável interno e nível de criticidade para o negócio.
Esse documento serve para o gestor de TI decidir onde investir, para o financeiro entender o custo de cada serviço e para a área de infraestrutura mapear dependências antes de qualquer mudança.
O catálogo de requisição de serviços é a vitrine que o usuário final vê. É deliberadamente mais simples: mostra apenas o que pode ser pedido naquele momento, em linguagem de negócio, sem os detalhes técnicos que não interessam a quem só quer resolver um problema.
Um usuário não precisa saber qual servidor hospeda o sistema de e-mail para solicitar uma nova caixa de correio.
Quando uma operação tenta usar o catálogo técnico completo como interface de abertura de chamado, o resultado é um portal confuso, cheio de termos que o usuário não entende, e que acaba sendo ignorado em favor do velho hábito de mandar e-mail ou ligar direto para o técnico conhecido.
Por que tentar documentar tudo de uma vez trava o catálogo
Um padrão recorrente em projetos de catálogo de serviços é a tentativa de mapear cada serviço possível antes de publicar qualquer coisa, buscando um catálogo “completo” desde o primeiro dia.
Esse objetivo nunca é alcançado, porque a operação de TI muda mais rápido do que qualquer documentação consegue acompanhar.
O catálogo não é um projeto com data de entrega, é um processo contínuo. A primeira versão pode e deve ser incompleta, cobrindo apenas os serviços de maior volume identificados no histórico de chamados.
Publicar uma versão simples e usá-la gera mais valor do que esperar uma versão perfeita que nunca sai do papel.
O sistema de chamados que permite adicionar itens ao catálogo de requisição de forma incremental, sem precisar reconfigurar tudo a cada inclusão, é o que viabiliza essa abordagem gradual na prática.
O que entra primeiro no catálogo de requisição de serviços
Definir a ordem de prioridade na construção do catálogo evita o efeito de tentar abraçar tudo e não publicar nada. A lógica mais eficiente segue o volume real de chamados, não a percepção de importância.
- Solicitações de altíssima frequência e baixa complexidade, como redefinição de senha ou liberação de acesso padrão, que se beneficiam imediatamente de um formulário estruturado e de aprovação automatizada.
- Solicitações de frequência média que exigem aprovação de terceiro, como instalação de software pago ou acesso a sistemas sensíveis, onde o catálogo formaliza quem precisa aprovar antes da execução.
- Solicitações raras mas de alto custo quando mal executadas, como provisionamento de novo equipamento, onde o formulário estruturado evita que informações críticas fiquem de fora do pedido inicial.
Os relatórios por categoria de chamados já abertos antes de qualquer catálogo formal são a fonte de dados mais confiável para essa priorização, porque mostram o que a operação já faz, não o que alguém imagina que deveria fazer.
Como o catálogo de requisição se conecta ao SLA sem expor complexidade técnica
Cada item do catálogo de requisição precisa de um prazo visível para o solicitante, mas esse prazo carrega, por trás, toda a complexidade calculada na gestão de nível de serviço. O usuário não precisa ver a fórmula, só o resultado: “este pedido costuma ser atendido em até quatro horas”.
Essa tradução é o que separa um catálogo bem construído de uma lista técnica disfarçada de portal de autoatendimento. Se o prazo exibido depende de variáveis que o usuário não controla nem entende, como disponibilidade de licença ou aprovação de outro departamento, o catálogo precisa deixar isso explícito de forma simples, não esconder a informação até o pedido travar na fila.
Como o catálogo técnico orienta decisões que o usuário nunca vê
Enquanto o catálogo de requisição cuida da experiência de quem abre o chamado, o catálogo técnico completo serve a um propósito diferente: dar ao gestor de TI visibilidade sobre onde a operação está investindo esforço e onde está exposta a risco.
Cruzar o catálogo técnico com o volume de incidentes por serviço, por exemplo, revela quais sistemas concentram mais instabilidade em relação à sua importância para o negócio.
Um serviço de baixa criticidade que consome volume alto de chamados pode ser candidato a descontinuação. Um serviço crítico com poucos incidentes registrados pode estar sob monitoramento insuficiente, não necessariamente estável.
Essa análise depende de dados que só existem quando os chamados estão vinculados de forma estruturada a cada serviço do catálogo, e não dispersos em categorias genéricas que não correspondem a nenhum item formal.
Como manter as duas camadas do catálogo sincronizadas
O maior risco de manter dois catálogos separados é deixá-los dessincronizados: o catálogo técnico evolui com mudanças na infraestrutura, mas o catálogo de requisição que o usuário vê continua desatualizado, ou vice-versa.
A sincronização funciona melhor quando existe um responsável único pela governança do catálogo, mesmo que a manutenção do conteúdo seja distribuída entre diferentes áreas técnicas.
Esse responsável garante que toda mudança no catálogo técnico, como a descontinuação de um serviço ou alteração de SLA, seja refletida no catálogo de requisição antes que o usuário tente solicitar algo que já não existe mais daquela forma.
Checklist para implantar a gestão do catálogo de serviços no Milldesk
Antes de publicar a primeira versão do catálogo de requisição, vale validar estes pontos com a equipe:
- Os 10 a 15 tipos de chamado mais frequentes do histórico já têm um item correspondente mapeado, com campos específicos definidos para cada um.
- Cada item tem um prazo visível vinculado ao SLA real daquele tipo de serviço, calculado a partir de dados de atendimento, não de estimativa.
- As aprovações necessárias estão identificadas e configuradas no workflow visual, sem depender de e-mail paralelo fora do sistema.
- Existe um responsável definido pela atualização do catálogo, com rotina clara de revisão quando um serviço muda ou é descontinuado.
- O catálogo técnico completo está separado do catálogo de requisição, evitando que detalhes irrelevantes para o usuário final apareçam no portal de abertura.
O Milldesk permite configurar formulários específicos por tipo de solicitação, com SLA vinculado e fluxo de aprovação definido, sustentando tanto a vitrine simplificada que o usuário acessa quanto os dados estruturados que o gestor de TI precisa para decisão.
Perguntas frequentes
- Catálogo de serviços e catálogo de requisição de serviços são a mesma coisa?
Não. O catálogo de serviços completo é técnico e detalhado, voltado para a gestão interna de TI. O catálogo de requisição é a versão simplificada que o usuário final vê no portal de abertura de chamados. - Por que tentar mapear todos os serviços de uma vez trava o projeto?
Porque a operação de TI muda constantemente e nenhuma documentação alcança esse ritmo. Publicar uma primeira versão incompleta, cobrindo os serviços de maior volume, gera valor imediato em vez de esperar uma versão que nunca fica pronta. - Por que o prazo do catálogo de requisição não deveria expor a complexidade técnica?
Porque o usuário final não precisa entender as variáveis internas que definem o SLA, apenas o resultado prático: quanto tempo aquele pedido específico costuma levar. - Como decidir qual serviço entra primeiro no catálogo de requisição?
Pelo volume real de chamados já registrados no histórico, priorizando solicitações de alta frequência e baixa complexidade antes de itens raros, mas de execução mais delicada. - Quem deve ser responsável pela manutenção do catálogo?
Idealmente uma pessoa ou função única com governança sobre o catálogo, garantindo que mudanças no catálogo técnico sejam refletidas no catálogo de requisição antes que o usuário tente solicitar algo desatualizado.