Revisão de leads: status, prazos e decisões contestadas
Organize a análise de leads com responsáveis, prazos, evidências, motivos de recusa e revisão de decisões. Exemplos didáticos e checklist de preparação.
Um lead pode chegar no prazo e continuar semanas sem uma decisão compreensível. O afiliado vê uma espera, o anunciante uma fila e a operação procura conversas em vez de verificar um evento. Comece combinando quem analisa cada solicitação, segundo quais condições, até quando e com qual explicação.
Este guia ajuda anunciantes e equipes operacionais a organizar a análise de solicitações já recebidas. Aplique-o a produtos permitidos após verificar as exigências regionais pertinentes. Todos os prazos, códigos e números são didáticos, não condições da AffiliateCore. O exemplo trata de um serviço digital comum e não comprova a disponibilidade de uma oferta desse tipo no catálogo.
1. Defina o objeto da decisão
Separe três perguntas: o evento ocorreu, atende às condições acordadas e a liquidação financeira terminou? Receber um postback comprova o recebimento de uma mensagem, não a qualidade do lead por si só. Uma conversão confirmada também não significa necessariamente saldo disponível para saque: retenção e operações financeiras são verificadas separadamente.
Antes do lançamento, documente evento, atributos obrigatórios, fontes permitidas, regras para solicitações repetidas, janela de observação e versão das condições. Em um pedido didático de demonstração de software, o evento pode ser um formulário enviado com produto selecionado. Uma compra dentro de um mês não pode virar silenciosamente uma condição adicional depois que o tráfego chegou. Se a remuneração depende de outro evento, defina-o antes.
O resultado é uma página de regras com início de vigência. Guarde versões anteriores para reconstruir as condições de uma solicitação contestada. Combine mudanças para eventos futuros, sem usá-las para reduzir resultados já aceitos.
2. Atribua responsáveis por etapa
Uma pessoa recebe a fila, um responsável técnico verifica evidências quando necessário e uma parte autorizada registra o resultado. Uma equipe pequena pode acumular funções, mas é preferível que a contestação seja analisada por alguém que não tomou a decisão inicial. Nomeie substituto para férias e contato de escalonamento.
Fluxo didático: recebido → identificado → condições verificadas → decisão fundamentada → comunicação → reavaliação diante de novas evidências. Informação insuficiente gera uma solicitação com responsável e prazo. É um processo de equipe, não uma representação de automação integrada à AffiliateCore.
Com as regras preparadas, você pode cadastrar-se como anunciante na AffiliateCore, completar as informações exigidas e usar o documento ao preparar sua própria oferta. O cadastro não confirma a elegibilidade do produto nem a prontidão para lançamento.
3. Diferencie etapas de trabalho e status
A lista de conversões verificada no painel do anunciante AffiliateCore oferece visualização e filtro por status. Ela mostra tipo de evento, identificador externo, valor e moeda do evento, cobrança do anunciante, motivo de rejeição, oferta e horário do evento. Essa lista não permite ao anunciante editar ou excluir conversões livremente.
| Status exibido | Pergunta operacional |
|---|---|
| pending | Quem analisa e quando se espera a decisão? |
| confirmed | Qual condição foi confirmada? Verifique retenção e liquidação à parte. |
| rejected | Qual regra não foi atendida e onde está a evidência? |
| reversed | Por que um resultado anterior foi revertido? Não confunda com recusa inicial. |
| disputed | O que está sendo contestado e quem analisa? |
O rótulo disputed não comprova envio automático de recurso, contador de prazo ou área própria de contestações. Na verificação, não foi confirmado um fluxo completo de recursos acessível aos participantes. Mantenha o registro de casos e os prazos sugeridos na ferramenta de trabalho combinada. A parte autorizada altera os status do sistema. Não prometa ao parceiro um botão indisponível.
4. Dê um ponto inicial aos prazos
“Analisamos rapidamente” é vago. “Triagem até o próximo dia útil após o recebimento; se faltarem dados, informamos quais e uma nova data” é acionável. Um piloto didático pode prever dois dias úteis para uma decisão comum e mais um para escalar um atraso. Combine valores reais de acordo com demanda, feriados, região e momento em que o evento-alvo pode ser observado.
Registre separadamente horário do evento, recebimento e limite da decisão. Defina um fuso e inclua o deslocamento ao compartilhar horários. Entrega tardia não caracteriza automaticamente uma infração do afiliado: investigue primeiro a causa e a regra aplicável.
A espera por evidências não deve zerar silenciosamente a idade do lead. Preserve prazo original, motivo da extensão, responsável e nova data. O vencimento gera escalonamento, não rejeição ou crédito automático, salvo quando esse mecanismo estiver acordado e implementado.
5. Reúna evidências suficientes e limitadas
Uma análise precisa do ID do evento na origem, ID da conversão na plataforma quando disponível, vínculo com clique, oferta, horário, versão da regra e referência à evidência. ID de usuário não substitui ID de evento: a mesma pessoa pode realizar diferentes ações permitidas.
No registro de decisões, inclua status anterior e novo, analista, data, fundamento e vínculo com a decisão anterior. Entrega repetida da mesma mensagem não é um lead novo. IP compartilhado ou endereço semelhante também não prova, isoladamente, duplicidade ou fraude. Verifique a identidade do evento e as condições combinadas.
Não envie senhas, segredos de postback, documentos completos nem contatos desnecessários de visitantes. Use acesso restrito ou um extrato com dados ocultados que explique o motivo. O OWASP Logging Cheat Sheet traz orientações gerais para registros e proteção; o processo deste artigo é um modelo editorial de trabalho.
6. Separe recusa e pedido de evidência
Estes códigos didáticos evitam a expressão “tráfego ruim” sem explicação. Não são um dicionário integrado à AffiliateCore.
EVENT_DUPLICATE — O mesmo evento foi registrado novamente. O que anexar: Referência original e critério de correspondência.
TERMS_MISMATCH — Uma condição vigente específica não foi atendida. O que anexar: Cláusula, versão e fato verificável.
EVENT_NOT_MET — A ação-alvo acordada não foi concluída. O que anexar: Estado da origem ao terminar a janela de observação.
NEEDS_EVIDENCE — Faltam informações para decidir. O que anexar: Pedido exato, destinatário e prazo de resposta.
A última linha é uma tarefa, não um motivo definitivo de rejeição. Sinais antifraude também exigem interpretação. Se uma falha do seu sistema impede obter provas, registre o incidente e a data de análise. Não transforme incerteza em acusação contra o parceiro.
7. Exemplo: apresente a fila sem distorcer percentuais
Um serviço digital fictício recebeu 100 leads únicos em uma semana, depois de remover entregas repetidas. No momento do relatório, 60 estão confirmados, 20 rejeitados com fundamento e 20 aguardam decisão. Foram concluídas 80 análises. Confirmação entre decididos: 60 / 80 = 75%; entre todos os recebidos: 60 / 100 = 60%. Informe o denominador, pois as métricas respondem a perguntas diferentes.
Oito dos 20 pendentes estão atrasados. A participação vencida da fila aberta é 8 / 20 = 40%. Não transforme pendências em recusas para fechar um relatório. Atribua responsáveis aos oito atrasos e depois examine idade e motivos de espera dos demais.
Se 12 das 20 recusas forem explicadas como mensagens repetidas, revise a definição da coorte. Nosso total inicial já excluía entregas repetidas; essa explicação exigiria corrigir os dados de origem. A conta precisa corresponder à unidade contada, não apenas somar cem.
Exercício: prepare essa tabela para sua oferta sem dados pessoais. Compare-a com os status disponíveis na conta de anunciante e encaminhe uma lista separada de divergências ao operador responsável. Não crie eventos remuneráveis fictícios para testar uma planilha.
8. Exemplo: reavaliar uma decisão contestada
L-041 foi rejeitado como duplicata de L-019. O parceiro apresenta dois IDs de evento diferentes. O analista recupera as condições vigentes: uma nova solicitação só é permitida para outro produto. Depois confere produto e horário na origem. Outro identificador, sozinho, não prova a razão do parceiro; o mesmo IP não prova a validade da recusa.
Se for confirmado um evento distinto e elegível, a parte autorizada corrige o resultado pelo procedimento disponível. Preserve decisão original, novas evidências, data da reavaliação e motivo. Verifique o efeito financeiro separadamente. Reenviar postback não deve ser usado para “adicionar o crédito que falta”.
Se a decisão for mantida, responda com regra e fato concretos, não só “rejeitado”. Se ainda faltarem evidências, indique próxima ação e data. Encerrar um caso apenas porque venceu um prazo interno não substitui uma decisão fundamentada.
9. Meça a operação de análise
Semanalmente, examine a fila aberta em um horário definido, número de atrasos, mediana e percentil 90 do tempo até a primeira decisão, proporção de decisões fundamentadas e resultados de reavaliações. Calcule tempos sobre registros concluídos e mostre separadamente a idade dos abertos. Caso contrário, casos demorados ainda não resolvidos desaparecem da métrica de velocidade.
Calcule decisões iniciais alteradas entre contestações resolvidas, não entre todos os leads. Três reavaliações não sustentam uma conclusão forte sobre uma fonte. Compare períodos, versões de regras e coortes suficientemente maduras. Mais recusas podem indicar mudança na definição do evento ou erro operacional; investigue antes de julgar o tráfego.
10. Preparação e próximo passo
Antes do piloto, confira evento e versão de condições; responsável e substituto; início do prazo; evidências para motivos; diferença entre esclarecimento e rejeição; responsável por contestação; histórico preservado; relatórios separados de abertos e decididos.
Faça uma simulação de mesa com três fichas didáticas: lead comum, mensagem repetida e contestação com novas evidências. O critério de prontidão é o analista identificar regra, próximo passo, responsável e prazo em cada uma. Caso contrário, esclareça o processo antes do lançamento, em vez de inventar novos status.
Consulte os guias de apresentação clara da oferta e divergências de relatórios. O resultado aqui é uma decisão reproduzível por lead, não configuração de atribuição nem promessa de taxa de aprovação.
Cadastre-se como anunciante na AffiliateCore, complete os dados obrigatórios e prepare sua oferta com condições de revisão acordadas. Elegibilidade, verificações exigidas e moderação são etapas distintas. Criar a oferta não garante lançamento nem tráfego. Guarde o processo com sua equipe e confirme a comunicação disponível com a plataforma antes do primeiro teste.