Playbook operacional: recuperação de pedido abandonado por WhatsApp com IA e CRM

A recuperação pedido abandonado precisa ser precisa: gatilhos com números claros, mensagens prontas e regras de estoque que evitem venda duplicada. Este playbook entrega tudo isso para você implementar hoje.

Recuperação pedido abandonado: gatilhos, thresholds e cenários

Defina eventos claros no seu sistema e ações correspondentes no CRM. Gatilhos primários e ações imediatas recomendadas:

• Abandono de checkout: usuário abriu checkout ou clicou em “Finalizar” → disparo automático 4h após inatividade; ação: enviar 1ª mensagem session e reenvio de link de pagamento.
• Link de pagamento expirado/não pago: 30 minutos após envio sem confirmação → reenvio com nota de validade; se pagamento falhar, disparo imediato com opção de novo link.
• Falha de pagamento (gateway retorna erro): disparo imediato com instrução e novo link.
• Carrinho com itens em estoque crítico (stock <= threshold crítico): disparo em 15 minutos e marcar como alta prioridade.
• Pedido reservado via WhatsApp e sem pagamento: reservar por TTL configurável (varejo 15–60 min; atacado 4–24 h), antes de liberar.

Regras de prioridade e supressão:

• Supressão por user_event: não reenviar HSM se usuário respondeu nas últimas 4h.
• Prioridade de envio: payment_failed > checkout_abandoned > cart_saved > reengajamento (7 dias).
• Thresholds de IA: confidence >= 0.85 para respostas automáticas; score >= 70 → transferir humano; 40–69 → follow-up prioritário; <40 → nurture.

Eventos CRM que disparam fluxos (mínimo): checkout_abandoned, payment_link_sent, payment_failed, reservation_created, reservation_expired, cart_updated. Cada evento deve conter reservation_id e idempotency_key para evitar duplicação.

Sequência de mensagens (HSM + session) por cenário e persona

Cadência padrão recomendada (ajuste por persona):

• Varejo: Follow-up 1 = 4h (session), Follow-up 2 = 24h (HSM), Reengajamento = 7 dias (HSM).
• Atacado: Follow-up 1 = 1h, reserva mais longa (4–24h), abordagem comercial com proposta.

Modelos prontos — Checkout abandonado (varejo):

HSM — título e corpo

HSM título: "Seu pedido está quase pronto" HSM corpo: "Oi {{nome}}, você deixou {{product_name}} no carrinho. Posso reabrir o link de pagamento? Ele fica disponível por {{tempo_reserva}}. [PAGAR_AGORA]"

Session follow-up (4h)

"Vi que não finalizou a compra de {{product_name}}. Quer que eu reserve por {{tempo_reserva}} e reenvie o link?" — incluir quick-replies: [Pagar agora] [Reservar] [Falar com vendedor]

Variação atacado (tom comercial): "Olá {{nome}}, montei uma proposta com condições para o lote {{sku}}. Deseja que eu envie a cotação com prazo e frete?"

Personalização por histórico (regras práticas):

• Insira {{last_order_date}}, {{freq_meses}} e CLTV tier; clientes VIP recebem oferta condicional (ex.: desconto ou prazo melhor).
• Se cliente abriu checkout 2x → ofertar condição (cupom ou frete grátis) no segundo follow-up.
• Se first_time_buyer → inclua prova social e garantia de entrega.

Regra HSM vs session:

• HSMs: templates aprovados para mensagens fora da janela de sessão; use para Follow-up 2 e reengajamentos.
• Session: mensagens dinâmicas e rápidas quando há sessão ativa (até 24h desde última mensagem do usuário). Use buttons/quick-replies para CTA direto.

Regras práticas de reconciliação de estoque, reserva e overcommit

Política de reserva (exemplos práticos):

• Varejo: reservar automaticamente ao iniciar checkout/abrir link de pagamento por 15 minutos; estender +15 min se o cliente pedir via chat (máx 60 min).
• Atacado: reservar após confirmação de interesse por 4–24 horas dependendo da negociação; negociar manualmente após 24h.
• TTL configurável por SKU: itens críticos podem ter TTL 5–15 min.

Sincronização de estoque e frequências:

• Eventos críticos via webhook: on_change_stock, order_created, reservation_created.
• Polling fallback 5–15 minutos para SKUs críticos; reconciliação completa nightly.
• Alerta automático quando discrepancy (reserved_qty > stock_real): bloquear oferta, marcar lead como "stock_mismatch" e notificar time de estoque/vendas.

Concorrência e locking (implantar imediatamente):

• Use locking otimista/for update: ao criar reservation, grave stock_snapshot e reservation_id; ao confirmar pagamento verifique stock_real >= reserved_qty + safety_buffer. Se falhar, rejeite e notifique.

Pseudocódigo SQL simplificado:

BEGIN TRANSACTION;
SELECT stock_real FROM sku WHERE id = :sku FOR UPDATE;
IF stock_real >= requested_qty THEN
  UPDATE sku SET stock_real = stock_real - requested_qty;
  INSERT INTO reservation(...);
  COMMIT;
ELSE
  ROLLBACK;
  notify_team('stock_mismatch', sku, requested_qty);
END IF;

Regra operacional imediata: se reserved_total > stock_real → set lead.status = 'hold', cancelar HSM promocionais ativos e notificar vendedor.

Mapeamento CRM e payloads para automação de recuperação

Campos mínimos no CRM por lead/lead_event:

• lead_id, whatsapp_id, session_id, reservation_id, product_id, sku, reserved_qty, stock_snapshot, event_type, event_timestamp, intent_detected, score, idempotency_key, last_messages (últimas 3), follow_up_count.

Eventos webhook esperados e ações CRM:

• inbound: checkout_abandoned, payment_link_sent, payment_failed, payment_confirmed, reservation_created, reservation_expired, message_received.
• ações CRM: mover_funil(pipeline_stage), criar_tarefa(due_date, owner), enviar_HSM(template_id), criar_proposta(sku, qty, price), lock_reservation(reservation_id).

Idempotency e deduplicação (prática):

• Gere idempotency_key = hash(message_id + event_id + timestamp_window). Ignore eventos com mesma key e status já processado.
• Use message_id + reservation_id como chave para evitar reenvio duplicado de HSM.

Exemplo de payload (webhook -> CRM):

{
  "event_type": "checkout_abandoned",
  "lead_id": "L123",
  "whatsapp_id": "5511999xxxx",
  "reservation_id": "R456",
  "product_id": "SKU-0001",
  "reserved_qty": 2,
  "stock_snapshot": 5,
  "idempotency_key": "msg-789-event-20261027",
  "timestamp": "2026-10-27T10:00:00Z"
}

O CRM deve responder 200 OK e pode devolver ações (ex.: {"send_hsm": "template_id"}).

Mapeamento de ações automatizadas:

• Ao payment_confirmed → mover funil para 'Pedido confirmado', decrementar reservation, enviar confirmação e nota fiscal.
• Ao reservation_expired → liberar estoque, marcar lead para reengajamento 7 dias, registrar motivo.

Playbook de hand-off: quando e como escalar do agente IA para vendedor humano

Quando escalar (regras práticas):

• score >= 70 e intenção de comprar mas necessidade de negociação (desconto, frete, prazo).
• Divergência de estoque (reserved_qty > stock_real) ou disputa de preço.
• Usuário pede falar com vendedor; >2 mensagens sem intenção clara; 2 tentativas de pagamento falhadas.

Resumo mínimo que o agente envia ao vendedor (automático):

• Últimas 3 interações (texto), intent detectada, score atual, cart snapshot (skus + qty + reservation_id + tempo restante), event_history e sugestão de ação.

Template de transferência ao cliente: "Vou passar você para um especialista que já tem seu pedido: resumo enviado. Aguarde 1–5 min."

Processo operacional pós-transferência:

• Ao transferir: set lead.status = 'em_atendimento_humano', bloquear HSM automáticos, estender TTL da reserva (+30 min) e criar tarefa no CRM com prioridade alta.

Testes, métricas, checklist E2E e próximo passo prático

KPIs para acompanhar inicialmente:

• Recovery rate por sequência (%) — % de checkouts recuperados após fluxo.
• Conversion after recovery — % que paga após receber a sequência.
• Time to payment médio pós-recovery.
• Lift por segmento (VIP vs novo) e por canal (WhatsApp vs web).
• Operacionais: fallback rate IA <10–15%; transfer rate humano <15%.

A/B tests sugeridos:

• Mensagem A: reenvio simples do link vs Mensagem B: reenvio + 5% desconto condicionado; medir taxa de pagamento em 72h.
• TTL de reserva 15 min vs 60 min para SKU crítico: medir perda por expiração vs venda duplicada.
• Personalização simples vs personalizada (incluir last_order) para medir lift por CLTV.

Checklist E2E para staging (execute 5 simulações):

1. Configurar webhook checkout_abandoned com idempotency_key.
2. Registrar HSM templates e testar envio (aprovado).
3. Implementar reserva com TTL e lock; simular concorrência.
4. Simular 3 cenários: checkout_abandon → pagar; payment_failed → novo link → pagar; concorrência duas reservas → validar bloqueio.
5. Ver logs: checar events, idempotency, updates no CRM e status final do lead.

Próximo passo prático para hoje:

• Em staging, implemente 1 gatilho (checkout_abandoned) + 1 HSM de reenvio + reserva TTL (15–60 min). Rode o checklist E2E com 5 simulações e monitore eventos no CRM por 72h. Inicie 1 A/B test simples (reenvio vs reenvio+desconto) e ajuste thresholds com os resultados.

Notas finais: treine o agente com intents e slots (use guia de treinamento do agente) e valide webhooks e idempotência conforme checklist técnico antes de ir para produção.