Vale a pena um sistema de pedidos gratuito? O que ver antes de escolher

Vale, para começar. Um sistema de pedidos de suporte gratuito resolve o primeiro problema de quase todo o suporte: tirar os pedidos da caixa de e-mail de uma pessoa e colocá-los numa lista que toda a equipa vê. O que costuma não resolver aparece três a seis meses depois, quando o volume cresce e o pedido deixa de ser só uma pergunta para passar a ser trabalho de outras pessoas.

Este texto separa as duas fases. Primeiro, o que um sistema gratuito oferece de facto. Depois, os limites que aparecem com o uso e um critério simples para decidir se fica onde está ou muda.

O que um sistema de pedidos gratuito resolve bem

A diferença entre "sem sistema" e "com qualquer sistema" é enorme. Mesmo uma ferramenta básica traz ganhos que justificam o esforço de instalar.

• Uma fila única. Cada pedido passa a ser um registo com número, solicitante, data e responsável. Acabou o "alguém viu aquele e-mail do cliente da Padaria Bom Jesus?".
• Histórico por cliente. Quando o mesmo cliente volta, quem atende vê o que já foi tratado, sem perguntar de novo.
• Estados. Aberto, em curso, a aguardar cliente, resolvido. Parece pouco, mas é o que permite responder "como está o meu pedido?" sem abrir três conversas.
• Contagem. Pela primeira vez fica a saber quantos pedidos entram por semana. Esse número, por si só, já muda as conversas sobre contratar mais pessoas.

Se a sua equipa de suporte tem uma ou duas pessoas, atende por um único canal e não precisa de prometer prazos por contrato, um sistema gratuito pode ser tudo de que precisa durante bastante tempo. Não mude de ferramenta por mudar: mude quando um limite concreto começar a custar dinheiro ou clientes.

Os limites que aparecem depois

Os limites abaixo não são defeito de uma ferramenta específica. São consequência de o produto gratuito ser, em geral, pensado para a fila e não para a operação à volta dela. Confira cada um na ferramenta que utiliza, plano a plano.

1. SLA: o prazo existe só na cabeça da equipa

No início ninguém precisa de SLA. Depois de um cliente se queixar de que esperou três dias, todos passam a precisar. O que se descobre então é que o sistema não mede prazos: não mostra quanto falta, não avisa quando vai expirar e não distingue um pedido urgente de uma dúvida.

Um SLA útil tem três relógios (primeira resposta, resposta seguinte e resolução), pausa quando a bola está do lado do cliente e aviso antes de ser ultrapassado. Se quiser perceber cada um deles, o guia de SLA explica o conceito, e o post SLA de atendimento na prática mostra como calibrar os números.

2. Canais: o cliente não escreve onde o sistema espera

Muitos sistemas gratuitos recebem pedidos por formulário e por e-mail. O seu cliente, no Brasil, provavelmente escreve no WhatsApp. Quando o canal principal não entra no sistema, alguém tem de copiar a conversa para dentro do pedido, e a cópia é a primeira coisa a ser esquecida num dia atarefado.

A pergunta certa não é "tem WhatsApp?", mas sim: o WhatsApp entra numa caixa partilhada, com histórico, ou é só um botão que abre a aplicação de uma pessoa? E ainda: é possível atender no mesmo sítio o e-mail e a mensagem do mesmo cliente? Há mais sobre isto em como organizar o suporte no WhatsApp sem virar confusão.

3. Relatório: dá para ver a fila, mas não dá para decidir

Contar pedidos abertos é fácil. Responder às perguntas que importam é mais difícil:

• Que assunto se repete mais e deveria passar a ser uma correção definitiva?
• Que atendente cumpre o prazo e qual está sobrecarregado?
• O tempo de primeira resposta piorou depois de o volume duplicar?
• Os clientes ficaram satisfeitos?

Os relatórios por período, por atendente, por canal e por motivo costumam ficar nos planos pagos. Sem eles, a reunião de segunda-feira passa a ser feita de impressões, não de dados.

4. O pedido que passa a ser trabalho da equipa

Este é o limite que mais pesa e o menos percebido na hora da escolha. Boa parte dos pedidos não termina no suporte. "O relatório está a somar mal" é uma correção no produto. "Preciso de um ecrã novo" é um pedido de projeto. "O cliente quer integrar com o sistema dele" é trabalho de várias semanas.

Num help desk isolado, o suporte copia o problema para a ferramenta de quem executa, depois pergunta no grupo "então, já saiu?" e, quando a correção entra no ar, o cliente descobre sozinho. São dois sistemas, duas filas e uma pessoa no meio a fazer a ponte à mão.

Etapa	Pedido numa ferramenta separada	Pedido e trabalho no mesmo sistema
O problema precisa de correção	Copiar o texto para a ferramenta da equipa	Transformar o pedido em tarefa, com o histórico junto
Acompanhar o andamento	Perguntar no grupo ou no corredor	Ver o estado e o prazo da tarefa no próprio pedido
Avisar o cliente	Alguém lembra-se de voltar ao pedido	O responsável pelo atendimento vê quando a tarefa fecha
Medir o que custa	Dois conjuntos de números que não se cruzam	Pedidos e tarefas no mesmo relatório

Como decidir: cinco perguntas

Em vez de comparar listas de funcionalidades, responda a estas perguntas sobre a sua operação. Cada "sim" é mais um motivo para sair do gratuito.

1. Promete prazos a algum cliente? Contrato, proposta ou acordo verbal. Se sim, precisa de SLA medido, não de boa vontade.
2. Há mais de um canal a trazer pedidos? E-mail e WhatsApp, por exemplo, e hoje alguém junta tudo à mão.
3. Há mais de uma pessoa a atender? A partir de duas, surgem as dúvidas sobre quem pegou em quê e sobre como transferir sem perder o contexto.
4. Mais de um terço dos pedidos depende de outra equipa? Se o suporte vive a pedir coisas ao desenvolvimento, à contabilidade ou à operação, o estrangulamento está no reencaminhamento.
5. Alguém pergunta "quantos pedidos tivemos no mês e de quê?" e ninguém sabe? Sem relatório, as decisões de contratação e de produto são tomadas ao acaso.

Zero ou um "sim": fique no gratuito e reveja daqui a seis meses. Dois ou três: já vale a pena testar uma alternativa, sem pressa de migrar. Quatro ou cinco: o gratuito está a custar mais caro do que parece, em retrabalho e em clientes irritados.

O custo escondido de ficar

"Grátis" mede o que paga à ferramenta, não o que ela lhe custa. Uma pessoa que gasta uma hora por dia a copiar informação entre sistemas custa, por mês, mais do que muitas mensalidades. Some a isso o cliente que deixa de renovar porque esperou por uma resposta, e o gratuito sai caro.

O inverso também é verdade. Pagar por um sistema completo antes de ter volume é desperdício. A conta honesta olha para o ponto em que está, não para o ponto onde pretende chegar.

O que testar antes de migrar

Se a resposta às cinco perguntas apontou para a mudança, não migre tudo de uma vez. Faça um teste curto com pedidos reais.

• Escolha um canal e uma equipa, e funcione em paralelo durante duas semanas.
• Registe o prazo de primeira resposta e veja se o ecrã de quem atende mostra o tempo restante sem abrir o relatório.
• Pegue num pedido que depende de outra área e acompanhe o caminho dele até à entrega. Conte quantas vezes alguém teve de copiar texto de um sítio para outro.
• Extraia um relatório do mês e confira se responde às perguntas da secção sobre relatórios.
• Use o Atendimento se o WhatsApp é o canal principal: junta WhatsApp, e-mail e formulários numa caixa partilhada, e tem teste de 14 dias em qualquer plano.

Se o teste não mostrar diferença no seu dia a dia, acabou de poupar uma migração. Se mostrar, terá um argumento concreto, com números do seu próprio atendimento, para defender a mudança perante quem paga a conta.

Resumo prático

Um sistema de pedidos gratuito vale a pena enquanto o seu problema for "ninguém sabe o que está aberto". Deixa de valer quando o problema passa a ser prazo, canal, medição ou reencaminhamento para a equipa. Nesse ponto, a pergunta deixa de ser "quanto custa a ferramenta?" e passa a ser "quanto custa o trabalho manual que a ferramenta não faz?".