Um Claude Skill que recebe uma lista de contas-alvo ABM e uma rubrica ICP e retorna um relatório de defeitos por conta — cada conta que não atende aos critérios recebe um código de defeito de uma taxonomia definida (wrong-size, wrong-industry, wrong-geo, stale-data, low-intent, missing-field), um nível de qualidade (Q1 a Q4), uma pontuação de qualidade da lista e uma fila de remediação priorizada. O bundle está em apps/web/public/artifacts/abm-list-quality-audit-skill/ e contém SKILL.md mais três templates de referência que o usuário adapta antes do primeiro uso.
Ele responde à pergunta que a maioria das campanhas ABM ignora antes do lançamento: “Das 300 contas nesta lista, quantas realmente atendem ao nosso ICP, e o que exatamente está errado com as que não atendem?” Sem essa resposta, o gasto em plataformas ABM — 6sense, Demandbase, LinkedIn matched audiences — vai para contas que você nunca converteria, e os resultados decepcionantes da campanha são atribuídos a mensagem ou canal em vez de qualidade de lista.
Quando usar
Use este skill antes de carregar qualquer lista ABM em uma plataforma de mídia paga, antes de atribuir contas nomeadas a AEs e antes do lançamento de qualquer campanha em que a lista foi montada há mais de 90 dias. As listas ABM se degradam mais rápido do que a maioria das equipes de RevOps percebe: os dados de headcount ficam desatualizados, os estágios de financiamento mudam, empresas são adquiridas e a própria rubrica ICP às vezes muda sem que a lista seja reavaliada.
O skill também é a ferramenta certa para higiene trimestral de listas. Execute-o em todo o seu universo ABM — não apenas nas listas de campanha — para encontrar contas que foram adicionadas quando seu ICP era diferente e não foram reavaliadas desde então. A tabela de frequência de defeitos diz quais lacunas de enriquecimento são mais comuns em seu universo, o que é acionável para quem é responsável pelo workflow de enriquecimento do Clay.
Invoque a partir de:
- Uma tabela do Clay onde cada linha é uma conta, acionada manualmente antes do lançamento de uma campanha ou em um cron trimestral. O skill escreve
quality_tieredefect_codesde volta para duas colunas do Clay; a automação downstream pode filtrar nelas para suprimir contas Q3/Q4 de uploads de campanha. - Uma verificação pré-voo de CSV antes de importar para o 6sense ou qualquer plataforma de publicidade ABM. Executar a auditoria remove contas que você de outra forma pagaria para atingir — nas taxas típicas de CPM de ABM ($20-40 por 1.000 impressões), remover 50 contas fora do ICP de uma lista de 500 reduz o desperdício em 10%.
- Um trigger baseado em relatório do Salesforce sobre contas nomeadas em um segmento, escrevendo
ABM_Quality_Tier__ceABM_Defect_Codes__cde volta ao registro de conta.
Quando NÃO usar
Pule este skill quando:
- Você quer pontuar MQLs inbound. A auditoria é projetada para listas de contas nomeadas outbound. Para triagem de leads inbound, o skill lead-scoring-icp-rubric é a ferramenta certa — ele lida com o fluxo de lead único e a lógica de escalonamento borderline que importa para inbound.
- Sua rubrica ICP ainda não existe. O skill audita em relação a uma rubrica que você fornece. Se você não teve a discussão sobre ICP — quais indústrias, faixas de headcount e geografias você realmente ganha — essa conversa deve acontecer primeiro. Executar uma auditoria contra uma rubrica de placeholder produz uma falsa sensação de rigor.
- A lista precisa de deduplicação, não de auditoria. Se o objetivo é remover clientes atuais, concorrentes, contas canceladas ou contatos com GDPR suprimido, isso é uma operação de filtro, não uma auditoria ICP. Execute essas exclusões antes da auditoria, ou o skill gastará tokens pontuando empresas que você já sabe que quer excluir.
- Você precisa gerar a lista, não auditá-la. O skill recebe uma lista existente como entrada. Ele não executa descoberta de TAM nem gera novas contas. Use um workflow dedicado de construção de listas — Clay mais critérios ICP — para produzir a lista bruta primeiro.
- A lista tem menos de 20 contas. Abaixo desse tamanho, um RevOps ou AE experiente pode revisar manualmente cada conta em menos de uma hora. O custo de configuração do skill (configuração de rubrica, personalização de taxonomia de defeitos) não vale a pena.
Configuração
A configuração leva de 30 a 60 minutos, assumindo que a rubrica ICP existe. A discussão sobre a rubrica — alinhar RevOps, liderança GTM e um ou dois AEs sobre o que realmente significa uma indústria e uma faixa de headcount de nível A — leva mais tempo e acontece antes da configuração.
- Instale o Skill. Copie
apps/web/public/artifacts/abm-list-quality-audit-skill/SKILL.mde a pastareferences/para seu diretório.claude/skills/abm-audit/, ou faça upload como Skill no claude.ai. Os camposnameedescriptiondo frontmatter são o gatilho em prompts relevantes. - Configure a rubrica ICP. Abra
references/1-icp-rubric-template.md. Se sua equipe já usa o skill lead-scoring-icp-rubric, você pode referenciar o mesmo arquivo de rubrica — a estrutura é idêntica. Substitua as linhas de placeholder por critérios reais, pesos (1-5) e valores de nível (A / B / C). Preencha a seção de desqualificadores definitivos. Atualize “Last edited” — o SHA-256 que o skill registra em cada rodapé de relatório garante que os stakeholders possam saber quando a rubrica mudou. - Configure a taxonomia de defeitos. Abra
references/2-defect-taxonomy.md. Os próprios códigos de defeito são fixos — não os renomeie, pois parsers downstream usam as strings de código. Edite a coluna “Remediation action” para corresponder ao processo real da sua equipe: qual coluna do Clay fornece o re-enriquecimento de headcount, quem é o responsável pela assinatura do ZoomInfo, qual segmento cuida das contas de estouro empresarial. - Prepare os scores de intenção (opcional mas de alto valor). Se você usa 6sense ou Bombora, exporte um mapa
domain → intent_scorepara seu universo de contas e passe-o como entradaintent_scores. Isso adiciona anotaçõeslow-intenteintent-spikesobre as pontuações da rubrica — o flagintent-spikeé particularmente valioso para contas Q2 que estão em ICP mas são borderline, porque as coloca em evidência para priorização mesmo antes do re-enriquecimento. - Defina o limite de obsolescência do enriquecimento. Atualize
enrichment_staleness_dayspara corresponder à agressividade com que sua camada de enriquecimento recicla dados. O Clay + ZoomInfo tipicamente atualiza em um cronograma de 90 dias; se você executa enriquecimento mensal, pode definir 45 dias. Isso aciona o código de defeitostale-data. - Teste em uma lista conhecida. Execute o skill em 20-30 contas que você conhece bem — uma mistura de clientes atuais, contas canceladas e prospects de qualidade variada. Verifique se os níveis de qualidade correspondem à intuição da sua equipe. Se contas Q1 estão mostrando códigos de defeito, a rubrica está mal calibrada. Se contas obviamente fora do ICP estão pontuando Q2, os desqualificadores definitivos ou pesos precisam de ajuste.
O que o skill realmente faz
O skill executa quatro etapas em uma ordem fixa.
Etapa 1 — varredura de desqualificadores definitivos. Antes de qualquer chamada LLM, cada conta é verificada contra os desqualificadores definitivos da rubrica: país sancionado, indústria desqualificada, headcount abaixo do mínimo absoluto, contas na lista de exclusão explícita (concorrentes, clientes atuais). As que correspondem recebem o código de defeito hd:{reason} e um nível de qualidade de disqualified. Esta etapa é determinística e é executada em cada conta em milissegundos. Por que executar primeiro: em uma lista de 500 contas, é comum que 5-15% das contas sejam desqualificações imediatas — executar pontuação LLM nessas contas desperdiça tokens e adiciona latência sem adicionar informação.
Etapa 2 — pontuação da rubrica ICP por conta. Contas que passaram pela varredura de desqualificadores definitivos são pontuadas em cada critério da rubrica. Para cada critério, o modelo emite um nível (A / B / C), um peso (da rubrica) e uma justificativa de uma frase citando a linha da rubrica. A soma ponderada mapeia para um nível de qualidade: Q1 (pontuação ≥ 8,0), Q2 (6,0-7,99), Q3 (4,0-5,99), Q4 (< 4,0). Critérios com falha geram os códigos de defeito correspondentes — uma pontuação de critério C de headcount em uma conta abaixo do mínimo do nível B gera wrong-size:too-small.
Por que por critério em vez de uma pontuação holística: os códigos de defeito que impulsionam a fila de remediação requerem saber qual critério específico falhou, não apenas que a pontuação geral foi baixa. Uma conta Q3 com missing-field:tech_stack é uma tarefa de remediação diferente de uma conta Q3 com wrong-industry — a primeira precisa de enriquecimento, a segunda precisa de remoção.
Etapa 3 — detecção de defeitos suplementares. Após a pontuação da rubrica, o skill verifica defeitos não cobertos pela rubrica: stale-data (enriquecimento mais antigo que o limite), missing-field:{field} (critérios que não puderam ser pontuados), low-intent e intent-spike dos scores de intenção fornecidos. O flag intent-spike pode aparecer mesmo em contas Q2 — ele coloca em evidência contas onde o comportamento no mercado deveria anular a pontuação de rubrica borderline e acionar contato direto do AE de qualquer forma.
Etapa 4 — agregação no nível da lista. Após a pontuação por conta, o skill calcula a pontuação de qualidade da lista (Q1% + Q2% - Q3% - 2×Q4%, escalado para 100), a tabela de frequência de defeitos e a fila de remediação. A fila de remediação é ordenada por estimativa de elevação na re-auditoria: contas com maior probabilidade de se tornar Q1 após re-enriquecimento aparecem primeiro. Uma pontuação de qualidade de lista abaixo de 30 é o sinal de go/no-go do skill — a seção de recomendação dirá “Não lançar até que as contas Q3/Q4 sejam remediadas ou removidas.”
Realidade de custos
O custo de tokens por conta depende do tamanho da rubrica e de quantos dados de conta são fornecidos. Para uma rubrica típica de 6 critérios com output estruturado por critério e um registro de conta de 300-500 tokens de dados, espere aproximadamente 1.200-2.000 tokens de entrada e 300-500 tokens de saída por conta. Nos preços do Claude Sonnet 4.x (aproximadamente $3 por milhão de tokens de entrada e $15 por milhão de tokens de saída no início de 2026), isso representa $0,008-0,015 por conta.
Uma auditoria pré-campanha de 500 contas custa $4-8 em tokens do Claude. Uma passagem trimestral de higiene em um universo ABM de 2.000 contas custa $16-30. Esses valores são menores do que o custo de uma única sequência de AE mal roteada. O custo não relacionado a tokens é maior: configurar corretamente a rubrica e a taxonomia de defeitos é uma sessão de 60-90 minutos; planeje para isso.
O custo de tokens por conta é menor do que o skill de pontuação de leads porque as contas ABM tipicamente têm dados estruturados mais ricos (menos campos ausentes) e os códigos de defeito são mais compactos do que uma justificativa completa por critério. Se suas contas têm muitos campos ausentes, mais do processamento cai na etapa de defeito suplementar, que é determinística e gratuita.
O cache de prompts dos arquivos de rubrica e taxonomia de defeitos vale a pena de forma significativa em escala — em uma auditoria de 500 contas, a rubrica é carregada uma vez e armazenada em cache em todo o lote. Em uma verificação pontual de 5 contas, não faz diferença.
Métrica de sucesso
A métrica principal para a auditoria é a tendência de pontuação de qualidade da lista: execute a auditoria no mesmo universo ABM a cada trimestre e acompanhe se a pontuação de qualidade da lista sobe. Uma pontuação crescente significa que sua cadência de enriquecimento está funcionando, sua rubrica é estável e seu processo de construção de listas foi ajustado. Uma pontuação em queda — ou uma pontuação que permanece estável apesar do esforço de remediação — significa que a rubrica mudou ou que a fonte de enriquecimento não é confiável.
Métrica secundária: taxa de conversão de campanha ABM por nível de qualidade. Após 90 dias de execução de campanhas contra listas auditadas, compare a taxa de conversão para oportunidade para contas Q1 vs contas Q2 vs contas que foram remediadas de Q3 antes de serem incluídas. Q1 deve converter a uma taxa maior do que Q2, e Q2 após remediação deve converter a uma taxa maior do que Q3 não auditado. Se não houver diferença de conversão entre níveis, a rubrica não é preditiva e precisa ser re-argumentada.
Modos de falha
- Códigos de defeito que acusam a rubrica, não a lista. Se 35% da sua lista recebe
wrong-size:too-small, o problema é geralmente o mínimo de headcount na rubrica, não a lista. A rubrica pode ter sido definida quando seu movimento era puramente empresarial e não foi atualizada desde que você abriu um segmento SMB. Agir sobre esses códigos de defeito removendo 35% da lista é o movimento errado; reexaminar a rubrica é o correto. Guard: após cada auditoria, verifique se algum código de defeito único se aplica a mais de 25% das contas. Se sim, revise o critério da rubrica que gera esse código antes de remediar a lista. A tabela de frequência de defeitos no output da auditoria torna essa verificação fácil — o código mais comum é sempre a linha um da tabela. - Enriquecimento desatualizado produzindo falsos negativos em boas contas. Uma conta com
last_enrichment_datede 14 meses atrás pode ter triplicado o headcount, levantado uma Série B e adicionado Salesforce ao seu tech stack desde que esses dados foram coletados. O veredicto Q4 do skill sobre essa conta não é um veredicto sobre a empresa — é um veredicto sobre sua cadência de enriquecimento. Remover ou despriorizar essas contas antes de re-enriquecê-las perde pipeline real. Guard: o skill adicionastale-dataa qualquer conta onde o enriquecimento ultrapasse o limite de obsolescência e anota “scored on potentially stale data” na justificativa. A fila de remediação coloca contasstale-data+ alto potencial de pontuação da rubrica no topo. A regra vigente: nunca remover uma conta da lista somente por causa destale-data; sempre re-enriquecê-la primeiro. - Inflação de score de intenção por comportamento de usuário único. Uma empresa em um segmento de “alta intenção” do 6sense pode estar lá porque um analista júnior da empresa leu três posts do blog. Apresentar essa empresa como
intent-spikee roteá-la para contato direto do AE com base nesse sinal é um falso positivo que consome tempo do AE. Guard: quandointent_scoressão fornecidos, o skill exibe a pontuação de intenção bruta e a fonte junto com o flagintent-spike. A orientação vigente no output do skill: antes de agir em qualquer sinalintent-spike, verifique com o 6sense ou sua plataforma ABM que a atividade de intenção origina de personas do comité de compra — nível diretor ou acima em áreas funcionais relevantes — em vez de um único usuário de baixa autoridade. - Deriva da rubrica invalidando comparações históricas de auditoria. Se a rubrica muda entre a auditoria do Q2 e a auditoria do Q3, as pontuações de qualidade de lista não são comparáveis — uma pontuação crescente pode simplesmente refletir uma rubrica mais flexível, não uma melhoria real da lista. Guard: o skill registra o SHA-256 da rubrica em cada rodapé de auditoria. Ao comparar pontuações de qualidade de lista trimestre a trimestre, confirme que o SHA-256 da rubrica é idêntico. Se a rubrica mudou, re-execute a lista do trimestre anterior contra a nova rubrica antes de fazer comparações. A data “Last edited” no arquivo de rubrica e o lembrete trimestral no calendário para revisar a rubrica trabalham juntos para tornar a deriva visível antes que ela distorça a tendência.
vs alternativas
vs revisão manual de RevOps. Para uma lista com menos de 50 contas, um analista de RevOps experiente com a rubrica ICP aberta pode revisar manualmente cada conta em 2-3 horas e produzir um resultado melhor calibrado do que o skill — humanos captam casos extremos, como “essa empresa tem um código SIC estranho mas seu produto real claramente está em nosso ICP,” que o skill perderá. Acima de 150 contas, a revisão manual se torna inconsistente: a intuição ICP do analista deriva entre a primeira conta e a 130ª. O skill aplica a rubrica de forma consistente em qualquer tamanho de lista.
vs a gradação de contas integrada do 6sense. O 6sense fornece uma pontuação de fit de conta com base em seu modelo ICP proprietário, treinado em empresas no seu CRM com histórico positivo de engajamento. É útil quando você tem histórico de CRM suficiente para o 6sense aprender (tipicamente 50-100 contas ganhas). Para equipes abaixo desse patamar, o modelo de fit do 6sense está sub-treinado e ruidoso. Este skill funciona desde o primeiro dia porque a rubrica é de autoria manual. A compensação: o modelo do 6sense capta padrões que você não escreveu explicitamente; este skill só sabe o que você disse a ele. Para equipes com 50+ fechadas-ganhas, execute os dois — use a pontuação do 6sense para “o que me surpreende” e os códigos de defeito deste skill para “o que especificamente está errado com as contas Q3.”
vs uma matriz de pontuação ICP em planilha. Muitas equipes de RevOps têm uma planilha onde avaliam manualmente cada conta em relação aos critérios ICP. A abordagem de planilha falha em escala (a consistência cai acima de 50 contas), não produz uma taxonomia de defeitos (diz a pontuação, não por que está errada) e fica desatualizada no momento em que a rubrica muda porque ninguém atualiza todas as linhas pontuadas anteriormente. Este skill aplica a rubrica de forma consistente, nomeia o defeito específico e o mecanismo SHA-256 garante que você saiba quando a rubrica se moveu. A planilha é a ferramenta certa para as primeiras 20 contas; o skill é a ferramenta certa depois disso.