O cliente manda uma mensagem para saber se o pedido foi recebido. Depois liga para perguntar se ele já entrou em produção. Quando a equipe procura a resposta, o status está em uma planilha, o prazo está com um fornecedor e a última atualização ficou na conversa de outra pessoa.

Para reduzir essas ligações, não comece por um portal. Primeiro descubra qual informação está faltando e se o status interno é confiável. Depois escolha o menor caminho que fecha a lacuna: confirmação, atualização proativa, página de status, portal do cliente ou atendimento humano. Se a operação precisa de responsabilidade contínua pelo software da operação, essa pessoa deve cuidar do fluxo e da informação, além da tela que o cliente vê.

Diagrama mostra confirmação, atualização, status e atendimento humano em um fluxo de pedido.

Resposta curta

  • Descubra se o cliente não sabe se o pedido existe, em que etapa está ou quando algo mudou.
  • Defina uma fonte de status, os eventos que atualizam o pedido e quem responde quando o prazo muda.
  • Use mensagens para uma dúvida pontual, uma página ou portal para consultas recorrentes e uma pessoa para exceções.
  • Meça contatos sobre status, repetições e escaladas antes e depois da mudança. Não transforme um silêncio em prova de satisfação.

Por que os clientes ligam para perguntar pelo pedido?

O contato costuma ser uma reação à falta de informação, não uma preferência automática por falar ao telefone. O cliente pode não ter recebido confirmação, estar diante de um prazo que venceu ou não saber se "em andamento" significa aguardando material, em produção ou pronto para envio.

Em 2025, o guia da Shopify, "WISMO Ecommerce: Meaning + 5 Strategies", recomenda combinar expectativa clara de entrega, canais de comunicação, acompanhamento do pedido, automação e um processo de atendimento que consiga consultar o status. A lista não transforma cada negócio em uma loja virtual. Ela ajuda a separar duas perguntas: o cliente precisa de um aviso ou precisa investigar o próprio pedido?

Siga cinco contatos recentes do início ao fim e anote o que a pessoa queria descobrir. Classifique cada contato em uma destas situações:

  1. Confirmação: o cliente não sabe se o pedido foi registrado.
  2. Andamento: o cliente sabe que o pedido existe, mas não sabe a etapa atual.
  3. Prazo: a data prometida está distante, mudou ou não tem explicação.
  4. Ação: o cliente quer aprovar, corrigir, enviar um documento ou alterar algo.
  5. Exceção: houve atraso, falta de material, endereço errado ou outro problema que exige julgamento.

Essa classificação evita a compra de uma solução para o problema errado. Um portal não corrige uma confirmação que nunca é enviada. Uma mensagem automática também não resolve um prazo que a equipe não consegue calcular.

Qual é o menor caminho para cada tipo de contato?

Escolha a intervenção pela pergunta que se repete e pela mudança que o negócio consegue sustentar. A tabela é um ponto de partida, não uma promessa de que uma ferramenta reduzirá contatos sozinha.

Problema percebido pelo cliente Primeiro caminho Quando procurar outra solução
"Vocês receberam meu pedido?" Envie uma confirmação com identificador, próximos passos e canal de ajuda. O pedido entra por canais diferentes e a equipe precisa redigitar os dados.
"Em que etapa está?" Defina poucos status compreensíveis e avise quando a etapa mudar. O status nasce em sistemas diferentes ou fica desatualizado.
"O prazo mudou?" Mostre a data prometida e avise quando ela deixar de ser válida. Ninguém tem autoridade para confirmar a nova data.
"Posso aprovar ou alterar?" Ofereça uma ação clara com prazo e registro da resposta. A aprovação depende de documentos, regras ou sistemas que não estão conectados.
"Deu algum problema?" Encaminhe a exceção para uma pessoa que possa decidir e explique o próximo passo. A equipe só consegue responder depois de perguntar a várias áreas.

O erro comum é pular para a última linha e tentar esconder toda pergunta em um autoatendimento. O cliente ainda precisa encontrar uma resposta verdadeira. Se o negócio não sabe qual é o status, a interface apenas torna a dúvida mais bonita.

O status do pedido é confiável o bastante?

Antes de publicar qualquer atualização, escolha o lugar onde o status nasce e defina o que cada etapa significa. A equipe pode consultar vários sistemas, mas o cliente não deveria receber versões concorrentes do mesmo pedido.

Para cada status, registre:

  • qual evento inicia a etapa;
  • quem pode mudar o status;
  • qual informação o cliente pode ver;
  • qual prazo ou próximo passo acompanha a etapa;
  • o que acontece quando a etapa fica atrasada;
  • quando uma pessoa precisa assumir a conversa.

Em 2022, a pesquisa da APQC "Optimizing Customer Service", com 289 respondentes, registrou que 65% das organizações disseram que o tempo gasto respondendo a pedidos de status havia aumentado nos dois anos anteriores. O dado descreve aquela amostra e aquele período. Não é uma medida atual de toda empresa, mas mostra por que o status repetitivo merece ser tratado como fluxo operacional, em vez de ficar restrito ao trabalho de atendimento.

A mesma pesquisa encontrou um detalhe importante para a decisão: apenas 17% dos respondentes antecipavam que clientes usariam um portal web de self-service para atualizações. O resultado é de 2022 e não prova que portais sejam pouco úteis hoje. Ele apenas alerta contra a ideia de que todo cliente quer abrir uma página para procurar uma resposta. Em muitos casos, uma confirmação ou um aviso enviado no momento certo é o caminho mais simples.

Se vendas, operação e financeiro mantêm versões diferentes, leia o diagnóstico sobre sistemas da empresa que não conversam. O problema de status é, nesse caso, uma consequência de dados e responsabilidades que já se desencontram.

Quando uma mensagem basta?

Mensagens são adequadas quando a dúvida tem poucos eventos previsíveis. O cliente não precisa fazer login para saber que o pedido foi recebido, que a produção começou ou que o envio foi despachado. A mensagem deve conter a informação que permite a próxima decisão, e não só dizer "seu pedido foi atualizado".

Antes de automatizar, confira:

  1. O evento realmente aconteceu ou alguém apenas alterou um campo para encerrar uma fila?
  2. A mensagem informa prazo, próxima etapa e canal para uma exceção?
  3. O cliente consegue responder sem abrir uma nova conversa em outro lugar?
  4. A equipe consegue corrigir uma mensagem enviada com status errado?

Inclua o pedido e o prazo que a equipe consegue sustentar. Evite prometer "tempo real" quando o dado é conferido uma vez por dia. Uma mensagem atrasada ou falsa pode gerar mais contatos do que o silêncio, porque o cliente passa a questionar a atualização e o pedido ao mesmo tempo.

Também não trate mensagens como substitutas do trabalho de entrega. A Shopify aponta que confirmação, rastreamento e comunicação em mais de um canal ajudam a responder perguntas de status, mas a operação ainda precisa resolver atrasos e falhas de atendimento. O aviso fecha a lacuna de informação. Não fecha a lacuna de execução.

Quando vale uma página de status ou um portal?

Uma página de status vale quando o cliente precisa consultar o mesmo pedido mais de uma vez e a informação muda em etapas que podem ser explicadas. Um portal passa a fazer sentido quando, além de consultar o andamento, o cliente precisa ver documentos, aprovar algo, acompanhar vários pedidos ou responder a uma solicitação dentro de um espaço próprio.

Faça esta distinção:

  • Mensagem: o negócio sabe quando algo mudou e quer avisar.
  • Página de status: o cliente precisa consultar um andamento simples.
  • Portal: o cliente precisa consultar, agir e encontrar histórico ou documentos.
  • Atendimento humano: o caso envolve exceção, negociação ou informação que ainda não pode ser confirmada.

Comece verificando se o software que a empresa já paga possui uma função de portal, notificações ou acompanhamento que está desligada. Se a necessidade é comum e a ferramenta respeita o fluxo atual, configurar costuma ser menos arriscado do que criar outra solução. Se o portal precisa juntar dados de vendas, produção, estoque, financeiro e logística que não têm uma fonte compartilhada, o problema é maior do que uma tela de consulta.

O diagnóstico de quando a empresa deve comprar outro sistema ajuda a fazer essa conta sem começar pelo catálogo. Primeiro descreva o fluxo, as cópias e o responsável. Depois escolha a ferramenta.

Como proteger o cliente e a empresa?

Um portal expõe dados para a pessoa certa. Isso exige mais do que uma URL bonita e um campo para digitar um número de pedido. Liste quais dados podem aparecer, qual identidade confirma o acesso, quais ações são permitidas e como revogar o acesso quando a relação termina.

A orientação da Federal Trade Commission sobre segurança para pequenas empresas recomenda inventariar software, dados e serviços usados pela empresa, limitar acesso ao necessário, exigir autenticação multifator quando apropriado, proteger dados em trânsito e em repouso e definir expectativas de segurança nos contratos com fornecedores. Para uma página de status, isso se traduz em perguntas concretas:

  • O cliente vê apenas seus próprios pedidos?
  • O link ou acesso pode ser revogado?
  • A empresa sabe onde os dados são armazenados?
  • Existe uma conta da empresa, ou só o fornecedor controla a entrada?
  • O que acontece com os dados quando o contrato termina?
  • Quem investiga um status errado ou um acesso indevido?

Não transforme esse checklist em um motivo para paralisar uma confirmação simples. Ele serve para aumentar o cuidado conforme a solução passa de uma mensagem sem dados sensíveis para um portal com documentos, valores, endereços ou ações de aprovação.

Como saber se as ligações diminuíram de verdade?

Registre o problema antes de mudar o processo. Durante um período que a equipe consiga comparar depois, conte os contatos cujo motivo principal foi confirmação, andamento, prazo, alteração ou exceção. Separe chamadas, mensagens e e-mails. Anote também quando a resposta estava disponível e quando alguém precisou reconstruir o pedido.

Depois da mudança, compare a mesma janela de operação. Observe:

  • contatos de status por pedido;
  • pedidos sem confirmação;
  • repetições do mesmo cliente sobre o mesmo evento;
  • tempo até a primeira resposta;
  • exceções encaminhadas para uma pessoa;
  • correções de status enviadas depois de um erro.

Uma queda nas ligações pode significar que os clientes desistiram, mudaram de canal ou passaram a esperar mais. Por isso, a medida precisa andar junto com reclamações, cancelamentos, respostas às mensagens e pedidos entregues dentro do prazo que foi comunicado. Sem esses dados, registre a mudança como hipótese, não como resultado comprovado.

Quem fica responsável quando o status muda?

O sistema não deve ser o dono do processo. Defina uma pessoa ou função que saiba quem atualiza o status, quem corrige uma data, quem responde por uma exceção e quem aprova mudanças na comunicação. Essa responsabilidade pode ficar dentro da empresa ou com um parceiro, desde que não dependa da memória de uma única pessoa.

O guia sobre quem cuida do software depois do lançamento detalha contas, dados, manutenção e transição. Para o fluxo de pedidos, o responsável também deve receber o histórico de decisões, os critérios de status, as mensagens enviadas e o caminho para desligar ou trocar a solução.

Se a empresa precisa de alguém para corrigir o fluxo inteiro, não peça apenas "um portal". Descreva o que o cliente pergunta, onde a resposta nasce, quais ações são permitidas e quem assume os casos que não cabem na regra. Assim a decisão de comprar, configurar ou construir começa pelo trabalho real.

Perguntas frequentes

Um portal do cliente elimina as ligações sobre pedidos?

Não. O portal ajuda quando o cliente precisa consultar ou agir sobre informações que mudam, mas não corrige um status ausente, atrasado ou errado. Comece definindo a fonte dos dados e os eventos. Mantenha uma pessoa para atrasos, negociações, correções e situações que a regra não consegue explicar.

É melhor enviar mensagens ou criar uma página de status?

Depende da pergunta. Envie mensagens quando eventos previsíveis exigirem um aviso. Use uma página quando o cliente consultar o mesmo pedido várias vezes. Se ele também precisa aprovar, alterar, baixar documentos ou ver histórico, avalie um portal. Em todos os casos, a informação precisa ser verdadeira e ter um responsável.

Quando vale criar um portal sob medida?

Considere uma solução sob medida quando o cliente precisa ver ou executar um fluxo específico que depende de vários sistemas e nenhuma ferramenta existente consegue representar a operação com segurança. Antes disso, procure funções de portal e notificações no que a empresa já usa. O custo de manter a solução também faz parte da decisão.

Como reduzir contatos sem afastar clientes que preferem falar com uma pessoa?

Não esconda o telefone nem force o cliente a procurar uma resposta quando existe uma exceção. Publique a informação simples no canal certo e deixe claro como pedir ajuda. A automação deve retirar consultas repetitivas da fila, não impedir que uma pessoa veja atraso, erro, alteração ou necessidade de negociação.

Conclusão

Clientes ligam pelo status do pedido quando a informação está ausente, atrasada, espalhada ou difícil de interpretar. A correção começa pelo fluxo, não pelo portal. Defina a fonte do status, os eventos que mudam a etapa, a data que pode ser prometida e a pessoa que assume uma exceção.

Depois escolha o menor caminho: confirmação, atualização proativa, página de status, portal ou atendimento humano. Meça contatos e consequências junto com a mudança. Uma operação pode continuar usando telefone, planilha ou vários sistemas por algum tempo. O que não pode continuar é obrigar o cliente e a equipe a reconstruir a mesma resposta em cada contato.

Nota de produção

Samuel Fajreldines é o responsável editorial por este texto. A pesquisa usou a documentação pública da Shopify, APQC e Federal Trade Commission, além de discussões públicas de operadores. A assistência de IA ajudou na descoberta, comparação de fontes, primeira redação, tradução, imagem e revisão de consistência. Não houve teste em uma empresa cliente, benchmark próprio ou estudo de caso inventado.

Fontes consultadas