How to hand research-ready B2B accounts to outbound.

The direct answer

An account is sales-ready when its next owner can understand why it was selected, what evidence supports the next action, what remains unresolved, and what they are allowed to do next without reopening every research tab. It is not sales-ready merely because it has a company name and a contact field.

Define a compact handoff contract before research starts. It should distinguish account fit from contact availability, evidence from inference, and an approved next action from a suggestion. The contract creates a feedback loop: rejected accounts return with a reason that improves upstream discovery instead of becoming unexplained rep frustration.

This Guide owns the minimum research packet for one account. It does not design CRM authority, integration, reconciliation, sequence execution, or territory routing. For the broader cross-system workflow, read How to run outbound pipeline in one platform.

1. Use a minimum viable research packet

Do not export every research note. The packet should contain the evidence needed for the immediate action and links or identifiers for deeper review. Restrict sensitive data to the purpose and authorised recipient.

2. Define what an outbound owner can reject

If a rep says “bad lead,” the research system learns nothing. Give recipients a finite feedback taxonomy:

• wrong entity or duplicate;
• does not meet the documented ICP;
• evidence is stale or does not support the claim;
• role hypothesis is irrelevant or incomplete;
• account is already engaged, customer, competitor, or otherwise excluded;
• country/channel/policy state is unresolved;
• contact research result is unusable; or
• next action was unclear.

Use stable codes for those reasons in the handoff artifact: wrong_entity_or_duplicate, icp_mismatch, evidence_insufficient_or_stale, role_hypothesis_unusable, existing_state_or_exclusion, policy_or_channel_unresolved, contact_research_unusable, and next_action_unclear. An optional short note can point to a correction; the code keeps feedback comparable without replacing the original evidence.

Review recurring reasons weekly. Three “wrong entity” returns point to identity rules; a cluster of stale sources points to freshness policy; many “already engaged” returns point to an exclusion or system-of-record gap. Do not punish reps for returning a record that the contract says they may reject.

3. Keep a two-step acceptance gate

This prevents a research team from implying that it can approve commercial or legal actions it does not own. It also prevents an outbound team from silently reclassifying the ICP through one-off exceptions.

Use the research-to-outbound handoff schema

Download the research-to-outbound handoff schema. A valid handoff has a packet version, handoff date, canonical account, ICP version, inclusion reason, dated source, evidence status, account decision, role hypothesis, separate contact-research state, policy reference, owner, and allowed next action. Account decisions use pass, review, or fail; an unknown evidence status routes to review rather than becoming a fourth decision. The sample row is intentionally not outreach-ready: it models the difference between a reviewed account and permission to act. Return rejected rows with one controlled feedback-reason code and an optional short note, rather than overwriting the original research decision.

4. Measure decision quality, not rows delivered

Track accepted handoffs ÷ delivered handoffs, rejection reason mix, time to first owner decision, evidence-complete rate, and repeat returns after a correction. Do not use reply rate as the only validation; it depends on offer, messaging, timing, channel, and rep behaviour as well as account quality.

Sample both accepted and rejected handoffs. A healthy process can reject accounts. The warning sign is a handoff that cannot explain why it was accepted or a rejection that cannot improve the upstream rule.

5. Build the packet in the order an owner needs to decide

The handoff schema is deliberately not a long research report. Put the fields in the order a recipient uses them:

1. Identity first. State the canonical account name, domain, and any identifier your team uses. If the entity is uncertain, stop at research acceptance; do not make a sales-ready packet.
2. Why this account. Record the ICP version, inclusion rule, and a short, dated evidence statement. "Looks relevant" does not let another person reproduce the choice.
3. What is known and unknown. Put the account decision, source link, date, role hypothesis, and contact-research outcome in separate fields. A missing contact is not a failed account; a good account is not proof that a contact is correct. If the role is still only a title guess, return to the buying-committee hypothesis workflow before contact lookup.
4. What is permitted next. Reference the policy or review state and name the owner. This can be "review account", "research a role family", or "hold until policy review". It must not imply that a research note grants consent, territory ownership, or campaign eligibility.
5. How to return it. Give the recipient one structured feedback reason and a place for a concise source correction. The original research decision and its evidence remain visible when the record returns upstream.

This order makes a practical distinction: a field can be present but not ready to support the next action. For example, a company domain may be confirmed, the ICP reason may be strong, and contact lookup may still be pending. That is an account ready for a defined research queue, not automatically an account ready for outreach.

Set field-level acceptance rules

For every required packet field, decide whether the recipient needs a value, an allowed state, or a link to a controlling record. A simple field contract keeps teams from using a red/green status with no explanation:

Do not convert this table into an automatic legal or sales approval engine. It is a shared definition of what a recipient may understand from the record.

6. Use accepted, returned, and held examples

Consider three fictional accounts in the same ICP. They show why a single "ready" flag is too coarse.

Example A: accepted for a bounded next step

An account's domain and entity are resolved. A dated company-controlled page supports the operating characteristic used in the current ICP. The packet names the ICP version, retains the source URL and date, labels a service-operations role family as a hypothesis, and says: "Account owner: assess role relevance; no outreach instruction in this packet." The recipient accepts it for account review because the decision and boundary are clear. That acceptance does not turn the role hypothesis into a named buyer or authorise a campaign.

Example B: returned with a useful correction

The entity is correct, but the source describes a subsidiary outside the defined market. The recipient returns the packet with "does not meet documented ICP" and links the relevant entity information. Research keeps the original inclusion reason, records the return, and tests whether the discovery rule needs an entity-boundary check. This is useful feedback, not a failed rep action.

Example C: held rather than forced through

The account fits, but the controlling country or channel review is unresolved. The handoff shows that status plainly and assigns an owner to resolve it. The right next action is hold or policy review, not a workaround such as exporting the account without the status. A high-quality handoff makes a justified pause easy to see.

The examples are operational patterns, not claims about any prospect or automatic Leadbase outcome. Use your own eligibility and outreach policies to decide which actions are permitted.

7. Make feedback change a rule, not only a row

One returned account can be an edge case. Repeated returns are evidence about a process. Create a weekly or biweekly review with the research owner and one outbound representative. Group returns by the controlled taxonomy, inspect a small sample of accepted accounts as well, and choose one of four responses:

• Clarify the contract when recipients interpreted a packet field differently.
• Change the discovery or identity rule when the same wrong entity or ICP mismatch repeats.
• Change the source or freshness rule when evidence regularly fails review.
• Add an exclusion or controlling-system check when returned accounts are already engaged or otherwise unavailable.

Record the rule version and effective date. Do not overwrite history and then pretend the original packet used the new rule. A later reviewer needs to know which standard produced a past decision, especially when training a new team or comparing two pilots.

It is also useful to distinguish recipient disagreement from missing research. If two account owners reach different conclusions from a complete packet, the problem might be ICP interpretation or commercial strategy rather than data completeness. Escalate that decision to the person who owns the rule instead of quietly adding more fields to every handoff.

8. Audit the transition without claiming a system integration

This Guide does not require a CRM sync or sequence integration. A controlled handoff may be a shared Sheet view, a CSV export, or another team-approved transfer. The quality test is whether the receiving owner gets the packet, decision context, and return path without losing the original record—not whether every field moves automatically between tools.

Before a batch handoff, take five records across different states and have a recipient answer these questions without speaking to the researcher:

• Which entity is this, and which ICP rule admitted it?
• What exact source supports the material account claim, and when was it seen?
• Is the stated role a verified fact, a role-family hypothesis, or missing?
• Is contact research complete, pending, unsuccessful, or not requested?
• What action is allowed now, who owns it, and what feedback reason applies if the record is returned?

If a recipient needs to reopen several tabs to answer those questions, add a link or concise field to the packet. If the answer is actually unknown, retain that state. Inventing a completion signal to satisfy a spreadsheet check makes the handoff less trustworthy, not more efficient.

9. Choose metrics that reveal a broken boundary

Use a short measurement window and define the denominator before you calculate anything. For example, if 24 of 30 delivered packets receive an explicit outbound decision, the decision-completeness rate is 24 ÷ 30. That is not a benchmark and does not say whether the decisions were commercially good. It simply shows whether owners can use the handoff at all.

Pair it with reviewable measures:

• Evidence-complete rate: packets with every required evidence field divided by packets delivered.
• Structured-return rate: returned packets carrying a valid reason divided by returned packets.
• Repeat-return rate: accounts returned again after an upstream correction divided by corrected accounts resent.
• Time to explicit decision: elapsed time from handoff to accept, hold, or return; interpret alongside owner capacity rather than as an isolated score.

Avoid using meeting booked, reply, or revenue as a direct proof that the packet was good. Those outcomes have many intervening causes. The handoff contract is successful first when the next owner can make a bounded, accountable decision from preserved evidence.

10. Keep the handoff distinct from the outbound workflow

An outbound workflow determines messaging, channels, timing, and any controls for taking action. This Guide stops earlier. It produces an evidence packet and a controlled decision boundary. That distinction is intentional: it lets a team fix a vague or unreliable research handoff without implying that Leadbase runs campaigns, synchronises CRM authority, or decides who may be contacted.

11. Protect the packet from scope creep

As a handoff becomes popular, teams tend to add every useful-looking field. That makes it harder for an owner to see what matters and can expose more data than the immediate decision requires. Add a field only when you can answer all four questions: What decision does the recipient make with it? What source or state makes it trustworthy enough? Who updates it when it changes? What is the safe action when it is unknown?

Keep deeper research as a link, identifier, or follow-up task rather than copying it into every row. A concise packet with a clear evidence trail is more reviewable than a complete-looking profile with no distinction between material facts, hypotheses, and historical notes. Review the schema after a pilot and remove fields that did not change a recipient decision.

Release one versioned packet at a time

Name the packet version in the sheet or export. When the team changes a required field, feedback taxonomy, or acceptance rule, document the effective date and teach recipients the difference. Do not silently apply the new rule to old records. Versioning lets a team compare why one cohort was returned more often than another without blaming the recipient or claiming the underlying accounts changed.

12. Test data minimisation against the actual recipient

"More context" is not a sufficient reason to hand over a field. For every recipient role, ask: does this person need this value to decide the exact next action they are allowed to take? An account owner may need the source link, ICP reason, and unresolved policy state. A person resolving an entity may not need additional contact-research notes. Keep the view limited to the necessary purpose and point to the authorised research context for deeper review.

This is not legal advice and does not replace your own privacy or access rules. It is a practical quality check against a common waste: the packet becomes so broad that nobody can identify which fields actually justify an action. If a sensitive field does not change an immediate decision, it does not belong in the standard export simply because it exists in the working list.

13. Treat returns differently by error class

A return marked "wrong entity" needs different work from one marked "evidence too old." To keep feedback from disappearing into free text, assign each controlled reason an upstream owner and next check:

This mapping does not mean that every return must be resolved immediately. It ensures the problem returns to the right place. An outbound owner should not quietly repair an entity rule, and a research team should not decide a governing policy on its own.

14. Run a receipt test before the first larger batch

Choose ten records with deliberately different states: at least one accepted account, one account in review, one no-result in contact research, one uncertain entity case, and one account with a documented return. Ask two recipients to review the packet version independently. For every record they should mark: Can I identify the entity? Do I understand the inclusion reason and evidence? Do I know what is unknown? Do I know my allowed action? Do I know how to return it in a controlled way?

Do not only compare the number of accepted accounts. Check whether both recipients read the same material point from the packet. Different answers are not a failure of the people; they reveal a field, state definition, or instruction that is not yet clear enough. Apply that learning before using the schema version for a larger batch.

15. Preserve the chain from account to return

A practical handoff needs a reference that keeps the origin and return together: an account identifier, packet version, handoff date, and one controlled feedback reason are often enough. Do not make a new disconnected copy for every return that loses its evidence. Refer to the same working record, or retain an explicit relationship, so research can later see which source, rule, and decision put the account into the queue.

That chain is especially useful when an account returns after a correction. The team can see whether account facts, the rule, source conditions, or only the packet form changed. Without that distinction, repeated returns look like poor lead quality when the real failure is the handoff boundary.

Outbound gets the why, not only the who

The weakest moment in many data workflows is the export. Research produces a clean-looking list, but the reasons behind the rows—the source, the unresolved doubt, the rejection history, and the intended next action—are flattened or left behind. Sales then has to trust the file or repeat the research.

Leadbase keeps the account decision, evidence, research result, owner, and next action in one shared Sheet until the team deliberately releases the handoff. Sharing roles and Sheet history support review of the working record, while selected-row enrichment keeps focused research beside the accepted account instead of broadening every row.

A sales-ready account is not a company with contact data. It is an account whose reason, evidence, owner, and next action survive the handoff.

The Leadbase advantage starts upstream of the packet: it can find companies by meaning, research the criteria your team invented, qualify the accounts, and add the relevant contact path before Sales receives anything. The research workspace becomes the evidence packet for that list, so Sales gets both the right targets and the reason each one belongs.

Leadbase is not an outbound sequencer, territory router, consent system, or CRM system of record, and it does not enforce every downstream action. Use it when the expensive failure is a contextless handoff. Build the handoff Sheet and run a receipt test with the person who must work the result.

Handoff release checklist

• Account fit and contact availability are distinct fields.
• Every material claim has a source and observation date.
• Unknown and unresolved states remain visible.
• The next action has a named owner and boundary.
• Recipients have structured rejection reasons.
• Returns change the upstream rule, source, or exclusion list.