Resumo
Planejamento de cobertura de suporte são três decisões: em quais horas e canais você responde, quantos agentes cada hora precisa e o que acontece com os tickets que chegam quando ninguém está online. A maioria das equipes começa pelo relógio ("vamos fazer fins de semana?"). Eu começaria pelo canal, porque um cliente de chat espera segundos e um cliente de e-mail espera horas, e essa diferença decide a maior parte da sua escala.
Faça a conta antes de contratar. Puxe o mapa de calor de tickets por hora do seu helpdesk, multiplique o volume pelo tempo de atendimento e some 15-35% de shrinkage, a faixa que a própria documentação de gestão de força de trabalho da Zendesk chama de padrão do setor. Uma posição atendida 24/7 dá cerca de 6 pessoas, e é por isso que quase nenhuma equipe pequena deveria cobrir as noites com humanos.
Para as horas que você não consegue cobrir, um colega de helpdesk com IA como a eesel responde os tickets de rotina dentro do seu helpdesk atual e deixa os difíceis marcados para a manhã. Humanos ficam com chat ao vivo, telefone e quedas; a IA assume o "cadê meu pedido?" das 2 da manhã.
O que é planejamento de cobertura de suporte?
Planejamento de cobertura de suporte é o trabalho de casar os horários da sua equipe com os momentos em que os clientes realmente precisam de você. Ele responde a três perguntas:
- Em quais horas e dias respondemos, por canal? E-mail, chat, telefone e redes sociais não precisam dos mesmos horários.
- Quantos agentes precisamos em cada hora em que estamos abertos? Não por dia, por hora, porque o volume não é constante.
- O que acontece fora dessas horas? Uma resposta automática, uma pessoa de plantão, um parceiro ou um agente de IA.
Estou na equipe de suporte da eesel, então convivo todo dia com as consequências desse plano. E como a eesel passou anos colocando IA em filas de suporte ao vivo, vi o mesmo padrão em muitas equipes: o plano de cobertura foi decidido uma vez, no feeling, quando a equipe tinha três pessoas, e ninguém o revisitou quando o volume triplicou.
Ele também é confundido com temas vizinhos. O planejamento de cobertura decide quando você está aberto. Suas políticas de SLA decidem com que rapidez você promete responder dentro dessas horas. Uma passagem de turno é o que acontece nas emendas. Se a cobertura estiver errada, os outros dois não conseguem salvar você.
Passo 1: Descubra quando os clientes realmente escrevem
Comece com dados, não com suposições. Todo grande helpdesk hoje tem um relatório que mostra o volume de tickets por hora e dia, e ele leva uns dez minutos para ser lido.
| Helpdesk | Relatório a abrir | O que mostra | Plano |
|---|---|---|---|
| Gorgias | Busiest times | Mapa de calor por hora e dia com seu horário comercial marcado; tickets criados, respondidos, fechados | Todos os planos de helpdesk |
| Front | Relatório Workload, Busiest times | Mapa de calor de novas conversas, mensagens e colegas ativos; das 9h às 17h por padrão, expansível para 24 horas | Todos os planos atuais |
| Help Scout | Relatório All Channels | Mapa de calor "Busiest time of day" mais a métrica Busiest Day | Não informado na documentação |
| Freshdesk | Ticket volume trends (Load Analysis) | Tickets criados, resolvidos, reabertos e não resolvidos por hora | Não informado para este relatório |
| Zendesk | Receita do Explore, tickets por hora do dia | Relatório personalizado sobre "Ticket created - Hour", mais uma receita de horários de pico por canal | Suite Professional ou superior, ou Explore Professional |
Há duas coisas a procurar no mapa de calor. Primeiro, a óbvia: onde estão as células escuras. Segundo, e mais útil, as células escuras fora dos seus horários atuais. A documentação do Gorgias diz melhor do que eu: "A dark cell outside your business hours is demand arriving when nobody is scheduled."
Depois olhe criados versus resolvidos por hora, porque as horas em que os criados vencem são onde começa um backlog de tickets. O Load Analysis do Freshdesk foi feito exatamente para isso, e a documentação diz que, se os criados superam os resolvidos em um período, "you should add more agents during this time period."
Use meses de histórico, não dias (o previsor da Zendesk parte de seis meses de tickets), e tire os picos conhecidos da base. Uma marca de entrega de flores que treinou a eesel com seus tickets passados pediu que a eesel excluísse os picos de Dia dos Namorados e Dia das Mães pelo mesmo motivo: semanas de pico distorcem como é uma terça-feira normal. Planeje primeiro a base e depois os picos separadamente (passo 6).
Passo 2: Decida a cobertura por canal, não por relógio
Esta é a mudança de ótica que eu mais defenderia. "Estamos abertos no sábado?" é a pergunta errada. A certa é: quanto tempo um cliente neste canal espera antes que a demora nos custe algo?
| Canal | Quanto os clientes esperam | O que cobertura significa |
|---|---|---|
| Telefone | Segundos | Uma pessoa na linha, ou a linha está fechada |
| Chat ao vivo | Um ou dois minutos | Uma pessoa online, ou o chat muda para "deixe uma mensagem" |
| E-mail e formulários web | Horas | Alguém responde dentro da janela informada, que pode começar na manhã seguinte |
| DMs de redes sociais | Horas, mas em público | Igual ao e-mail, com vigilância mais próxima de reclamações |
| Quedas e problemas de segurança | Minutos, qualquer que seja o canal | Uma pessoa de plantão, mesmo quando todo o resto está fechado |
O próprio mecanismo de previsão da Zendesk trata os canais assim. Sua documentação de previsão diz que o volume de e-mail que chega fora do horário com equipe é distribuído "over the period of First Response Time", enquanto o volume de voz e chat fora do horário não é transferido de forma alguma. Em português claro: um e-mail às 23h é trabalho de amanhã, uma ligação perdida está perdida.
Isso dá um padrão sensato para a maioria das equipes:
- Canais ao vivo funcionam apenas nas horas em que você consegue atendê-los direito. Fora delas, o chat muda para captura de e-mail. Help Scout, Front e Zendesk oferecem isso, e meu guia de mensagens offline do Zendesk cobre uma configuração.
- E-mail recebe uma promessa de resposta ("em até 4 horas úteis") em vez de equipe o dia todo, que é o núcleo do suporte assíncrono, e seus timers de SLA seguem a mesma escala.
- Quedas têm uma pessoa de plantão nomeada, todos os dias, com uma lista curta de acionamento.
Um comentarista do Hacker News fez a versão do comprador desse ponto: para SaaS, "I'd be fine with business hour support. SaaS failures don't directly cost me money and/or reputation." Seus clientes podem ser diferentes. Um produto de pagamentos ou um sistema hospitalar não pode fazer essa troca. Seja honesto sobre qual é o seu caso.
Passo 3: Calcule quantos agentes você precisa a cada hora
Agora a aritmética. A versão simples é um modelo de carga de trabalho:
Agentes a escalar = (tickets na hora × minutos por ticket ÷ 60) ÷ ocupação ÷ (1 − shrinkage)
Minutos por ticket é seu tempo médio de atendimento. Dois dos outros termos precisam de definição, e o glossário de WFM da Zendesk tem definições limpas:
- Ocupação é o tempo que os agentes gastam atendendo trabalho dividido pelo tempo total de trabalho. Ninguém sustenta 100%; o próprio exemplo da Zendesk limita em 90%.
- Shrinkage cobre "lunch breaks, training sessions, scheduled meetings" mais "absenteeism, holiday, vacation, sick days, lateness, and leaving early." A Zendesk coloca o padrão do setor em 15-35%.
Coloque aqui seus próprios números. A calculadora dá os agentes a escalar na sua hora de pico e o número de agentes em tempo integral para cobrir uma semana de horas abertas.
O modelo de carga de trabalho é um piso, não a resposta, para canais ao vivo. Clientes de chat e telefone entram em fila, e a fórmula que as ferramentas de força de trabalho usam para dimensionar essa fila é o Erlang C, que acrescenta agentes para que uma parcela definida dos contatos seja atendida dentro de um tempo-alvo. O Zendesk WFM calcula a equipe necessária por intervalo de 15 minutos "based on a modified version of Erlang C."
O Erlang C tem uma peculiaridade conhecida em volume baixo. O documento de boas práticas da Zendesk alerta que "for low-volume workstreams, the industry-standard Erlang C formula may result in slightly higher staffing recommendations." O próprio exemplo mostra o quanto: 38 e-mails por dia a 210 segundos cada são cerca de 2,2 horas de atendimento, mas o modelo chega a "1.5 agents per day", ou 12 horas de tempo com equipe. Essa diferença é o custo de garantir resposta rápida em uma fila tranquila, e é o argumento mais forte para não cobrir horas tranquilas com pessoas.
Quanto custa de verdade uma posição 24/7
Este é o número que encerra a maioria dos debates sobre "devemos ir para 24/7?".
Uma semana tem 168 horas. O glossário da Zendesk conta um FTE como 40 horas por semana. São 4,2 pessoas para manter uma única cadeira ocupada, antes de qualquer pessoa tirar férias. Some 30% de shrinkage e são 6 pessoas, para uma posição. Se você quiser dois agentes de madrugada, dobre.
Um comentarista do Hacker News que já passou por isso resumiu o que a planilha costuma deixar de fora:
"Still need enough staff at each site to handle rotation for covering weekends and for people to go on holiday and get sick or quit for new jobs etc."
Passo 4: Escolha um modelo de cobertura para as horas que você não consegue atender
Quando você sabe seus horários de pico e sua equipe, está escolhendo como lidar com o resto. Estes são os seis modelos que mais vejo, com o que cada um custa.
| Modelo | Como funciona | Melhor para | O problema |
|---|---|---|---|
| Só horário comercial | Uma escala, uma promessa de resposta clara, resposta automática fora do horário | SaaS B2B em que um atraso não custa dinheiro ao cliente | Backlog de segunda de manhã |
| Turnos escalonados | Horários de início espalhados (7-15, 9-17, 11-19) para esticar uma equipe por 12 horas | Equipes de 4+ em uma região | Cobertura fina nas pontas |
| Rodízio de plantão | Uma pessoa carrega um telefone ou pager para urgências fora do horário | Quedas, contas VIP | Desgasta as pessoas rápido |
| Follow-the-sun | Equipes em 2-3 regiões cobrem cada uma o seu dia | Clientes globais, 15+ agentes | Passagens, gestão duplicada |
| Fora do horário terceirizado | Um parceiro atende noites e fins de semana (guia de terceirização) | Suporte a consumidores com muito telefone e alto volume | Transferência de conhecimento e qualidade |
| IA na primeira linha mais horas humanas | A IA responde tickets de rotina o dia todo; humanos pegam o resto quando estão online | Equipes com grande parcela de rotina | Exige bom conhecimento e limites claros |
Algumas notas de equipes que já viveram isso.
Rodízios de plantão são mais baratos que turnos e mais caros do que parecem. Estar de plantão limita sua vida mesmo em semanas tranquilas:
"We were a small team so rotation was weekly and you would be on support every 4 weeks or so. I couldn't go to the gym after work without worrying about a call coming in and ruined weekends for me."
Reserve os rodízios para emergências genuínas, com uma definição escrita e curta do que conta como uma e um processo de escalonamento claro por trás.
Contratações dedicadas vêm antes do 24/7, e há um gatilho aproximado para elas. A regra de bolso de um fundador: se a equipe gasta 20 ou mais horas por semana em suporte, "hire a dedicated support person or agency, even if they're part time", e depois "schedule dedicated hours for each person to be on call." Essa é a questão da estrutura da equipe de suporte em uma frase.
Contratar para o dia não resolve a noite. Outro comentarista, cuja equipe de 10 pessoas cresceu rápido, descreveu contratar pessoas dedicadas ao suporte e ainda assim descobrir que "after hours were an issue." Se sua lacuna é de madrugada, mais contratações diurnas não vão fechá-la.
É aí que entram o suporte follow-the-sun, uma equipe offshore ou uma primeira linha de IA. Comparei separadamente o custo de equipes offshore com o da IA.
Passo 5: Monte a escala e configure seu helpdesk
Um plano que vive só em uma planilha se afasta da realidade em um mês. Coloque-o no seu helpdesk, para que timers, roteamento e respostas automáticas o sigam. Veja o que cada um faz e onde ficam as barreiras por plano.
| Horário comercial | Várias escalas (regiões, canais) | Turnos que mudam o status do agente | |
|---|---|---|---|
| Zendesk | Uma escala no Suite Growth e Professional | Enterprise (documento de escala) | Não nativo; exige o complemento WFM |
| Freshdesk | Growth e superior | Pro ($55/agente/mês anual) | Enterprise ($89), Agent Shifts |
| Help Scout | Plus ($45) e superior, por caixa de entrada | Por caixa de entrada, Plus e superior | Não disponível |
| Gorgias | Basic e superior, por integração | Por integração | Não disponível |
| Front | Professional ($65), por caixa de entrada | Por caixa de entrada | Enterprise ($105), Shifts |
A armadilha é o status. O documento de status de agente da Zendesk diz "operating hours won't set an agent's status", então uma escala que diz "fechado" não impede o roteamento para alguém que esqueceu de ficar offline. Corrija isso primeiro, porque o roteamento inteligente é tão bom quanto os status que lê.
Meus guias de horário comercial do Zendesk e escalas de feriados cobrem a configuração, e as automações fora do horário tratam do que acontece com tickets que chegam fora dele.
No Gorgias, respostas automáticas programadas fazem o mesmo trabalho.
Quando trazer software de gestão de força de trabalho
Você não precisa de uma ferramenta de gestão de força de trabalho (WFM) para planejar a cobertura de uma equipe de seis. Precisa quando está escalando algumas dezenas de pessoas entre turnos e canais, porque a ferramenta faz previsão por intervalo e monta as escalas para você.
- Zendesk WFM prevê o volume "for up to a year in the future" a partir do seu histórico de tickets (precisa de pelo menos um mês de dados) e mostra a equipe necessária por intervalo de 15 minutos. O preço público é o Workforce Engagement Bundle, WFM mais QA, a
$50por agente por mês com pagamento anual na página de preços da Zendesk, e os complementos são comprados para todos os agentes da conta. - Assembled lista Workforce Management a
$25,$45e$75por mês para seus níveis Core, Pro e Enterprise em sua página de preços, sem informar se é por agente. Sua página de WFM diz que os planos de equipe "account for AI agent capacity alongside human resources", que é a forma certa de pensar.
Passo 6: Planeje picos, feriados e ausências
Seu plano base cobre uma semana normal. Três coisas o quebram.
Picos sazonais. Equipes de e-commerce conhecem os seus: Black Friday, feriados, semanas de lançamento. Uma marca de suplementos que chegou à eesel atende cerca de 7.000 tickets por mês com alta temporada de novembro a maio, e sua equipe não dava conta do volume sozinha. Planeje a cobertura de pico como uma camada separada: equipe temporária, hora extra ou um agente de IA assumindo a parcela repetitiva por meio de deflexão de tickets. Meu guia de suporte na Black Friday percorre o roteiro.
Feriados. Adicione todo feriado público de toda região que você atende à escala do seu helpdesk, para que os relógios de SLA pausem e as respostas automáticas digam a coisa certa. Depois confira o dia seguinte a cada um, que costuma ser seu pior dia do mês.
Ausências e rotatividade. Isso é shrinkage de novo, e é onde os planos falham em silêncio. Duas pessoas fora ao mesmo tempo em uma equipe de seis cortam sua capacidade em um terço. Perder um agente sênior dói ainda mais, porque o conhecimento dele vai junto; uma empresa de serviços de TI procurou a eesel especificamente para capturar o conhecimento de dois agentes seniores que estavam de saída antes que eles fossem embora. Escrever respostas na sua base de conhecimento também é planejamento de cobertura.
Onde a IA entra em um plano de cobertura de suporte
É aqui que o plano fica mais barato. Se seis pessoas mantêm uma posição ocupada de madrugada, a pergunta para a maioria das equipes não é "como cobrimos as noites?", e sim "quanto da noite realmente precisa de uma pessoa?". Para a maioria das filas a resposta é menos do que você imagina, e esse é todo o argumento a favor do suporte com IA fora do horário.
A forma que funciona: sua equipe cobre as horas movimentadas dos dias úteis; um agente de IA cobre todo o resto como primeira linha; uma pessoa fica de plantão para quedas; e tudo de que a IA não tem certeza espera, marcado e resumido, o próximo turno com equipe. A IA preenche as células vazias, não as movimentadas.
A Anytime Fitness é o exemplo mais limpo que posso apontar. Antes da eesel, um membro que fazia uma pergunta às 22h esperava até a manhã; agora as perguntas comuns são respondidas a qualquer hora em mais de 5.000 academias. A Gridwise viu a eesel resolver 73% de seus tickets de nível 1 no primeiro mês, segundo sua citação na página do agente de helpdesk com IA da eesel.
A regra que torna a IA fora do horário segura é a que os compradores pedem em quase toda ligação. Um líder de CX de uma marca de suplementos no Gorgias, que atende cerca de 7.000 tickets por mês, disse sem rodeios:
"I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
Esse é o plano de cobertura em miniatura: a IA pega de madrugada a parcela de que tem certeza, e o resto chega na fila da manhã com contexto anexado. A mesma ideia move o suporte 24/7 com IA. Se você quer a mecânica, meu guia sobre quando a IA deve passar o atendimento a cobre.
Uma lição que a eesel aprendeu do jeito difícil: coloque seu horário comercial e suas regras de passagem nas próprias configurações de escala e roteamento do helpdesk, não apenas nas instruções da IA. A IA de um cliente errou a lógica de fuso horário apesar de instruções detalhadas no prompt. A escala do helpdesk é a fonte da verdade; a IA deve ler dela.
Erros comuns no planejamento de cobertura de suporte
- Planejar por dia, não por hora. Uma equipe "com quadro completo" na segunda ainda pode estar afogada das 9 às 11h. Use o mapa de calor.
- Esquecer o shrinkage. Um plano com shrinkage zero fica com falta de pessoal toda semana. Comece em 30% se você não sabe o seu.
- Mesmos horários para todos os canais. Abrir o chat ao vivo em horas que você não consegue atender transforma uma boa experiência de e-mail em uma experiência ruim de chat. Feche o chat antes de deixá-lo sem equipe; comparei separadamente chatbots e chat ao vivo.
- Cobrir horas tranquilas com pessoas. O Erlang C infla intervalos de baixo volume, e as noites são em sua maioria de baixo volume. É a cobertura mais cara que você pode comprar.
- Sem responsável por quedas. Todo plano precisa de uma pessoa de plantão nomeada para o que não pode esperar, mesmo que todo o resto esteja fechado.
- Nunca revisitar o plano. Rode o mapa de calor de novo a cada trimestre e depois de qualquer grande lançamento, junto com seus outros KPIs de atendimento ao cliente. Acompanhe o tempo de primeira resposta por hora do dia; se disparar em uma faixa, essa é sua próxima lacuna.
eesel para planejamento de cobertura de suporte
O colega de helpdesk com IA da eesel preenche as células do seu plano de cobertura que são caras demais para atender com pessoas. Ele entra no helpdesk que você já usa, seja Zendesk, Freshdesk, Gorgias, Help Scout ou Front, aprende com seus tickets passados, sua central de ajuda e suas macros, e responde tickets de rotina nas noites e fins de semana. Tudo de que ele não tem certeza fica na fila com um resumo para o seu próximo turno.
Você pode rodá-lo sobre centenas de tickets passados antes que ele toque em um ao vivo, e ver exatamente que parcela do seu volume fora do horário ele teria atendido. E ele não adiciona posições para o turno da noite: o plano Teammate começa em $299 por mês para 500 créditos, em que um ticket ou um chat custa um crédito.
Se o seu mapa de calor tem células escuras depois das 18h e você prefere não contratar seis pessoas para preenchê-las, experimente a eesel grátis na sua própria fila e veja o que ela teria respondido no último fim de semana.