Prospect list schema

A prospect list should answer four questions: what the account is, who the contact is, why the record belongs in the list, and what action follows. Give each answer its own field so the record survives an import, a handoff, and a status change. Keep raw records, enriched contacts, accepted prospects, and messages sent separate.¹ This prevents list volume from being mistaken for usable coverage. Start with the account relationship, then add identity, provenance, activity, permission, and status around it.

Start with the record model

Decide how account and contact records relate before choosing columns.

Accounts are the organizations contacts belong to.² Give every contact an account relationship that can be inspected without reading notes. Use a stable account identifier across that relationship. The CRM Account ID is unique to the account and shared by every contact derived from that account.³

Decide whether your records use Leads, Contacts, or both, and define how Leads match Accounts.⁴ Also decide whether a contact can sit under more than one account. Keep that answer explicit in the schema so imports and routing follow the same rule.

Account fields

Use account fields to identify and group the organization. Keep personal details and activity in the contact layer.

At the account view, show the account name and a contact list containing each contact's name, title, email, and last interaction.⁵ Store the company or domain and a created timestamp when you need to trace where the record came from and when it entered the list.⁶

A change to the identifier between systems makes the contact relationship difficult to trust, even when the person fields look complete.

Contact fields

A contact record needs identity, a way to reach the person, and enough context to connect the person back to the account.

Store the contact's name, email address, title, and company.⁷ Keep a lead or contact identifier, created timestamp, and lifecycle stage timestamps when the list needs history across handoffs.⁶

For phone-based calling workflows, call lists can include leads, accounts, person accounts, and contacts, and they use the standard Phone field for those records.^{8, 9} Include an entity type when your workflow accepts more than one record type.

Preserve the outbound campaign Profile ID when a downstream process needs the customer profile associated with the contact being dialed.¹⁰ Treat that identifier as a relationship field, not a replacement for the contact's name, email, or phone.

Provenance and readiness

A list needs fields that explain why a record is present and how ready it is for use. Keep that context beside the identity fields so a reviewer can judge the record without guessing.

Capture the relationship, acquisition or consent path, segment, lifecycle stage, organization type, list age, and relevant sender maturity.¹¹ These fields distinguish a newly sourced record from one with an established relationship or a known permission path.

Define reporting terms before counting records. A contacted prospect is a record with at least one campaign send.¹² Keep that definition separate from enrichment, acceptance, reply, meeting, and other stages you choose to track.

Status and activity

Activity describes what happened. Status tells the workflow what to do with the record now, so status values should point to a clear next action.

Make status values match the sales process and change them as the process is refined.¹³ As the team builds and refines that process, it can update its status customizations.¹⁴ Keep each status usable as a routing instruction so two people reading it would take the same next step.

Store conversation result, prospect request, lead stage, next action, and scheduling outcome as separate fields. An illustrative disposition records those details separately, including when no meeting or callback has been agreed.¹⁵ This keeps a completed conversation from being mistaken for a scheduled next step.

Permission and suppression

Permission fields need to survive every export and handoff. Keep them independent from sales progression so a record can remain useful for reporting without becoming eligible for contact.

Include an Opted Out field on the prospect record.¹⁶ Keep it separate from Do Not Email, since those fields are decoupled.¹⁷ Track suppression status as active or inactive, and allow lead status to change when client interactions or campaign changes require it.¹⁸

Import and handoff checks

Run the schema through a field check before loading a list. This catches missing relationships, unclear mappings, and fields that could disappear during the handoff.

Review the Record Layout to make sure the data meets your requirements.¹⁹ During field mapping, map the account column in the file to Account.²⁰ When records merge, select which fields among the records need to be retained.²¹

Define the outbound payload separately from the storage schema. A documented outbound message configuration sends Id, FirstName, LastName, Company, Email, and Phone from the Lead record.²² Use that as a handoff checklist, then add any fields required for consent, status, provenance, or account matching.

What not to do

These schema decisions create cleanup work later, so make them before the list is loaded.

• Define what an account is and how contacts relate to it before the first import.²³
• Decide whether contacts can belong to multiple companies.²⁴
• If the sales motion regularly includes contacts spanning accounts, design the model around that before configuration.²⁵
• Use Lead Status for the sales representative's next action with a contact, not to identify the contact or record website activity.²⁶
• Avoid creating a new status value for every campaign or import. Lead statuses can grow quickly when new leads are imported or segmented by campaign.²⁷

Test the fields against an import and an outbound handoff before the list enters daily use.