A conciliação de pedidos de ecommerce permite reconstruir a situação real de uma compra quando a informação está distribuída entre a loja, a plataforma de pagamento, o sistema de gestão de pedidos, o operador logístico, o CRM e os canais de atendimento. Não consiste simplesmente em comparar duas listas: é um processo para confrontar factos, identificar contradições, atribuir uma decisão e conservar as evidências que a justificam.
Um pedido pode constar como pago na plataforma de venda, recusado na plataforma de pagamento, entregue pela transportadora e aberto no atendimento ao cliente devido a uma reclamação. Se cada equipa consultar uma fonte diferente sem regras partilhadas, o resultado habitual é uma resposta inconsistente, reembolsos indevidos, expedições duplicadas ou pedidos bloqueados sem motivo.
O pedido é uma sequência de factos distribuídos
Convém tratar um pedido como uma entidade composta por eventos, e não como um único registo com um estado definitivo. Cada sistema observa uma parte do ciclo e regista-a com a sua própria semântica, tempos e possíveis erros.
- A loja regista a criação do carrinho, a confirmação da compra e, por vezes, a autorização do pagamento.
- A plataforma de pagamento regista autorizações, capturas, recusas, anulações, reembolsos e estornos.
- O sistema de gestão de pedidos regista preparação, reservas de stock, cancelamentos e expedições.
- O operador logístico regista aceitação, trânsito, tentativa de entrega, entrega, perda ou devolução.
- O atendimento ao cliente regista contactos, compromissos, alterações manuais e documentação fornecida.
Estes factos não chegam necessariamente por ordem. Um webhook pode ser objeto de novas tentativas, um ficheiro de liquidação pode ser recebido no dia seguinte e uma entrega pode ser confirmada horas depois de ter ocorrido. A conceção deve admitir que uma ausência temporária de informação não equivale automaticamente a uma falha.
Definir um ciclo de vida canónico e as suas evidências
O primeiro passo é definir um modelo canónico, independente das etiquetas específicas de cada fornecedor. Deve ser suficientemente detalhado para operar, mas não tão complexo que obrigue a criar equivalências ambíguas. Uma opção prática é separar a situação comercial, financeira e logística, em vez de tentar condensá-las num único estado.
- Comercial: criado, confirmado, cancelado ou encerrado.
- Financeiro: pendente, autorizado, cobrado, falhado, reembolsado ou em disputa.
- Logístico: não libertado, preparado, expedido, em trânsito, entregue, com ocorrência ou devolvido.
- Pós-venda: sem caso, consulta aberta, reclamação, devolução solicitada, devolução recebida ou caso resolvido.
Cada estado canónico deve ter uma definição verificável e uma evidência admissível. Por exemplo, cobrado pode exigir um identificador de transação e um evento de captura ou liquidação; entregue pode exigir uma confirmação do operador com data, código de rastreio e, quando aplicável, prova de entrega. Definir evidências evita que uma nota interna ou uma inferência se transforme indevidamente num facto.
Também é necessário documentar transições proibidas ou excecionais. Uma expedição não deve ser libertada se o pagamento tiver falhado, salvo se existir um fluxo explícito de pagamento contra reembolso. Um pedido entregue não deve voltar a em trânsito devido à chegada de um evento antigo; é necessário conservar o histórico e aplicar regras de precedência.
Utilizar identificadores que permitam correlacionar sistemas
A conciliação depende da capacidade de associar registos sem recorrer a correspondências frágeis por nome, montante ou endereço de e-mail. O identificador interno do pedido deve acompanhar, sempre que possível, os metadados do pagamento, a ordem de preparação, a etiqueta de envio e o caso de atendimento.
Nem todos os objetos partilham o mesmo nível de granularidade. Um pedido pode ter várias tentativas de pagamento, envios parciais, várias embalagens, devoluções por linha e mais do que uma conversa. Por isso, o modelo deve distinguir, no mínimo:
- ID do pedido: referência comercial estável e visível para a operação.
- ID de pagamento e tentativa de pagamento: chave do fornecedor e referência interna de cada tentativa.
- ID de envio e embalagem: para suportar entregas parciais ou reexpedições.
- ID de devolução: associado ao pedido e, quando aplicável, às suas linhas.
- ID de caso: referência de atendimento associada ao pedido sem o substituir.
Quando um sistema externo não aceitar a referência interna, mantenha uma tabela de correspondências com origem, destino, data de criação e nível de confiança. Evite utilizar o montante como chave: dois pedidos podem ter o mesmo total, e os descontos, impostos ou reembolsos parciais introduzem diferenças legítimas.
Modelar eventos, tempos e alterações manuais
Guarde os eventos originais juntamente com uma representação normalizada. No mínimo, cada evento deve incluir origem, identificador externo, tipo, instante declarado pela origem, instante de receção, carga ou referência da evidência e um identificador de desduplicação.
É útil diferenciar o momento em que um facto ocorreu do momento em que o sistema tomou conhecimento dele. Um evento recebido hoje com uma data efetiva de ontem pode ser válido; um evento com data futura, uma sequência impossível ou uma referência inexistente requer revisão. Para processar novas tentativas em segurança, as operações devem ser idempotentes: receber duas vezes a mesma confirmação não pode criar duas cobranças, dois envios nem duas ocorrências.
As alterações manuais merecem um tratamento específico. Devem registar quem as realizou, quando, o valor anterior, o novo valor, o motivo e, se existir, a aprovação. Um ajuste manual pode ser necessário para desbloquear uma exceção, mas não deve apagar o evento original nem ocultar que o estado foi corrigido.
Criar regras de comparação e tolerâncias explícitas
As regras de conciliação transformam o modelo em decisões operacionais. Devem expressar uma condição esperada, uma janela temporal, a gravidade do incumprimento e a ação posterior. É preferível começar por poucas regras de elevado impacto e ampliá-las de acordo com os padrões detetados.
- Pedido confirmado sem pagamento autorizado ou cobrado após a janela definida: reter a libertação logística e rever.
- Pagamento cobrado sem pedido correlacionado: investigar a referência, evitar um reembolso automático sem verificar a liquidação e possíveis novas tentativas.
- Envio expedido sem condição financeira válida: bloquear novas ações e escalar para operações e finanças.
- Pedido entregue sem confirmação de expedição: rever a integração logística, a correlação da embalagem e a atualização do pedido.
- Reembolso iniciado sem devolução recebida: verificar se responde a um cancelamento prévio, a uma ocorrência de entrega ou a uma exceção autorizada.
- Dois eventos incompatíveis para o mesmo objeto: conservar ambos, aplicar uma precedência documentada e abrir revisão se não puder ser resolvido.
As tolerâncias devem responder ao comportamento real de cada integração. Por exemplo, a ausência de confirmação logística durante alguns minutos pode ser normal; durante vários dias, não. Não estabeleça janelas universais sem observar horários de corte, lotes noturnos, dias não úteis e acordos com fornecedores.
Separar automatização, revisão e comunicação
Nem toda a divergência deve ser corrigida de forma automática. Classifique as ações por risco e reversibilidade. A automatização é adequada para desduplicar eventos, preencher campos derivados, repetir consultas ou fechar alertas resolvidos por evidência posterior. A revisão operacional é preferível quando existe impacto económico, risco de fraude, entrega física ou contradição entre fontes relevantes.
A comunicação com o cliente deve partir do estado validado, e não de um sinal isolado. Se o pagamento estiver sob revisão, indique que a transação está a ser verificada sem afirmar que o pedido está confirmado. Se existir uma ocorrência de entrega, comunique o passo seguinte, o canal de acompanhamento e o prazo de atualização que a equipa consegue cumprir. Evite que o atendimento ao cliente altere estados críticos como atalho para encerrar conversas.
Conceber uma ficha de ocorrência auditável
Cada exceção que exija intervenção deve gerar uma ficha única, associada ao pedido, que reduza a necessidade de reconstruir o caso a partir de várias ferramentas. Deve incluir a divergência detetada, a sua gravidade, os identificadores relacionados, uma cronologia de eventos, as evidências disponíveis, o responsável atual e a data-alvo de revisão.
A ficha deve terminar com uma decisão estruturada: corrigido automaticamente, validado como exceção, cancelado, reembolsado, reenviado ou escalado. Acrescente o motivo, a pessoa ou função que decidiu e a evidência utilizada. Este registo serve para responder ao cliente, facilitar auditorias internas e descobrir causas repetidas.
Medir a saúde do processo e prevenir novas divergências
Os indicadores devem medir tanto o volume como a qualidade da resolução. Controle a percentagem de pedidos sem correspondência entre sistemas, a antiguidade das ocorrências abertas, o tempo até à resolução, a proporção de ajustes manuais e a reincidência por regra, canal, transportadora ou integração. Segmente por etapa: um problema de correlação de pagamentos exige uma resposta diferente de uma perda de eventos logísticos.
A prevenção começa nas integrações: contratos de dados versionados internamente, validação de campos obrigatórios, monitorização das entregas de eventos, alertas por quedas de volume e testes de cenários como duplicados, reordenação, reembolsos parciais e envios parciais. Nos procedimentos de atendimento, limite permissões, estabeleça motivos normalizados e exija evidências para ações sensíveis.
Um processo maduro não procura que todos os sistemas apresentem exatamente a mesma etiqueta em cada instante. Procura que cada diferença seja explicável, temporalmente delimitada ou gerida através de uma decisão rastreável. Essa é a base para operar pedidos com coerência, mesmo quando venda, pagamento, entrega e atendimento evoluem a ritmos diferentes.