Da reclamação ao estorno em um minuto governado.
O agente de suporte lê o ticket, verifica o pedido no ERP, estorna no trilho original de pagamento, emite a nota de crédito e avisa o cliente, tudo dentro de um limite de gasto por agente. O suporte para de escalar estornos; o financeiro para de descobri-los no fechamento.
Verificado, estornado, selado, dentro da conversa.
O cliente reclama onde já está: no WhatsApp. O agente puxa o pedido #8421 do ERP, confirma o Pix que o liquidou, estorna para a mesma chave e emite a nota de crédito. O limite de gasto é um mandato, não um PDF de política: um estorno acima do teto simplesmente não executa.
- Pedido verificado no ERP antes de qualquer centavo voltar
- Estorno no trilho original: Pix de volta para a chave do pagador
- Nota de crédito emitida no mesmo fluxo, selada ao recibo do estorno
A conversa é a parte fácil.
Estorno é onde o suporte encontra o dinheiro, e os dois times hesitam. O ticket espera alguém com acesso ao banco, a transferência não bate com o pagamento original, a nota de crédito é lembrada uma semana depois, e ninguém sabe dizer quem aprovou o quê. Um problema de um minuto vira uma thread de três dias.
Escalar cada estorno para quem tem o login do banco
O agente estorna dentro de um teto por agente; sem login compartilhado
Estornar por transferência manual, desconectada da cobrança original
O codespar_pay devolve o dinheiro no trilho original, mesma chave Pix
Emitir a nota de crédito depois, se alguém lembrar
O codespar_invoice corta a nota de crédito no mesmo fluxo
Responder o auditor com uma thread do Slack e um print do banco
Verificação, estorno e nota selados em um único recibo
Estorno com limite de gasto, não com login compartilhado.
O codespar_ledger verifica o pedido e o pagamento original antes de qualquer coisa se mover. O codespar_pay executa o estorno no mesmo trilho em que a venda liquidou, limitado pelo mandato de suporte: um teto assinado por agente, revogável a qualquer momento. O codespar_invoice emite a nota de crédito e o codespar_notify fecha o ciclo com o cliente, tudo selado em um registro auditável.
Reclamação · pedido #8421
codespar_ledgerPedido + pagamento original
Omiecodespar_payPix · chave original · teto
Trilho Pixcodespar_invoiceNC emitida + armazenada
Trilho fiscalcodespar_notifyCliente confirmado
Z-APIO ticket entra pelo canal de suporte. O agente resolve o pedido no ERP, confirma a liquidação original e executa o estorno sob o mandato de suporte, um teto por agente que o motor de políticas aplica em tempo de execução. A nota de crédito é emitida contra o estorno, o cliente é avisado, e os quatro passos selam em um recibo.
Algumas linhas. O loop inteiro.
const session = await codespar.sessions.create(); // verify before moving money: order, amount, original rail const order = await session.execute("codespar_ledger", { action: "lookup", orderId: "8421", }); await session.execute("codespar_pay", { rail: "pix", amount: order.total, // R$ 186,00 destination: order.payer.pixKey, // original key, original rail mandate: "cm_support", // per-agent cap · revocable }); await session.execute("codespar_invoice", { kind: "credit_note", orderId: "8421" }); await session.execute("codespar_notify", { to: order.buyer, template: "refund_done" });
codespar_payEstorna no trilho original, limitado pelo mandato de suporte por agente.
codespar_ledgerVerifica o pedido e a liquidação original antes de o estorno rodar.
codespar_invoiceEmite a nota de crédito no mesmo fluxo e a sela ao estorno.
Coloque no ar ainda hoje.
Abra o sandbox, aponte uma sessão para os seus provedores e rode o loop inteiro contra rails reais em minutos — não no trimestre que levaria para construir tudo na mão.