Linha do tempo de status de pedido que explica o que está acontecendo, o que vem a seguir e quando se preocupar, usando um modelo de eventos simples que mantém as atualizações consistentes.
A maioria dos tickets “Cadê meu pedido?” não é realmente sobre envio. É sobre incerteza. Se um cliente não consegue entender o que está acontecendo, ele pede ajuda humana mesmo quando nada está errado.
As mesmas perguntas aparecem repetidas vezes: onde o pedido está agora, se já foi enviado ou ainda está sendo preparado, quando vai chegar (e se essa data mudou), se é possível cancelar ou mudar o endereço, e o que fazer quando o rastreio não avançou.
Quando sua equipe responde isso manualmente, dois problemas aparecem rápido. Primeiro, não escala. Um pequeno pico de pedidos vira uma enxurrada de tickets, e o tempo de resposta piora. Segundo, as respostas divergem. Um agente diz “está em processamento”, outro diz “está sendo embalado”, e o cliente percebe conflito em vez de clareza. Isso leva a follow-ups, criando ainda mais trabalho.
O objetivo é simples: os clientes devem conseguir verificar o status do pedido sozinhos sem adivinhar ou precisar de respostas personalizadas. Uma boa linha do tempo de status faz isso ao transformar atividade interna em uma história clara que o cliente pode acompanhar.
Transparência não significa expor todo detalhe interno. Significa que o cliente possa ver claramente o estado atual em linguagem simples, quando ele mudou (com um carimbo de tempo razoável), o que acontece a seguir (e o que poderia atrasar), e quando vale a pena contatar você.
Quando os clientes conseguem responder “o que está acontecendo e o que devo fazer?” sozinhos, muitos tickets nem chegam a ser criados.
Os clientes não verificam o rastreio por curiosidade. Verificam porque querem respostas rápidas: onde está meu pedido agora, quando algo aconteceu pela última vez, e o que deve acontecer a seguir.
Uma boa UI de rastreamento conta uma história, não só um rótulo. “Enviado” é um rótulo. Uma história é: “Embalado no nosso armazém ontem às 15:12, coletado pelo transportador; próxima atualização deve ser um scan em trânsito.” A história reduz suposições, então as pessoas não recorrem ao suporte.
Três coisas importam mais na linha do tempo do pedido:
A ansiedade aumenta quando o rastreio fica silencioso ou vago. Os maiores gatilhos são longos intervalos sem explicação, texto de status que pode significar qualquer coisa (“Processando”), e janelas de entrega ausentes. Se você não consegue estimar a entrega ainda, diga isso de forma direta e explique o que está aguardando, por exemplo: “Mostraremos um ETA após o transportador escanear o pacote.”
Precisão é mais importante que otimismo. As pessoas perdoam atrasos mais do que perdoam promessas falsas. Se seus dados são parciais, mostre o que você sabe e evite fingir que sabe o resto.
Um exemplo simples: se um pacote fica em “Etiqueta criada” por 36 horas, os clientes presumem que está preso. Uma timeline útil adiciona contexto: “O transportador ainda não escaneou o pacote. Próxima atualização esperada após a coleta. Se não houver scan até amanhã às 17h, investigaremos.” Essa única frase pode evitar uma onda de tickets “Cadê meu pedido?”.
Uma boa linha do tempo de status deve responder três coisas de relance: onde o pedido está agora, o que aconteceu antes, e o que o cliente deve esperar a seguir. Mantenha simples. Se as pessoas precisarem ler um artigo de ajuda para entender a timeline, ela não vai reduzir os tickets.
Comece com um pequeno conjunto de marcos amigáveis ao cliente. A maioria das lojas cobre a maioria das dúvidas com um conjunto estável como: Pedido feito, Pago, Embalado, Enviado, Entregue, além de finais claros como Cancelado e Devolvido.
Para cada passo, adicione uma linha curta de microcopy que explique o que significa e o que acontece a seguir. Por exemplo: “Embalado: seus itens foram preparados no nosso armazém. Próximo: entregue ao transportador.” Isso evita a clássica mensagem “Já foi enviado mesmo?”.
Mostre sempre timestamps e rotule a origem da atualização para que os clientes confiem. “Atualizado às 14:32 pelo Armazém” soa diferente de “Atualizado hoje”. Quando a origem é externa, diga: “Atualizado pelo Transportador.” Se você não sabe a origem, não chute.
Exceções devem ser mais evidentes que o progresso normal. Trate-as como um passo visível próprio, ou um badge claro no passo relevante, com linguagem direta e a próxima ação. Comuns: Atraso, Problema de endereço e Tentativa de entrega falhada.
Um padrão simples e confiável é:
Exemplo: um cliente vê “Enviado (Transportador) 09:10” e depois “Tentativa de entrega falhou 18:40.” Se a UI também mostra “O transportador não conseguiu acessar o prédio. Próxima tentativa: amanhã”, você evita trocas de mensagens.
Seu workflow interno pode ter dezenas de passos: separação, embalagem, agrupamento de etiquetas, entrega ao transportador, tentativas, exceções e mais. Clientes não precisam desse nível de detalhe. Eles querem respostas claras às perguntas simples: “Vocês receberam meu pedido?”, “Já foi enviado?”, “Quando vai chegar?”, e “Há algo de errado?”
Por isso ajuda separar operações internas dos estados visíveis ao cliente. Mantenha seu fluxo interno tão complexo quanto necessário, mas apresente um pequeno e estável conjunto de passos de timeline que façam sentido fora do armazém.
Uma abordagem prática é adicionar uma camada de mapeamento: muitos eventos internos se agregam em poucos estados de timeline. Por exemplo, pagamento autorizado, verificação antifraude aprovada e reserva de estoque podem se agrupar em “Pedido confirmado.” Separação iniciada, embalado e etiqueta criada podem aparecer como “Preparando.” Entrega ao transportador e scans em trânsito viram “Enviado.” Um scan de saída para entrega vira “A caminho”, e um scan de entrega mais confirmação com foto vira “Entregue.”
Essa camada de mapeamento é também sua rede de segurança. Se você mudar o backend depois (novo transportador, novo centro de atendimento, nova lógica de retry), sua linha do tempo não deve pular ou brotar passos novos. Clientes criam confiança quando a timeline permanece consistente de pedido para pedido.
Faça cada estado visível legível e acessível. Use rótulos em texto primeiro, depois ícones e cor. A cor nunca deve ser o único sinal. Um estado atrasado deve dizer “Atrasado” em palavras. Mantenha alto contraste, use um marcador claro de “passo atual” e escreva textos auxiliares curtos como “Estamos preparando seu pedido (geralmente 1–2 dias).” Isso reduz tickets “o que isso significa?” antes mesmo de eles começarem.
Uma boa linha do tempo começa com uma ideia simples: armazene eventos, não apenas o status mais recente. Um evento é um fato que aconteceu em um momento específico, como “etiqueta criada” ou “pacote entregue.” Fatos não mudam depois, então sua timeline permanece consistente.
Se você apenas sobrescrever um campo de status (por exemplo, status = shipped), perde a história. Quando um cliente pergunta “Quando foi enviado?” ou “Por que voltou?”, você não tem uma resposta limpa. Com eventos, você tem um histórico claro e um rastro de auditoria confiável.
Mantenha o registro pequeno e sem frescura. Você sempre pode adicionar mais depois.
order_id: a qual pedido esse evento pertenceevent_type: o que aconteceu (picked_up, out_for_delivery, delivered)happened_at: quando aconteceu (horário da ação no mundo real)actor: quem causou (system, warehouse, carrier, support)details: dados extras pequenos (número de rastreio, localização, nota)Quando sua UI renderiza a timeline, ela ordena eventos por happened_at e os exibe. Se depois você mudar como rotula estados visíveis ao cliente, pode remapear tipos de eventos sem reescrever o histórico.
Sistemas de entrega frequentemente reenviam a mesma atualização. Idempotência significa: se o mesmo evento chegar duas vezes, não deve criar duas entradas na timeline.
A abordagem mais simples é dar a cada evento entrante uma chave única estável (por exemplo, um ID de evento do transportador, ou um hash de order_id + event_type + happened_at + tracking_number) e armazená‑la. Se chegar de novo, ignore.
Uma timeline funciona melhor quando espelha momentos reais que os clientes reconhecem, não suas tarefas internas. Comece listando os pontos onde algo realmente muda para o comprador: dinheiro capturado, existe uma caixa, o transportador a tem, ela chegou.
Um pequeno conjunto geralmente é suficiente para responder a maioria dos “Cadê meu pedido?”:
Mantenha nomes consistentes e específicos. “Embalado” e “Pronto” soam parecidos, mas significam coisas diferentes para clientes. Escolha um significado por evento e não reutilize um rótulo para um momento diferente.
Nem todo evento backend deve aparecer na UI. Alguns são só para sua equipe (revisão antifraude, separação iniciada, validação de endereço). Uma boa regra: se mostrar isso criaria mais perguntas do que respostas, deixe interno.
Mapeie passos internos em menos estados ao cliente. Você pode ter cinco passos de armazém, mas a timeline mostra apenas “Preparando seu pedido” até chegar em “Entregue ao transportador.” Isso mantém a UI calma e previsível.
Tempo importa tanto quanto o rótulo. Armazene dois timestamps quando puder: quando o evento aconteceu e quando você o registrou. Mostre o horário da ocorrência na UI (horário do scan do transportador, horário da confirmação de entrega). Se você mostrar apenas o tempo de processamento, uma importação atrasada pode fazer parecer que o pacote voltou no tempo.
Dados do transportador faltarão às vezes. Planeje isso. Se você nunca receber um scan “Entregue ao transportador”, volte para “Etiqueta criada” com uma mensagem clara como “Aguardando o transportador escanear o pacote.” Evite inventar progresso.
Um exemplo concreto: o armazém imprime uma etiqueta às 10:05, mas o transportador só escaneia às 18:40. Seu modelo de eventos deve guardar ambos eventos, mas sua timeline não deve implicar movimento durante a lacuna. Essa escolha sozinha previne muitos tickets “Diz que foi enviado mas não se moveu”.
Passo 1: escreva a timeline para o cliente primeiro. Liste 5 a 8 passos que um comprador entenda (por exemplo: Pedido feito, Pago, Embalado, Enviado, A caminho para entrega, Entregue). Escreva a frase exata que mostrará para cada passo. Mantenha calma e específica.
Passo 2: defina tipos de evento e um mapeamento. Seus sistemas podem ter dezenas de estados internos, mas os clientes devem ver um conjunto menor. Crie uma tabela simples de mapeamento como warehouse.picked -> Embalado e carrier.in_transit -> Enviado.
Passo 3: armazene eventos, depois calcule a view. Salve cada evento como um registro append-only com order_id, type, occurred_at e data opcional (como código do transportador ou motivo). A UI deve ser gerada a partir de eventos, não de um único campo de status mutável.
Passo 4: retorne uma API pronta para timeline. A resposta deve ser fácil para o frontend: passos (com rótulos), o índice do passo atual, timestamps conhecidos, e uma mensagem curta.
{
"order_id": "123",
"current_step": 3,
"steps": [
{"key":"placed","label":"Order placed","at":"2026-01-09T10:11:00Z"},
{"key":"paid","label":"Payment confirmed","at":"2026-01-09T10:12:00Z"},
{"key":"packed","label":"Packed","at":"2026-01-09T14:40:00Z"},
{"key":"shipped","label":"Shipped","at":null,"message":"Waiting for carrier scan"}
],
"last_update_at": "2026-01-09T14:40:00Z"
}
Passo 5: mantenha a UI atualizada sem ser barulhenta. Para uma timeline, fazer polling a cada 30 a 120 segundos costuma ser suficiente durante o envio ativo, e bem menos quando nada mudou.
Passo 6: adicione fallback para dados atrasados. Se o scan do transportador atrasar, mostre a última atualização conhecida e uma ação clara: “Se não houver atualização até amanhã, contate o suporte com o pedido 123.”
Um exemplo prático: o cliente vê “Embalado” com timestamp, depois “Enviado: Aguardando scan do transportador” até carrier.accepted chegar. Sem respostas personalizadas necessárias, apenas estado honesto.
Um cliente pede um moletom. O pagamento é instantâneo, mas a embalagem leva dois dias úteis. O envio depois sofre um atraso do transportador. O cliente ainda deve se sentir informado sem precisar perguntar ao suporte.
Aqui está a timeline que o cliente vê, dia a dia (mesma UI, apenas novas entradas adicionadas):
| Dia e hora | Status mostrado | Mensagem em linguagem simples |
|---|---|---|
| Seg 09:12 | Pedido feito | “Recebemos seu pedido. Você receberá atualizações conforme ele avançar.” |
| Seg 09:13 | Pagamento confirmado | “Pagamento aprovado. Próximo: vamos preparar sua encomenda.” |
| Ter 16:40 | Preparando seu pedido | “Estamos embalando seus itens. Data de envio prevista: Qua.” |
| Qua 14:05 | Enviado | “Entregue ao transportador. O rastreio será atualizado conforme o transportador fizer scans.” |
| Qui 08:30 | Em trânsito | “A caminho. Estimativa atual: entrega Sex.” |
| Sex 10:10 | Entrega atrasada | “O transportador reportou atraso devido a alto volume. Nova estimativa: Sáb. Nenhuma ação necessária agora.” |
| Sáb 12:22 | A caminho para entrega | “Com o entregador local. Geralmente chega hoje.” |
| Sáb 18:05 | Entregue | “Entregue. Se não encontrar, verifique a entrada e com vizinhos.” |
Note o que mudou na sexta: você não criou um fluxo totalmente novo. Adicionou um evento (shipment_delayed) e o mapeou para uma mensagem clara. Os passos anteriores permanecem, e a UI continua estável.
A opção de contato deve aparecer somente após um limiar claro, para que as pessoas não cliquem só por ansiedade. Uma regra simples funciona bem: mostre “Contatar-nos” se o pedido estiver 24 horas além da última estimativa prometida, ou se o status não mudou por 72 horas enquanto estiver “Em trânsito.” Antes disso, mostre tranquilização e a estimativa atual.
Uma boa timeline reduz mensagens “cadê meu pedido?”. Uma ruim cria novas dúvidas porque a UI e os dados por trás não correspondem ao que as pessoas realmente vivem.
Se expor todo passo interno, clientes se perdem. Quinze micro-status como “separado”, “classificado”, “etiquetado”, “agenciado” e “en fila” parecem ativos, mas não respondem às duas perguntas reais: “Quando vai chegar?” e “Há algo errado?” Mantenha a timeline pública com poucos marcos claros e deixe o resto interno.
Sobrescrever o status atual sem salvar eventos é uma forma rápida de criar contradições. Um cliente vê “Enviado”, atualiza a página e de repente está “Preparando” de novo porque houve um retry ou edição manual. Armazene um histórico com timestamp e construa o estado atual a partir desse histórico.
As armadilhas mais comuns são fáceis de notar:
Aqui está o porquê. Um item é enviado hoje e o segundo está em falta. Se você mostra apenas “Enviado”, o cliente espera tudo. Se você mostra “Enviado parcialmente (1 de 2)” e mantém “Entregue” por pacote, a timeline permanece crível.
Trate rótulos da timeline como texto de produto, não campos de banco de dados. Escreva para humanos, depois mapeie eventos internos para esses poucos passos amigáveis ao cliente.
Antes de liberar sua timeline para todos os clientes, faça um rápido exame do ponto de vista do cliente: “Se eu visse isso às 23h, ainda abriria um ticket?” O objetivo é clareza sem sugerir que algo está errado.
Comece por tempo e expectativa. Todo pedido deve mostrar a hora da última atualização e indicar o que normalmente acontece a seguir. “Última atualização 2 horas atrás” mais “Próximo: coleta pelo transportador” reduz a sensação de estar preso.
Mantenha o checklist pré-lançamento curto:
Depois disso, teste alguns pedidos problemáticos de propósito. Pegue um com remessa dividida, um com transportador que escaneia tarde, e um com tentativa de entrega falhada. Se a timeline parecer um mistério, os clientes vão pedir a ajuda de humanos para interpretá‑la.
Finalmente, confirme que sua equipe de suporte vê a mesma visão que o cliente, incluindo timestamps e mensagens de exceção. Quando ambos leem a mesma história, as respostas ficam mais curtas, e muitos tickets nunca chegam a ser escritos.
Comece pequeno. Uma timeline mínima que responda às principais perguntas (Receberam meu pedido? Quando será enviado? Onde está agora?) é melhor que um rastreador complicado cheio de casos de borda. Lance os estados principais primeiro, e só adicione mais detalhe quando o feedback real dos clientes provar que ajuda.
Planeje um rollout cuidadoso para aprender sem quebrar confiança. Escolha uma pequena fatia de pedidos (por exemplo, um armazém, um método de envio ou um país) e observe o que muda no volume de suporte e no comportamento dos clientes antes de expandir.
Não chute. Instrumente a timeline para ver se ela cumpre seu papel. Compare as perguntas “Cadê meu pedido?” mais comuns antes e depois do lançamento, e acompanhe quais telas de status os clientes visualizam logo antes de contatar o suporte.
Um conjunto simples de métricas iniciais:
A maior parte da carga de suporte vem de exceções: etiqueta criada sem scan, atraso por clima, problema de endereço, remessa dividida. Prepare templates de mensagem para esses casos para que sua equipe dê sempre a mesma resposta. Mantenha‑as curtas, claras e com ação: o que aconteceu, o que você está fazendo, o que o cliente deve esperar a seguir.
Se você está prototipando a UI e a API baseada em eventos, uma plataforma de vibe-coding como Koder.ai pode ser um caminho prático para gerar uma primeira versão a partir de um curto diálogo, e depois refinar a cópia e os mapeamentos conforme aprender com tickets reais.
Aumente a cobertura em etapas. Quando o rollout inicial mostrar menos tickets (e sem nova confusão), expanda para mais tipos de pedido e transportadores. Mantenha uma cadência regular de revisão: a cada poucas semanas, analise novos temas de ticket e decida se a correção é melhor redação, um novo template de exceção, ou um novo evento alimentando a timeline.
Padronize para uma linha do tempo pequena e legível que responda três perguntas: o que está acontecendo agora, quando mudou pela última vez e o que acontece a seguir. A maioria dos tickets vem da incerteza, então a timeline deve reduzir suposições (por exemplo, “Aguardando scan do transportador” em vez de um vago “Processando”).
Use um conjunto estável que a maioria dos compradores entenda:\n\n- Pedido feito\n- Pagamento confirmado\n- Preparando (ou Embalado)\n- Enviado\n- A caminho para entrega\n- Entregue\n\nInclua também finais claros como Cancelado e Devolvido. Mantenha passos internos (separar/embalar/lotear/tentar novamente) fora da visão do cliente.
Mostre o carimbo de data/hora para cada passo e um claro “Última atualização”. Se você vende internacionalmente, inclua o fuso (ou torne sem ambiguidade). Um timestamp transforma “nada está acontecendo” em “isso aconteceu recentemente”, evitando follow-ups.
Trate isso como uma exceção visível, não como progresso normal. Uma boa mensagem padrão é:\n\n- O que você sabe: “O transportador ainda não escaneou a encomenda.”\n- Próximo passo: “A próxima atualização é esperada após a coleta.”\n- Quando escalar: “Se não houver scan até amanhã às 17:00, investigaremos.”\n\nNão sugira movimentação que você não pode provar.
Separe fatos (eventos) do timeline ao cliente (estados). Armazene eventos internos detalhados e, então, mapeie-os em alguns passos compreensíveis pelo cliente. Isso mantém a UI consistente mesmo se o fluxo do armazém mudar.
Armazene eventos como fatos append-only (por exemplo: label_created, picked_up, out_for_delivery, delivered) com:\n\n- \n- \n- \n- (system/warehouse/carrier/support)\n- opcionais\n\nDepois gere a timeline a partir do histórico de eventos ao invés de um único campo de status mutável.
Use idempotência. Dê a cada atualização recebida uma chave única estável (ID do evento do transportador, ou um hash de campos-chave) e ignore duplicatas. Isso evita entradas repetidas como “A caminho para entrega” aparecendo duas vezes quando o transportador reenvia atualizações.
Mostre a melhor estimativa conhecida e seja honesto sobre o que você está aguardando. Se você ainda não tem um ETA, diga isso claramente (por exemplo, “Mostraremos o ETA após o primeiro scan do transportador”). A precisão vence promessas otimistas que quebram confiança.
Deixe as exceções óbvias e orientadas por ação. Comuns:\n\n- Atraso (com nova estimativa, se conhecida)\n- Problema de endereço (com “Confirmar endereço”)\n- Tentativa de entrega falhou (com info da próxima tentativa)\n\nAs exceções devem ter destaque maior que o progresso normal e indicar o que o cliente precisa fazer, se for o caso.
Uma regra prática é mostrar opções de contato apenas após um limiar claro, como:\n\n- 24 horas após a última estimativa prometida de entrega, ou\n- 72 horas sem mudança enquanto estiver “A caminho”\n\nAntes disso, mostre tranquilização, a última atualização e o próximo passo esperado para evitar cliques ansiosos.
order_idevent_typehappened_atactordetails