Quando todas as solicitações chegam como urgentes, o problema pode estar na ausência de um acordo sobre o que a empresa oferece, quem atende e como a prioridade é definida. Um catálogo de serviços organiza esse acordo. Ele transforma pedidos vagos em serviços identificáveis, com informações de entrada, responsáveis, critérios de conclusão e expectativas de atendimento.
Este guia apresenta um desenho de sistema para empresas que precisam organizar demandas de manutenção, tecnologia, financeiro, compras ou apoio administrativo. O objetivo não é implantar burocracia para cada mensagem. É permitir que solicitante e equipe entendam o mesmo compromisso, inclusive quando houver dependências e exceções. Os exemplos são hipotéticos e não representam resultados medidos de clientes.
1. Comece pela unidade de serviço, não pelo formulário
Um catálogo que oferece somente a opção “outros” transfere o trabalho de classificação para o atendente. No extremo oposto, centenas de opções quase iguais dificultam a escolha. A unidade de serviço deve representar uma entrega que o solicitante reconhece: corrigir acesso a um sistema, cadastrar fornecedor, avaliar compra ou reparar equipamento.
Reúna uma amostra de pedidos recentes e identifique o resultado esperado de cada um. Agrupe os que utilizam regras, informações e competências semelhantes. Preserve diferenças que alteram o fluxo. Solicitar acesso novo e remover acesso de alguém que saiu da empresa podem parecer variações do mesmo tema, mas têm riscos, responsáveis e urgências distintos.
Para cada serviço, escreva uma frase verificável de conclusão. “Resolver problema financeiro” é amplo demais. “Corrigir o centro de custo de um lançamento, com aprovação do responsável e histórico da mudança” permite desenhar o processo e testar o sistema.
2. Defina o contrato operacional do serviço
O contrato operacional deve indicar quem pode solicitar, quais informações são necessárias, quais ações estão incluídas e o que acontece após o envio. Especifique também o que não está coberto. Uma solicitação de avaliação de compra não equivale à autorização para contratar o fornecedor.
Campos obrigatórios precisam ter relação com decisões reais. Se ninguém utiliza uma informação para executar, priorizar ou auditar o atendimento, questione a coleta. Um formulário longo não garante uma demanda bem compreendida. A própria descrição do serviço pode orientar o usuário e reduzir campos desnecessários.
| Elemento | Pergunta de desenho | Exemplo hipotético |
|---|---|---|
| Entrega | O que será concluído? | Acesso ao módulo aprovado |
| Elegibilidade | Quem pode pedir? | Gestor da área solicitante |
| Dados de entrada | O que permite agir? | Usuário, perfil e justificativa |
| Dependência | Quem precisa decidir? | Responsável pelo sistema |
| Evidência | Como demonstrar conclusão? | Aprovação e concessão registradas |
| Exceção | Quando o fluxo muda? | Pedido de privilégio administrativo |
3. Separe prioridade de preferência pessoal
Uma prioridade útil combina impacto e urgência. Impacto representa a abrangência do problema: uma pessoa, uma equipe ou uma operação crítica. Urgência representa o tempo disponível antes de uma consequência relevante. O cargo do solicitante pode indicar quem decide, mas não deve substituir a análise operacional.
Crie critérios observáveis. “Alta prioridade” precisa explicar qual processo está interrompido e se há alternativa temporária. Um pedido importante para a semana seguinte pode ser planejado. Uma falha que bloqueia o faturamento do dia exige outro tratamento. O sistema deve registrar a justificativa e permitir revisão por uma pessoa autorizada.
Evite mostrar uma lista livre em que todos escolhem “crítico”. Faça perguntas sobre consequências e disponibilidade de alternativa. A classificação sugerida pode ser ajustada pela equipe, mas a alteração deve aparecer no histórico. Isso ajuda a aprender quais descrições de serviço precisam ser melhoradas.
4. Modele os relógios do SLA explicitamente
Tempo de primeira resposta, tempo de diagnóstico e tempo de resolução são medidas diferentes. Uma resposta automática pode confirmar recebimento, mas não prova que uma pessoa compreendeu a demanda. Defina exatamente o evento que inicia e encerra cada relógio.
Também é necessário decidir o calendário aplicável. O serviço pode operar em dias úteis, com feriados locais e jornadas diferentes por unidade. Um sistema que soma horas corridas enquanto o compromisso utiliza expediente exibirá atrasos inexistentes. Não deixe a conversão de calendários espalhada por telas e relatórios.
Pausas exigem motivo e responsabilidade. “Aguardando solicitante” não pode se tornar um mecanismo para esconder atraso interno. Registre a informação solicitada, o momento da pausa, quem pode retomar e o que ocorre se a resposta não chegar. Pausar o relógio não elimina o tempo total vivido pelo usuário; os dois valores devem permanecer visíveis em análises apropriadas.
5. Use estados que expliquem o trabalho
Um fluxo inicial pode conter recebido, em triagem, em atendimento, aguardando informação, aguardando aprovação, resolvido e encerrado. Cada transição deve ter uma condição. Resolver significa disponibilizar uma solução; encerrar pode depender de aceite ou do término de um período previamente acordado.
Inclua reabertura. Se o solicitante informa que a solução não funcionou, o sistema precisa relacionar a nova interação ao atendimento anterior, preservar os tempos e explicar como o SLA será tratado. Criar um pedido totalmente novo para cada retorno pode produzir indicadores aparentemente melhores e esconder reincidência.
Para demandas longas, utilize tarefas internas vinculadas. O solicitante não precisa receber todos os detalhes de execução, mas deve enxergar progresso relevante, dependências e próximo passo. A interface deve diferenciar um prazo estimado de um compromisso aprovado.
6. Exemplo: cadastro de fornecedor
Considere uma empresa que recebe pedidos de cadastro por e-mail. Parte dos documentos falta, o financeiro cobra compras e o solicitante não sabe quem está com a demanda. Um sistema pode oferecer um serviço específico, explicar os documentos necessários e encaminhar o pedido ao responsável correto.
O recebimento completo inicia o relógio de análise definido pela empresa. Uma divergência documental gera solicitação objetiva de correção, com o motivo registrado. A aprovação de cadastro não deve liberar automaticamente pagamentos ou alterações bancárias. São decisões diferentes e precisam de permissões próprias.
Na conclusão, o solicitante recebe a identificação do fornecedor e eventuais restrições. Se houver documento com validade, o sistema agenda a revisão correspondente. O ganho esperado é clareza de responsabilidade; qualquer redução de tempo deve ser medida antes e depois com o mesmo critério, em vez de ser presumida.
7. Estruture os dados para preservar contexto
Separe a definição do serviço das solicitações abertas. Uma mudança no prazo padrão não deve reescrever silenciosamente o compromisso assumido em pedidos antigos. Guarde a versão da política aplicada, a prioridade aprovada e o calendário utilizado.
Uma estrutura pode incluir serviços, versões de serviço, solicitações, participantes, tarefas, aprovações, eventos de estado e intervalos de relógio. O histórico deve permitir reconstruir o atendimento sem depender da lembrança do operador. Comentários internos e comunicações ao solicitante precisam ter visibilidade distinta.
O modelo de gestão de serviços do ITIL pode orientar o vocabulário de gestão. A adoção de uma ferramenta ou de termos conhecidos, porém, não substitui o acordo operacional específico da empresa. O desenho apresentado aqui é uma proposta editorial de implementação, não uma certificação de conformidade.
8. Integre sem perder a identidade da solicitação
Se pedidos entram por formulário, e-mail ou mensageria, todos devem receber uma referência estável. Uma atualização de canal não pode criar outra demanda por acidente. Preserve a origem, mas mantenha a situação operacional em uma fonte definida.
Notificações precisam comunicar mudanças úteis, evitando uma mensagem para cada evento técnico. O solicitante deve entender o que aconteceu e se precisa agir. Nas integrações, verifique permissões, repetição de eventos e indisponibilidade do fornecedor. Consulte também o manual de notificações transacionais da A2CR.
9. Indicadores que ajudam a melhorar o serviço
Analise volume por serviço, tempo total, tempo de trabalho, espera por terceiros, reabertura e causas recorrentes. Mostre a distribuição dos tempos, não apenas uma média. Poucos casos muito longos podem desaparecer em um número agregado ou distorcê-lo completamente.
Separe cumprimento de prazo de satisfação e resolução efetiva. Um atendimento encerrado rapidamente pode gerar outra solicitação pelo mesmo problema. A gestão deve investigar esse vínculo e revisar instruções, responsabilidades ou o serviço oferecido. Indicadores servem para orientar decisões, não para incentivar encerramentos artificiais.
Checklist de implantação
- Identificar serviços reconhecíveis pelo solicitante.
- Definir entrega, escopo e critérios de conclusão.
- Estabelecer impacto e urgência com exemplos.
- Documentar calendário, feriados e pausas permitidas.
- Diferenciar confirmação automática e primeira resposta útil.
- Versionar a política aplicada a cada pedido.
- Registrar tarefas, aprovações e dependências.
- Testar reabertura, duplicidade e mudança de prioridade.
- Conferir visibilidade de comentários e anexos.
- Medir resolução efetiva e reincidência.
Checklist para usar com sua equipe
Baixe o checklist editável em CSV e registre a conferência, o responsável e as observações da implantação.
Perguntas frequentes
Toda empresa precisa de uma ferramenta especializada?
Não. Um volume pequeno pode ser organizado com um fluxo simples. O investimento em sistema faz sentido quando variedade, responsabilidade, histórico e acompanhamento ultrapassam a capacidade do controle atual. O catálogo pode ser definido antes da escolha da tecnologia.
O cliente deve visualizar todos os indicadores internos?
Não necessariamente. Ele precisa de informações coerentes com o compromisso assumido. Métricas internas podem conter dados de outras equipes ou detalhes sensíveis. Transparência não exige expor indiscriminadamente toda a operação.
A IA pode classificar e responder às solicitações?
Pode sugerir classificação, resumir contexto e preparar respostas. Alterar prioridades, aprovar acesso e encerrar casos exige regras e limites definidos. A classificação automática precisa ser avaliada com demandas reais e permitir correção humana.
Para organizar um catálogo conectado à sua operação, prepare um briefing com a A2CR. Descreva quais pedidos chegam, quem executa e onde hoje se perde o contexto.
Autoria: Agência A2CR. Preparação editorial: 12 de novembro de 2026. Exemplos hipotéticos. Referências consultadas como apoio conceitual; regras e metas devem ser definidas para cada operação.
