- A maioria das empresas não precisa de uma equipe interna completa de TI para oferecer suporte eficaz
- Definir níveis (Nível 1 básico, Nível 2 técnico, Nível 3 especialista) antes de escolher ferramentas economiza tempo e dinheiro
- O sistema de chamados é a base. Threads de e-mail e planilhas não são uma central de serviços
- Os SLAs devem ser realistas. Comprometer-se com resposta em 1 hora para tudo cria uma dívida de suporte impossível de quitar
- Provedores de TI gerenciados oferecem uma equipe completa por uma mensalidade, muitas vezes mais barato do que uma única contratação sênior
O que uma central de serviços de TI realmente precisa fazer
Uma central de serviços de TI tem um único objetivo: garantir que, quando algo quebra ou impede alguém de trabalhar, o problema seja resolvido de forma previsível e rastreável. A maioria das organizações que afirma ter uma central de serviços opera algo mais informal: um endereço de e-mail, um chat em grupo e algumas pessoas que respondem quando veem uma mensagem.
Uma central de serviços real recebe solicitações por um canal definido, registra cada uma como item individual, atribui responsabilidade, acompanha o progresso e fecha os chamados com confirmação de resolução. Sem registro, não há visibilidade da fila. Chamados sem dono são ignorados. Sem confirmação de encerramento, a fila se enche de problemas marcados como "provavelmente resolvidos" que ninguém verificou.
A central também precisa lidar com dois fluxos distintos: incidentes (algo quebrou e precisa ser corrigido agora) e solicitações de serviço (um usuário precisa que algo seja configurado, alterado ou explicado). Tratar todas as solicitações da mesma forma gera confusão de prioridades. Um laptop que não liga não está na mesma categoria que uma solicitação para adicionar um novo usuário a uma pasta compartilhada. Sua central precisa distinguir os dois, mesmo em nível básico.
Problemas de TI não resolvidos custam, em média, 22 minutos de produtividade perdida por incidente por trabalhador. Em uma organização de 50 pessoas lidando com alguns problemas diários, isso soma dias de trabalho perdido por mês: um custo que nunca aparece em uma fatura.
Defina seus níveis de suporte antes de comprar qualquer ferramenta
A coisa mais útil que você pode fazer antes de avaliar qualquer software ou serviço é definir os tipos de problemas de TI que sua organização realmente enfrenta e classificá-los em níveis. Isso leva cerca de duas horas, não custa nada e evita que você superengenharie um modelo de suporte para problemas que você não tem.
A maioria dos problemas deve ser resolvida no Nível 1. O que não for resolvido sobe para o Nível 2, e apenas trabalhos genuinamente complexos chegam ao Nível 3.
- Nível 1: Suporte básico. Redefinições de senha, problemas de impressora, dúvidas sobre instalação de software, configuração de e-mail, diagnóstico básico de hardware e qualquer problema resolvível com um artigo da base de conhecimento ou uma sessão remota de 10 minutos. A pessoa que atende o Nível 1 não precisa de conhecimento técnico profundo. Precisa de paciência, uma boa base de conhecimento e acesso a ferramentas de suporte remoto.
- Nível 2: Suporte técnico. Configuração de rede, erros de aplicativos que exigem análise de logs, imagem de dispositivos, configuração de VPN, problemas de licenciamento de software e qualquer coisa que exija acesso de nível administrador. Engenheiros de Nível 2 precisam de habilidades técnicas reais e capacidade de diagnosticar problemas sem um roteiro. Os tempos de resposta são mais lentos que o Nível 1 porque esses problemas exigem mais investigação.
- Nível 3: Suporte especializado. Incidentes de segurança, arquitetura de infraestrutura, integrações personalizadas, alterações de sistemas relacionadas à conformidade e qualquer coisa que exija uma área de especialização que sua equipe de Nível 2 não possui. O Nível 3 pode envolver especialistas externos, um provedor de segurança gerenciado ou a própria equipe de suporte de um fornecedor. Esses chamados têm prazos de resolução mais longos por natureza.
As definições de nível tornam as decisões de contratação e ferramentas diretas. Uma empresa onde 90% dos problemas são de Nível 1 precisa de uma configuração diferente de uma onde mudanças de infraestrutura são constantes. Você pode descobrir que toda sua carga de Nível 1 pode ser gerenciada por um portal de autoatendimento e um provedor gerenciado, sem nenhuma contratação interna.
Chamados e rastreamento: a configuração mínima viável
A regra fundamental de uma central de serviços é: se não está no sistema, não existe. Toda solicitação precisa de um chamado. Todo chamado precisa de um estado (aberto, em andamento, aguardando usuário, resolvido). Todo chamado resolvido precisa de um registro do que foi feito. Isso não é burocracia por si só. É a única maneira de gerenciar uma fila com mais de uma pessoa trabalhando nela, e a única forma de identificar padrões quando o mesmo problema continua aparecendo.
"Uma central de serviços sem sistema de chamados é uma fila que ninguém consegue ver."
Para pequenas e médias empresas, a escolha da ferramenta importa menos do que a disciplina de usá-la. Freshservice, Zoho Desk, Jira Service Management e HelpScout funcionam bem nessa escala. O Freshservice é o mais específico para gestão de serviços de TI: inclui rastreamento de ativos, portal de autoatendimento e regras de automação prontas. O Zoho Desk integra bem com outros produtos Zoho se você já usa esse ecossistema. O Jira Service Management é adequado para equipes de engenharia que já usam Atlassian. Os três podem ser configurados e implantados em um dia.
A configuração mínima necessária antes de entrar em operação é: um canal de entrada (formulário ou endereço de e-mail que cria chamados automaticamente), categorias de chamados que correspondem às suas definições de nível, uma regra de atribuição para que os chamados cheguem à pessoa certa e um relógio de SLA simples para ver o que está atrasado. Tudo mais (gestão de ativos, automação, pesquisas de satisfação) pode ser adicionado depois que o básico estiver funcionando bem. Tentar configurar tudo de uma vez é como as implantações de central de serviços travam.
SLAs: o que comprometer e o que evitar
Um acordo de nível de serviço (SLA) é um compromisso sobre a rapidez com que você responderá e resolverá diferentes tipos de solicitações de suporte. Os SLAs são úteis porque definem expectativas, criam responsabilidade e fornecem uma forma de medir se sua central de serviços está performando. Tornam-se um problema quando são definidos de forma irrealista, pois você passa mais energia gerenciando violações de SLA do que resolvendo problemas.
O erro mais comum que empresas em crescimento cometem é definir o mesmo SLA para tudo. Uma regra única de "responder em uma hora" parece profissional, mas é inviável se você tiver qualquer volume de Nível 2 ou Nível 3. Um problema de roteamento de rede que exige um engenheiro qualificado para investigar não será resolvido em uma hora. Comprometer-se com esse prazo apenas cria uma lista de violações de SLA em que ninguém confia e todos ignoram.
Uma abordagem mais durável é definir SLAs por nível de prioridade. A prioridade é determinada pelo impacto (quantas pessoas são afetadas) e pela urgência (o quanto está bloqueando agora). A tabela abaixo é um ponto de partida razoável para uma empresa com 20 a 150 usuários. Ajuste os prazos para corresponder à sua capacidade de suporte e seja honesto sobre o que você realmente consegue sustentar.
- Crítico (sistema fora do ar, múltiplos usuários afetados): responder em 30 minutos, resolver em 4 horas
- Alto (um usuário bloqueado em sua atividade principal): responder em 2 horas, resolver em 8 horas
- Médio (serviço degradado, solução alternativa disponível): responder em 4 horas, resolver em 2 dias úteis
- Baixo (dúvida, problema menor, não bloqueante): responder em 1 dia útil, resolver em 5 dias úteis
É melhor definir SLAs conservadores e superá-los consistentemente do que definir metas agressivas e perdê-las regularmente. Os usuários se lembram mais das vezes em que você falhou do que das vezes em que cumpriu. Se você trabalha com um provedor gerenciado, os SLAs no seu contrato devem corresponder ao que você publica internamente. Divergências entre seus compromissos internos e as obrigações contratuais do provedor criam lacunas que os usuários sempre percebem.
Evite criar metas de SLA baseadas no que soa bem em vez do que sua capacidade suporta. Se seu engenheiro de Nível 2 é uma pessoa cobrindo múltiplas responsabilidades, um SLA de resolução de 4 horas para problemas complexos vai ser violado constantemente. Comece com o que você consegue entregar com consistência e aperte os SLAs conforme sua capacidade cresce.
Quando contratar um provedor de serviços gerenciados
Um provedor de serviços gerenciados de TI (MSP) dá acesso a uma equipe completa de profissionais de TI por um valor mensal fixo. Na prática, isso geralmente cobre seu suporte de Nível 1 e Nível 2, monitoramento proativo da infraestrutura, gestão de patches e, com frequência, serviços de segurança. O modelo funciona porque o MSP distribui os custos de pessoal especializado entre muitos clientes. Você obtém o benefício de uma equipe sem o custo de construir uma.
O argumento financeiro é direto. Um engenheiro de TI sênior com habilidades para cobrir suporte de Nível 2, algum conhecimento de segurança e competência em infraestrutura custa entre R$120.000 e R$200.000 por ano no Brasil, sem contar benefícios, equipamentos e overhead de gestão. Um contrato com um MSP de médio porte para a mesma organização tipicamente custa uma fração desse valor. Você não está apenas comprando suporte mais barato. Está comprando cobertura para férias, doenças e os períodos de lacuna que acontecem quando uma única pessoa interna sai. A continuidade tem valor real.
A questão de quando contratar um MSP em vez de contratar internamente depende do volume e da variedade. Se suas solicitações de TI são previsíveis em tipo e baixas em volume, um portal de autoatendimento bem configurado e um recurso interno em meio período podem ser suficientes. Se suas solicitações variam amplamente em complexidade técnica, ou se você precisa de cobertura 24 horas, monitoramento de segurança ou suporte de TI relacionado à conformidade, um MSP é quase sempre a opção mais econômica e resiliente. Um modelo híbrido também é comum: um MSP cuida da fila do dia a dia enquanto um gerente de TI interno cuida dos relacionamentos com fornecedores, compras e decisões estratégicas.
Medindo se sua central de serviços está funcionando
Uma central de serviços que você não consegue medir é uma que você não consegue melhorar. A maioria das ferramentas de chamados fornece relatórios básicos por padrão, e você não precisa de análises complexas para obter insights úteis. Comece com quatro métricas e revise-as mensalmente. Depois que estiverem estáveis e compreendidas, adicione mais profundidade. Perseguir dez métricas desde o início geralmente significa que nenhuma delas recebe atenção adequada.
As quatro métricas mais importantes nos estágios iniciais de uma central de serviços são: tempo de primeira resposta (quanto tempo até o usuário receber a confirmação de que o chamado foi visto), tempo de resolução (quanto tempo desde a criação do chamado até a resolução confirmada), taxa de conformidade com SLA (qual percentual dos chamados é resolvido dentro do prazo comprometido) e taxa de problemas recorrentes (quantos chamados neste mês são sobre o mesmo problema subjacente que apareceu antes). Este último é particularmente valioso. Uma alta taxa de recorrência indica que sua central está corrigindo sintomas, não causas. Problemas de impressora recorrentes toda semana são um problema de compras de hardware, não um problema de suporte.
Além dos números, uma breve pesquisa de satisfação enviada ao fechar o chamado vale a pena ser implementada cedo. Uma única pergunta ("Seu problema foi resolvido satisfatoriamente?") com resposta sim ou não e um campo de comentário opcional fornece sinais qualitativos que as métricas sozinhas não conseguem oferecer. Usuários insatisfeitos apesar de um chamado marcado como resolvido geralmente estão apontando algo importante: a correção foi temporária, a comunicação foi ruim ou o tempo de resolução estava tecnicamente dentro do SLA mas parecia inaceitavelmente lento dado o impacto. Esse feedback é valioso se você agir com base nele.
O framework ITIL, mantido pela Axelos, é o padrão do setor para processos de gestão de serviços de TI e define as práticas mencionadas neste guia. O itSMF Netherlands é o organismo profissional local para praticantes de gestão de serviços.