A scoring job should return an explanation for every supplied row, including rows that cannot receive a score. Otherwise, a polished output can hide failed website matches, inaccessible sources, duplicates, or unsupported eligibility assumptions. The buyer sees fewer rows but cannot tell whether the missing companies were deliberately excluded or simply lost in processing.
Use an input-output reconciliation as the backbone of existing-list scoring. Preserve the original row identifier, resolve company identity separately, record research outcomes, and attach a score only when the defined method supports one. This guide describes an original workflow with fictional counts and cases. It applies to a spreadsheet process as well as a more automated pipeline.
What you’ll be able to do
- Give every source row an immutable identifier and preserve it through matching, research, scoring, and delivery.
- Keep input-row counts separate from unique-company counts and scored-company counts.
- Return explicit states for duplicates, invalid inputs, ambiguous matches, research failures, and unsupported scores.
- Do not use zero as a substitute for a score that could not be calculated.
- Reconcile row dispositions before importing the results or judging the scoring model.
Define the output contract before scoring
Write down what the buyer expects to receive for each supplied row. A useful contract includes the original ID, original company name and website, resolved company identity when supported, research status, score status, score when available, criterion evidence, and an explanatory note for exceptions. This establishes that an unresolved company is still an output record rather than a reason to disappear.
Specify whether scoring is company-level or row-level. A list can contain multiple contacts, several domains, or duplicate company names. If the score belongs to the operating company, it may be calculated once and referenced by several input rows. The delivery should show that relationship explicitly. Counting the same company repeatedly can otherwise distort both cost expectations and score distributions.
Agree what happens to records outside the accepted scope. A company may be valid but irrelevant to the offer, or the input may be too ambiguous to research. These are distinct outcomes. Scope exclusions should have a defined reason, while unresolved identities should remain unresolved. A low fit score should not be used to hide either a preprocessing problem or an unsupported match.
Preserve immutable input identifiers
Assign a source_row_id before sorting, filtering, deduplicating, or normalizing the file. The identifier should remain stable even if the company name is corrected or the website redirects. A spreadsheet row number is not enough if users later sort the sheet. Preserve the original file version as well so that an ID can be traced to the exact submitted data.
Keep a separate company_id for the resolved entity. Several input rows can map to one company, and one ambiguous input can temporarily have several candidates. Do not force the company identifier to equal the domain when the business may own several domains or share a group property. The identity model should support the actual buying unit.
Retain raw and normalized values separately where transformations matter. A cleaned domain may remove a path or standardize casing, but the supplied URL can contain clues about a specific business unit or storefront. If the researcher replaces the original value entirely, a reviewer may lose the context needed to explain why the row was matched incorrectly.
Run a preflight that classifies problems
Before research begins, inspect the input for missing company names, malformed URLs, duplicate identifiers, duplicate entities, and rows that are actually people or notes rather than companies. Record the findings in a preflight report. The purpose is to make the accepted population explicit, not to delete inconvenient rows until the file looks clean.
Separate recoverable input issues from blockers. A URL with surrounding whitespace may be normalized safely under a documented rule. A company name that matches several unrelated businesses requires disambiguation. A parent-company URL supplied for a subsidiary may need a scope decision. These cases should not share a generic 'bad data' label because their next actions differ.
Freeze the accepted input version after any agreed corrections. If the buyer sends a revised file midway through research, assign a new version and compare the changes. Otherwise, the team can end up reconciling output against a moving target. A simple version note is often enough to prevent a long argument about why the delivery count does not match the latest spreadsheet.
| Input condition | Preflight state | Permitted treatment |
|---|---|---|
| Exact duplicate source row | Duplicate input | Preserve ID; link to retained research record |
| Same company, different contact | Shared company identity | Reuse company score; retain both contact rows |
| Malformed recoverable URL | Normalization required | Record supported normalization |
| Ambiguous company name | Identity unresolved | Request discriminator or return unresolved |
| Valid company outside offer scope | Scope exclusion | Return explicit criterion reason |
| Unusable or empty company input | Invalid input | Return exception with original ID |
Resolve identity before generating a score
A score about the wrong company is worse than an honest missing score because it looks actionable. Verify that the resolved website and business description correspond to the supplied entity. Use the buyer's available identifiers and context to disambiguate similar names. If the input references a subsidiary, do not automatically score the corporate group merely because the group website is easier to find.
Store the match status and its evidence. Suggested states include supported match, candidate match requiring review, ambiguous, and no supported match. A confidence label alone is less useful than a reason. A reviewer should be able to see whether the match rests on a company-authored page, a clear redirect, or only a name resemblance.
Block dependent scoring when identity is unresolved. It is acceptable to return partial candidate information as a research note, but do not let a provisional match produce a definitive score. If the company is later resolved, score the confirmed entity using the same source row ID. This keeps the workflow reversible without polluting the buyer's account list.
Separate research outcomes from scoring outcomes
Research can be complete while a score remains unavailable. The sources may establish the company identity but leave a mandatory criterion unresolved. Conversely, an early score may be provisional because research is still underway. Use separate research_status and score_status fields so that the team can see which part of the process needs attention.
Useful research outcomes include completed, partial, inaccessible sources, unresolved identity, and out of scope. Useful score outcomes include scored, provisional, not scoreable, and not applicable. Choose labels that fit the actual workflow, but do not collapse all exceptions into zero. Zero should mean the scorecard evaluated the company and assigned no points, if that is how the model is defined.
Keep the evidence behind each criterion. A numeric score without its inputs is difficult to audit and hard to update when the offer changes. If a criterion is unresolved, record that state rather than silently treating it as false. The scorecard can define a conservative treatment, but the underlying research state should remain visible.
Preserve useful unknown results A missing score can represent a completed but inconclusive research process.
Worked example: reconcile 120 supplied rows
Consider an illustrative file of 120 source rows. Preflight identifies ten exact duplicate rows and five rows with unusable company inputs. The remaining 105 distinct valid rows enter identity resolution. Eight remain ambiguous. Of the 97 supported company matches, seven are outside the agreed campaign scope and six have insufficient evidence for a required criterion. The remaining 84 receive completed scores.
The output should still account for 120 source rows: 84 scored, six not scoreable because required evidence is missing, seven scope exclusions, eight ambiguous matches, five invalid inputs, and ten duplicates linked to their retained records. These categories are mutually exclusive terminal dispositions in this example, so they sum to the original input count.
The company-level research count is different from the source-row count. If duplicate rows refer to retained companies, the research need not be repeated. The delivery should show both the 120-row reconciliation and the unique-company outcomes. Calling the result '84 leads returned' without the exception report would conceal what happened to thirty-six rows and make the buyer unable to verify the job.
| Terminal disposition | Source rows | Reason visible in delivery |
|---|---|---|
| Scored | 84 | Criteria evaluated under the accepted scorecard |
| Required evidence unresolved | 6 | Company matched; score withheld or explicitly provisional |
| Outside accepted scope | 7 | Defined exclusion criterion |
| Ambiguous identity | 8 | More input or matching review needed |
| Invalid input | 5 | Original company information unusable |
| Duplicate input | 10 | Linked to retained research row |
| Total accounted for | 120 | Matches the frozen input population |
Handle duplicates without losing buyer context
An exact duplicate row and a repeated company with different contacts are not the same thing. The first may require only a duplicate linkage. The second may contain distinct buyer relationships, owners, campaign history, or notes. Deduplicating at company level should not erase these contact-level or workflow details.
Use a mapping table when several input rows share one researched company. Each row retains source_row_id, company_id, and duplicate_or_shared_entity_reason. The score can be stored once at company level and referenced in the delivered rows, or repeated with a clear shared identity. The buyer can then decide how to import without guessing whether repeated scores represent repeated research.
Review parent and subsidiary cases manually when the relationship changes the selling motion. A group and its operating subsidiary may legitimately need separate account scores. A shared website does not make them duplicates by itself. Record the buying-unit rule and apply it consistently rather than using a domain-only merge that collapses distinct prospects.
Worked example: one company appears four times
The fictional firm Vale Instruments appears in four source rows. Two rows are exact copies. A third contains a different contact and the same corporate domain. A fourth names Vale Instruments Service, an operating subsidiary using a page under the group domain. The buyer sells an offer whose fit depends on the operating unit's services.
The researcher links the exact duplicate to its retained row, keeps the distinct contact row associated with the same company score, and reviews the subsidiary as a separate buying unit. The result may involve two company-level scorecards while preserving all four source rows. If the subsidiary's public evidence is insufficient, its score remains unresolved rather than borrowing the parent's score.
The delivery note explains the mapping. This lets the buyer retain both contacts, avoid a duplicate company import, and decide how to represent the subsidiary. A simplistic 'deduplicated from four to one' output would lose meaningful information. A simplistic 'four companies scored' output would overstate the unique-company count. The mapping resolves both problems.
Make retries safe and visible
A research failure should have a reason, attempt date, and next action. Distinguish temporary source access problems from ambiguous identity and from a completed search that found insufficient evidence. Retrying every failure in the same way wastes effort. Identity ambiguity needs better input; a temporary access issue may need a later normal retry; a genuinely undisclosed field may remain unknown.
Keep retries attached to the original row and company identifiers. A rerun should update or append evidence under a controlled version, not create a new prospect each time. If the first attempt produced partial information, preserve it with its status so that a later attempt can build on it without mistaking it for confirmed output.
Define when an attempt is finished. A record should not remain indefinitely 'processing' after the accepted research boundary has been exhausted. Return a terminal unresolved state with the reason and any useful partial evidence. The buyer can then decide whether deeper research is worth a new scope rather than waiting for a result that has no defined path to completion.
Audit the score separately from reconciliation
A perfectly reconciled file can still contain poor scores. Once every input row is accounted for, inspect a sample of high, medium, low, and unavailable scores. Check whether the criteria match the seller's offer, whether the evidence supports each criterion, and whether exclusions are applied consistently. Reconciliation proves process completeness; it does not prove judgment quality.
Look for missing-data bias. Companies with sparse public websites may receive low scores because little is known, while companies with detailed marketing pages may appear stronger merely because more evidence is available. The scorecard should distinguish confirmed mismatch from incomplete research. A separate evidence-coverage indicator can make this difference visible.
Use counterexamples to test the model. Find a company with many attractive signals but a decisive exclusion, and another with few visible signals but a clearly relevant product and buyer. Ask whether the scores reflect the actual offer logic. The result should explain why a company is relevant, not simply reward the number of populated fields.
Reconcile the delivery before importing it
Compare the output IDs with the frozen input IDs. Every input should have a permitted disposition, and no unexplained output ID should appear. Check duplicate IDs, missing IDs, unexpected repeated company records, and invalid status values. Verify that scored rows contain a valid score and that unscoreable rows do not contain an unexplained zero.
The Government Data Quality Framework guidance emphasizes communicating missing records, missing data, and deduplication. In this workflow, the reconciliation report is the practical communication artifact: it tells the buyer which rows were processed, which outcomes remain unresolved, and how duplicates were treated. Keep the report beside the delivery rather than burying its conclusions in an email thread.
Test a small import with representative states. Confirm that unresolved scores remain blank, exclusions do not enter active campaigns, and shared company identities do not create accidental duplicates. If detailed evidence is stored in linked dossiers, check that the links remain associated with the correct company. A clean CSV does not guarantee a correct destination mapping.
References: Government Data Quality Framework guidance ↗
Handle a changed scorecard as a new evaluation
If the buyer changes the offer after research begins, preserve the original scorecard and create a new version for the revised evaluation. The company facts may remain reusable, but their meaning for fit can change. A manufacturer that was unsuitable for bookkeeping support might be relevant to a different advisory offer. Do not overwrite the old score without indicating which criteria produced the new one.
Decide whether the new criteria require additional research. Reweighting existing supported inputs is different from introducing a new mandatory condition that was never investigated. If the original dossier did not research international service coverage, a new geography-dependent score should not assume that coverage from a general company description. Mark the new criterion unresolved until the accepted research step is completed.
Return a comparison that separates changed facts from changed rules. For each affected company, record the old score version, new score version, and reason the result changed. Keep all original row mappings intact. This lets the buyer assess the effect of the offer revision without confusing a change in priorities with a change in the company's business. It also prevents successive scoring runs from becoming incomparable columns with identical labels.
Use a release checklist for supplied-list scoring
Assign responsibility for the reconciliation sign-off. The person approving the score model may not be the person checking row accounting, and both reviews are necessary. Keep the accepted input version, scorecard version, delivery version, and exception report together. These four artifacts make later corrections far easier to explain.
For StackShortlist own-list work, enrichment does not guarantee new contacts. Match the acceptance check to the selected research depth and agreed scope rather than assuming that scoring creates a fresh contact at every company. Payment is taken at checkout, and the work starts after payment. A row can be successfully accounted for while a particular field remains explicitly unresolved under the accepted specification.
- Freeze the input and assign stable source-row identifiers before any transformations.
- Define the company buying unit and preserve raw values beside normalized values.
- Classify preflight problems without silently deleting rows.
- Resolve entity identity before calculating dependent fit scores.
- Keep research status, score status, and exclusion reason separate.
- Preserve duplicates through explicit mappings and retain distinct contact context.
- Verify that terminal dispositions sum to the complete input population.
- Audit score evidence, then test destination mappings before broad import.
Common questions
Should records that cannot be scored remain in the output?
Yes, with a clear status and reason. The buyer needs to distinguish ambiguous identities, insufficient evidence, invalid inputs, exclusions, and processing failures. Returning only scored rows makes it impossible to tell which companies were deliberately omitted and which were lost.
Can I use zero for an unavailable score?
Avoid it unless the scorecard explicitly defines zero as that state and downstream users can distinguish it from evaluated non-fit. In most workflows, leave the score empty and use a score_status field. Zero usually looks like a completed judgment and can distort ranking or reporting.
Does every supplied row need separate research?
Not necessarily. Exact duplicates or several contacts at the same company may share company-level research. Preserve each source row and map it to the appropriate company result. Distinct subsidiaries or buying units may still require separate evaluation even when they share a domain.
What should a correction request include?
Provide the source-row ID, input version, expected company identity, delivered status or score, and the evidence showing the problem. State whether the issue concerns reconciliation, matching, source interpretation, or score logic. This helps the researcher fix the right layer and identify other affected records.
How do I know the output count is correct?
Compare stable IDs against the frozen input and confirm that mutually exclusive terminal dispositions sum to the input-row count. Then report unique companies and scored companies separately. Matching totals alone is not enough if duplicate IDs conceal missing rows, so check the actual identifier sets as well.
Sources & further reading
Primary references support the technical details. Worked examples are illustrative; workflows and checklists are practical methods to adapt to your own process.
Something changed? Tell the editorial team.