Saltar para o conteúdo
← Ideias

Pedidos com entregas parciais: como dividir envios sem perder o controlo

Saiba quando dividir um pedido, como relacionar os envios e comunicar cada atualização sem confundir o inventário, as operações ou o cliente.

Vista de um pedido de comércio eletrónico dividido em vários envios, com produtos, estados e datas de entrega distintos.

Um pedido pode incluir produtos expedidos de armazéns diferentes, artigos disponíveis em datas distintas ou unidades que exigem processos de preparação separados. Nestes casos, enviar tudo em conjunto pode atrasar os produtos já prontos; enviar em partes, por outro lado, exige mais coordenação e pode gerar dúvidas sobre o estado real da compra.

A solução não consiste apenas em criar várias etiquetas de envio. É necessário manter uma relação clara entre o pedido original, as respetivas linhas e cada envio, além de definir que estados são apresentados a cada equipa e que informações são comunicadas ao cliente. Este guia apresenta critérios práticos para conceber esse processo.

O que é uma entrega parcial e porque acontece

O que é uma entrega parcial e porque acontece

Há uma entrega parcial quando o cliente recebe apenas parte dos artigos ou das unidades incluídos num pedido, e o restante chega noutro envio ou numa data posterior. Um pedido pode ter vários envios e, ainda assim, corresponder a uma única compra do ponto de vista comercial.

As causas habituais incluem a distribuição do inventário por várias localizações, a disponibilidade faseada, a preparação por diferentes fornecedores ou uma ocorrência que afeta apenas algumas linhas. Convém distinguir essas causas: uma divisão planeada não exige a mesma resposta que um envio separado devido a uma falta inesperada de stock.

O desenho do processo deve partir de uma regra simples: o pedido representa o compromisso comercial; os envios representam a forma como esse compromisso é cumprido, total ou parcialmente. Se os dois conceitos forem confundidos, um envio já entregue pode marcar erradamente como concluído um pedido que ainda tem artigos por entregar.

Quando dividir o pedido e quando esperar

Dividir pode ser conveniente se os produtos disponíveis no momento tiverem utilidade por si só, se esperar mais tempo prejudicar o cliente ou se houver uma data de entrega comunicada para cada parte. Também pode ser necessário quando cada armazém ou fornecedor prepara as respetivas unidades de forma independente.

Esperar até o pedido estar completo pode ser preferível quando os artigos são utilizados em conjunto, o cliente espera receber tudo de uma só vez ou os envios adicionais implicam custos e trabalho sem valor suficiente. A decisão não deve depender apenas da existência de stock nalgum local: deve ter em conta a promessa de entrega, as preferências do cliente e o custo operacional de dividir o pedido.

Antes de definir a regra, as equipas de produto e operações devem responder a perguntas concretas:

  • O cliente pode receber os artigos separadamente sem perder valor de utilização?
  • Que atraso é evitado com o primeiro envio e que custo adicional implica a divisão?
  • Existe um prazo ou uma preferência de entrega registada para o pedido?
  • A equipa consegue responder a questões sobre vários pacotes e datas?

Se a resposta depender do tipo de produto, do canal ou da promessa comercial, convém estabelecer regras explícitas para cada situação. Evite deixar a decisão ao critério de cada pessoa no armazém ou no apoio ao cliente.

Relacionar o pedido, as linhas e os envios

O modelo operacional deve permitir saber que unidades de cada linha estão atribuídas a cada envio. Não basta guardar uma lista de pacotes associada ao pedido: se uma linha incluir várias unidades, algumas podem ser expedidas hoje e outras mais tarde.

No mínimo, cada envio deve ter uma identificação e estar relacionado com o pedido original e com as quantidades específicas que inclui. Também deve ser possível consultar a sua origem operacional, a data estimada, quando conhecida, e o identificador de seguimento, quando existir. Assim, um agente pode responder que parte foi expedida, qual continua pendente e porquê.

Por exemplo, se um pedido incluir três unidades de uma referência e apenas duas estiverem preparadas, essa diferença deve permanecer visível. O envio não deve indicar que a linha inteira foi expedida. A unidade pendente continua associada ao pedido, mas não ao pacote que já saiu.

A quantidade atribuída aos envios não pode exceder a quantidade pedida. Além disso, as unidades canceladas ou não fornecidas devem distinguir-se das que continuam pendentes. Esta distinção evita que o sistema trate uma falta definitiva como um atraso temporário ou prepare duas vezes unidades já atribuídas.

Estados separados para o pedido, a preparação e a entrega

Um único estado global costuma ser demasiado limitado. É mais claro manter estados separados para o pedido, para a preparação de cada parte e para o transporte de cada envio. Por exemplo, o pedido pode estar parcialmente expedido, enquanto um pacote está em trânsito e outro ainda aguarda preparação.

Os nomes concretos dependem da operação, mas cada estado deve ter uma definição e uma transição autorizada. “Pendente” não deve significar indistintamente falta de stock, espera de preparação ou ausência de dados de seguimento. Quando esses motivos são misturados, torna-se difícil definir prioridades para as ocorrências.

  • Pedido: resume o cumprimento do compromisso comercial, por exemplo, confirmado, parcialmente satisfeito ou concluído.
  • Preparação: descreve o trabalho relativo a cada parte, desde a atribuição das unidades até à expedição.
  • Envio: indica o progresso logístico de um pacote e a respetiva entrega, de acordo com as informações disponíveis.

Para as operações, apresente as quantidades e os motivos pendentes. Para o apoio ao cliente, mostre uma vista clara por produto, pacote e data estimada, sem exigir que a equipa interprete estados internos. Evite apresentar o pedido como “entregue” se ainda houver unidades comprometidas por resolver.

Atribuir stock, custos e seguimento a cada envio

A reserva de inventário deve estar associada a quantidades identificáveis. Quando uma unidade é atribuída a um envio, o processo deve impedir que essa mesma unidade seja reservada para outro pedido ou pacote. Se uma atribuição for alterada, é necessário libertar ou reatribuir o stock de forma controlada e deixar o resultado visível.

Os custos exigem uma regra própria. Defina como são registadas as despesas de preparação e transporte quando existem vários envios, e quem decide se são cobradas ao cliente, suportadas pela empresa ou sujeitas a aprovação. Não pressuponha que cada pacote corresponde a uma cobrança adicional: a resposta depende das condições comerciais aplicáveis e do que foi comunicado ao cliente.

O seguimento também deve estar associado a cada envio, e não apenas ao pedido. Guarde o endereço ou identificador correspondente a cada pacote e evite reutilizar um número em vários envios sem confirmar que representa corretamente o respetivo percurso. Se ainda não houver dados de seguimento, indique que estão pendentes; não apresente como confirmado algo que ainda é desconhecido.

Comunicar cada entrega sem confundir o cliente

A comunicação deve explicar que o pedido será entregue em partes, que artigos estão incluídos em cada envio e o que se sabe sobre as datas. Uma mensagem útil distingue o que está confirmado do que é estimado e facilita o seguimento de cada pacote. Se a data mudar, comunique a alteração relativa à parte afetada e esclareça se a previsão para o restante pedido se mantém.

Na página do pedido, apresente um resumo geral e os detalhes de cada envio. Evite repetir o pedido completo em todos os avisos: isso pode levar o cliente a pensar que receberá cada produto várias vezes. As mensagens devem manter uma referência comum ao pedido e identificar claramente os diferentes pacotes.

Também é importante não prometer uma precisão que a operação não consegue garantir. Se apenas for conhecida uma janela de entrega estimada, apresente-a como estimativa. Se uma parte ainda não tiver data, explique quando serão atualizadas as informações ou que alternativa o cliente pode consultar, de acordo com as políticas em vigor.

Exceções e indicadores para melhorar o processo

Exceções e indicadores para melhorar o processo

A falta de stock, o cancelamento de uma linha e um atraso exigem respostas diferentes. Perante uma discrepância de inventário, bloqueie a atribuição dessa quantidade e verifique que outras linhas podem avançar. Se uma parte for cancelada, atualize as unidades pendentes e comunique o efeito sobre o restante pedido. Em caso de atraso, confirme se existe uma nova previsão fiável antes de alterar a mensagem para o cliente.

Defina em que situações uma ocorrência deve ser encaminhada para intervenção humana: por exemplo, quando não é possível confirmar uma data, quando existe uma diferença entre as unidades reservadas e as preparadas ou quando o envio surge como entregue, mas o cliente informa que não o recebeu. Cada caso deve ter um responsável e um registo da decisão para evitar respostas contraditórias.

Para avaliar o processo, acompanhe indicadores que ajudem a localizar dificuldades, e não apenas o volume de pacotes:

  • Percentagem de pedidos divididos e motivos registados.
  • Tempo entre o primeiro envio e a resolução das unidades restantes.
  • Ocorrências de atribuições duplicadas ou de quantidades pendentes incorretas.
  • Questões e reclamações relacionadas com entregas parciais.
  • Diferenças entre as datas comunicadas e as datas efetivamente observadas.

Antes de lançar o processo, confirme que o pedido mantém uma referência única, que cada envio identifica as respetivas linhas e quantidades, que os estados não se contradizem e que um cancelamento ou uma reatribuição não deixa unidades sem associação. Teste também uma situação normal, uma com stock parcial e outra com atraso. O processo está bem concebido quando qualquer equipa consegue explicar o que foi pedido, o que foi expedido, o que falta e qual é o próximo passo sem ter de reconstruir manualmente o histórico.

Fuentes y referencias

  1. Web standardsW3C
  2. OWASP Cheat Sheet SeriesOWASP Foundation
  3. Web performanceweb.dev