Módulo determinístico
Order Management System (OMS, também Seller Center)
A venda foi fechada, e é aí que começa o trabalho que ninguém mostra em demonstração. O pedido aparece como "em separação" para o comprador, como "faturado" no ERP e como uma dúvida no grupo do WhatsApp do vendedor. Alguém marcou enviado antes de despachar, o cliente liga para o vendedor, o vendedor liga para a expedição, e o custo dessa reconciliação não entra em nenhuma planilha.
O pedido continua sob gestão
Painel do Vendedor da loja de demonstração, com chips de status e contagens, incluindo Em andamento 4, Pré-encomenda 5 e Em Aprovação Comercial 3.
- Ciclo de vida visívelos chips organizam os pedidos pelos diferentes estados da operação.
- Aprovação comerciala negociação mantém um ponto explícito de decisão humana.
- Filtros operacionaisstatus, data, cliente e outros campos ajudam a localizar pedidos na tabela.
Abaixo, filtros por coluna e uma tabela de pedidos.
O OMS entra neste ponto para provar que a jornada não termina na criação do pedido. Cada negociação segue por estados operacionais visíveis, inclusive pela aprovação comercial, onde o vendedor atua como decisão humana dentro de um fluxo digital mensurável.
O que é
O módulo que orquestra o ciclo do pedido depois que ele existe. São dez estados orientados a evento, do pré-pedido ao entregue e concluído, mais os desfechos de cancelado, extraviado e devolvido, e o pedido só muda de estado quando o evento correspondente acontece de verdade. Ele é a mesma máquina vista de dois lados: o lojista a chama de Canal da Loja, a operação e o ERP a chamam de Order Management System. Quem pode vender, como as ofertas concorrem e como o valor se divide são perguntas do Marketplace Center; aqui a pergunta é onde está este pedido e o que já aconteceu com ele.
A capacidade que ninguém replica
O estado não avança porque alguém clicou, avança porque a condição foi satisfeita
Na maioria dos sistemas o status é um rótulo que alguém troca, e por isso ele mente. Aqui cada estágio tem uma condição de entrada: READY exige a Nota Fiscal, SHIPPED exige o código de rastreio, e a modalidade de frete que precisa das dimensões da embalagem não deixa o pedido sair sem elas. O status deixa de ser o que a operação diz que fez e passa a ser o que ela comprovou, e é essa diferença que torna o dado confiável o bastante para o financeiro e para o cliente dependerem dele.
O mesmo pedido, três leituras que não podem divergir
O comprador acompanha pelo portal, o lojista opera no Canal da Loja e o ERP consulta e atualiza por API. Não são três cópias sincronizadas de tempos em tempos, é o mesmo registro lido de três lugares, e cada pedido carrega de onde a venda partiu e quem é responsável por entregá-la. Num pedido com vários sellers isso deixa de ser detalhe: sem essa marcação, ninguém sabe de quem cobrar qual parte.
Cancelar um pedido é uma permissão, não um botão
Deixar o seller cancelar sozinho parece uma gentileza operacional, e é a porta de entrada dos piores comportamentos de um marketplace. A plataforma trata isso como decisão de governança e a mantém fechada por padrão, porque conhece o que acontece quando ela é aberta sem critério:
- Estoque que não existe. O item aparece disponível, o pedido entra, e o cancelamento vira o conserto de um anúncio que nunca foi verdadeiro.
- Renegociação depois da venda. O preço combinado no portal vira ponto de partida, e a falta de estoque vira argumento para pedir mais.
- Disputa de pedido. Sellers escolhem os pedidos bons e devolvem os ruins, e o comprador paga a conta em prazo.
- Venda por fora. O pedido é cancelado na plataforma e refeito no particular, com o dado do comprador que a plataforma entregou.
Por isso a permissão é liberada loja a loja, no painel administrativo da CWS Platform, e não fica na mão do operador do marketplace; o cancelamento exige motivo registrado; e pedido já aprovado no meio de pagamento fica travado mesmo com a permissão ativa. Faz sentido abrir quando não há disputa, como na operação em que cada seller responde por uma área própria. O ponto não é o botão, é quem responde pela consequência dele.
Em operação
Imdepa · distribuição de autopeças
cerca de 60 mil pedidos
processados em 3 anos de portal B2B, com 153 clientes ativados e cerca de 25 mil sessões por mês.
Volume dessa ordem não se sustenta com status conferido na mão. O ciclo do pedido roda sozinho porque cada avanço tem uma condição objetiva, e o vendedor que antes gastava a maior parte do tempo processando pedido passou a acompanhar exceção, que é o único lugar onde ele é insubstituível.
Ler o caso Imdepa →Perguntas frequentes
O meu cliente consegue saber onde o pedido está sem ligar para alguém?
Sim, e sem depender de alguém lembrar de avisar. O comprador acompanha o pedido pelo próprio portal, com a etapa atual e o código de rastreio quando a modalidade de frete tem rastreio, e recebe mensagem automática nas viradas que importam: pedido concluído, pagamento confirmado e despacho. Num pedido com itens de sellers diferentes, cada lojista comunica a evolução da parte que é dele, porque cada parte tem prazo e transportadora próprios.
Quem emite a nota fiscal, a plataforma ou o meu sistema?
O seu. A emissão é procedimento fiscal da empresa e continua no sistema que já a emite hoje; a plataforma recebe os dados da nota e os usa como condição de avanço do pedido. Essa fronteira é deliberada, e é o que evita duas verdades fiscais: o Order Management System não disputa a emissão com o seu ERP, ele exige a prova de que ela aconteceu antes de deixar o pedido seguir.
O seller pode cancelar um pedido meu por conta própria?
Por padrão não, e essa é uma posição da plataforma, não uma limitação. Quando a permissão existe, ela é liberada loja a loja e no painel administrativo da CWS Platform, não pelo próprio operador do marketplace, e o cancelamento exige motivo registrado. Além disso, pedido já aprovado no meio de pagamento não é cancelável pelo seller de forma alguma: ali só existe o fluxo formal de solicitação, com rastro.