Keep account evidence separate from the score
An account-prioritization score is only useful when its inputs refer to the intended account. Confirm the account identity, preserve source and observation time for each field, and keep missing data distinct from evidence of poor fit. For example, if an employee-size range crosses two segments, label the segment uncertain under your policy instead of turning the midpoint into an exact headcount. If an advertising observation contributes to a signal, retain its source and scope; an observed ad does not prove a budget or purchase intent. Use company-domain matching to establish the account record and competitive advertising intelligence to build an evidence-linked research brief. Re-run the score only from the accepted inputs and record the rule version so the team can explain why priority changed.Who this is for
GTM leaders that need to allocate research, outbound, and account-executive time.Decision guide
Operating method
- Write the trigger, record identity, inputs, accepted output, owner, deadline, and permitted side effects.
- Run a representative sample in dry run and label every result accepted, rejected, or unknown with a reason.
- Apply explicit validation and precedence rules before any CRM or warehouse write.
- Retain the workflow version, source evidence, provider receipt, cost, and final result for each record.
- Review exception aging and recurrence on a fixed cadence, then repair the upstream rule that creates repeated failure.
Implementation details
- Accept a company domain, CRM account ID, or a reviewed CSV row as the record key. Do not merge companies from name similarity alone.
- Save the source URL and retrieval time beside each research field. Keep unknown values null instead of asking a model to fill them.
- Separate discovery from scoring. First build the evidence set, then apply a versioned scoring rule that an operator can inspect.
- Return the matched account, supporting evidence, rejected candidates, and the reason for the final decision.
Common failure modes
- Treating a provider response or model output as accepted without a business validation rule.
- Allowing several systems to write the same commercial field without a precedence policy.
- Counting an incomplete or failed result as a successful workflow run.
- Optimizing a provider price while ignoring acceptance rate, retries, and manual repair.