How to Launch a Cold Email Campaign From a CSV
A CSV can contain the right prospects and still fail at launch. A column can map to the wrong variable, a missing first name can render an empty greeting, a suppressed contact can return through a merged source, or a three-step sequence can exceed the capacity plan. We avoid those failures by treating launch as a controlled data handoff rather than an upload button.
This guide takes a B2B CSV through schema review, hygiene, verification, segmentation, column mapping, sequence setup, test sends and a 50-row pilot. We will keep product data fields separate from workflow fields, use explicit fallbacks and define stop conditions before volume increases.
Define “launch-ready”
Launch-ready does not mean “the import succeeded.” It means:
- the account and contact match the intended ICP;
- the row passed cleaning and suppression rules;
- verification status matches campaign policy;
- the row belongs to one documented segment;
- every message variable has a safe fallback;
- the sender infrastructure passed the readiness controls;
- test messages rendered correctly;
- the pilot owner knows when to pause.
The import is one step inside that contract.
Use a stable CSV schema
The confirmed Getlead B2B export columns are:
First Name
Last Name
Job Title
Email
Company
Website
LinkedIn URL
Industry
Employee Count
Verification Status
We preserve those names when possible. We add campaign fields separately:
Segment ID
Buying Role
Priority Tier
Pain Hypothesis
Proof Asset
CTA Variant
Suppression Status
Verification Timestamp
Source
Account Owner
Campaign Owner
Next Action
The second group is our operational schema, not the native Getlead export.
Minimum required fields
At minimum, the campaign system needs:
- a valid email field;
- enough identity/context for the chosen message;
- a segment identifier;
- a suppression decision;
- an actionable verification decision.
If the message uses First Name or Company, those fields become required for that campaign. “Optional in the database” does not mean “safe to reference without a fallback.”
Step 1: preserve and inspect the source
We store the raw export with:
- source;
- date;
- owner;
- filters;
- row count;
- verification date or status definition;
- intended campaign.
We inspect delimiter, encoding, header row and unexpected line breaks. Spreadsheet software can change leading characters, dates and non-ASCII text; a test parse should happen before the production import.
We never place API keys, passwords, suppression-list explanations or unrelated sensitive notes inside the campaign CSV.
Step 2: run hygiene before verification
Use the cold email list cleaning workflow and B2B Lead List Cleaner to:
- trim and normalize values;
- validate basic email syntax;
- remove exact and normalized duplicates;
- flag role-based mailboxes;
- flag disposable domains;
- identify missing company/title context;
- preserve excluded and review files.
Cleaning does not perform SMTP verification. It reduces avoidable noise before the verification step.
Suppression matching follows normalization. A contact previously opted out should not re-enter because the new file uses uppercase email or extra whitespace.
Step 3: apply the verification policy
For the approved standard campaign, Verified Emails Only keeps addresses that passed Getlead's real-time SMTP check at verification time and excludes catch-all and risky results. This reduces hard-bounce risk before outreach.
It does not guarantee future delivery. A mailbox can close, a receiving server can change behavior, or a message can be rejected for another reason. We retain the status and, where available, the timestamp.
Decision table:
| Status | Import decision | |---|---| | Verified under approved policy | Eligible after all other checks | | Catch-all | Hold out of the standard verified campaign | | Risky | Hold out | | Invalid | Exclude | | Unknown/not checked | Verify before import |
Verification never overrides suppression or relevance.
Step 4: assign one campaign segment
Use the B2B lead segmentation guide. Every live row receives one Segment ID.
Our segment contract states:
- inclusion and exclusion;
- buying role;
- shared pain;
- proof;
- CTA;
- required variables;
- fallback behavior;
- sequence;
- campaign owner.
A contact may fit more than one research hypothesis, but it must not enter overlapping live campaigns. We choose a primary campaign and suppress it from the others while active.
Step 5: map columns explicitly
We create a mapping table:
| CSV column | Destination | Required | Transform | Missing behavior |
|---|---|---:|---|---|
| Email | recipient email | Yes | trim/lowercase | Reject row |
| First Name | first_name | If used | trim/review case | Hold or remove entire greeting |
| Company | company | If used | preserve approved display name | Hold row |
| Job Title | CRM/context | No | none | Review if persona-dependent |
| Segment ID | campaign assignment | Yes | controlled values | Reject row |
| Verification Status | eligibility | Yes | controlled mapping | Hold unknown |
We do not map a column because its name looks similar. Status might mean CRM stage, verification or suppression. Ambiguous fields require human confirmation.
Fail-fast validation
Before import:
- Email column exists exactly once.
- Headers are unique.
- No formula or script-like cell is interpreted as executable content.
- Required variables are populated.
- Segment IDs match existing campaign contracts.
- Verification values match the allowed set.
- Suppression status is complete.
- Duplicate email policy is applied.
- Row count matches the expected eligible count.
If validation fails, the import stops with a row-level error file.
Step 6: create variables and safe fallbacks
A fallback must create a natural complete sentence. It should not merely replace a missing word.
Bad:
Hi {{first_name}},
I noticed {{trigger}} at {{company}}.
If first_name or trigger is missing, the sentence breaks or invents context.
Better:
Greeting block:
- if First Name exists: "Hi {{first_name}},"
- otherwise: hold the row for this campaign
Trigger block:
- if human-reviewed Trigger exists: render the entire trigger sentence
- otherwise: render the segment-level problem sentence
We avoid forced title case for names that may contain prefixes, particles or intentional capitalization. A reviewer checks transformed values.
Step 7: build the sequence
The sequence document records:
- step number;
- delay;
- allowed sending days/window;
- subject;
- body;
- segment;
- CTA;
- stop on reply;
- stop on opt-out;
- stop on permanent bounce;
- owner.
Follow-ups are part of capacity. A 50-row, three-step pilot schedules up to 150 campaign sends before stop rules. Use the Cold Email Volume Planner and inbox capacity guide.
We do not add follow-ups only to increase send count. Each step needs a distinct useful reason: clarify the problem, provide proof, answer a likely objection or close the loop.
Step 8: complete sender readiness
Before any test:
- SPF is configured/aligned;
- DKIM signing works;
- DMARC is configured;
- TLS and connection are checked;
- sender identity is accurate;
- required business/postal identity is present;
- opt-out is functional;
- replies have an owner;
- bounce/complaint monitoring exists;
- suppression updates automatically or has a controlled process.
Use the Campaign Readiness Checker. A critical blocker produces “Do Not Launch” regardless of score. If authentication answers are self-reported, use the email deliverability test for a live check.
Step 9: run test sends
We test to controlled inboxes that the team owns. We cover:
- each segment;
- every sequence step;
- long and short names;
- long company names;
- non-ASCII characters;
- each conditional block;
- link rendering;
- plain-text representation;
- reply routing;
- opt-out path;
- mobile and desktop layouts.
Test data is clearly synthetic. We do not use a real prospect as a rendering test.
Rendering QA
- Sender name and address are correct.
- Subject has no raw variable.
- Greeting is natural.
- No
undefined,null, braces or empty punctuation appears. - Claims match source evidence.
- Links use the intended destination and tracking policy.
- Signature and sender identity are complete.
- Opt-out works.
- Reply reaches the assigned owner.
If any test fails, we fix the template or mapping and rerun the entire affected path.
Step 10: launch a 50-row pilot
Fifty rows are an operating convention for a controlled first batch, not a universal benchmark or statistical guarantee. It is small enough to review manually and large enough to exercise mapping, scheduling, stop rules and reply operations.
We select the pilot across:
- all title variants;
- all accepted employee-count bands;
- every variable/fallback path;
- more than one source if the segment has multiple sources;
- the full approved verification status;
- no unresolved suppression.
Pilot record
Campaign ID:
Segment ID:
CSV version:
Template version:
Sequence version:
Sender group:
Pilot rows:
Start time:
Owner:
Stop conditions:
Review time:
Decision:
Stop conditions
We pause if:
- suppression or opt-out fails;
- sender identity is wrong;
- variables render incorrectly;
- unexpected duplicate sending occurs;
- a critical authentication issue appears;
- reply routing fails;
- bounce/complaint behavior requires investigation;
- the sampled recipients clearly do not match the segment.
We do not wait for a fixed threshold when there is a critical control failure.
Review the pilot by layer
After the pilot, we do not look at a single aggregate dashboard and decide “the campaign worked.”
Data layer
- Were companies and people correct?
- Did title/buying-role rules hold?
- Were any duplicates or suppressed contacts present?
- Was verification status interpreted correctly?
Rendering layer
- Did every variable and fallback render?
- Were links, signature and opt-out correct?
- Did plain text remain readable?
Infrastructure layer
- Did senders remain connected and authenticated?
- Did monitoring capture bounce/complaint events?
- Was volume consistent with the capacity plan?
Message layer
- Did replies show that the problem was relevant?
- Did recipients misunderstand the offer or CTA?
- Did negative replies reveal a segment exclusion?
Operations layer
- Were replies routed on time?
- Did stop rules remove contacts from later steps?
- Could the team explain every campaign state?
We change the smallest layer supported by evidence. A poor segment should not be “fixed” by raising volume. A broken variable should not trigger a new ICP.
Scale in controlled batches
If the pilot passes, we define the next batch, not an unlimited launch. Batch size follows:
- available inbox/domain capacity;
- reply-handling capacity;
- segment size;
- verification recency;
- confidence in the campaign hypothesis;
- monitoring quality.
Each batch records CSV, template, sequence and sender-group versions. If a metric changes, we can identify what changed with it.
Reserve inbox capacity remains reserve. Scaling should not consume every spare unit merely because the first batch ran.
Handle imports that partially fail
A robust import produces:
- accepted rows;
- rejected rows;
- warning rows;
- row numbers;
- machine-readable error codes;
- human-readable resolution.
Example codes:
| Code | Action |
|---|---|
| MISSING_EMAIL | Correct source or exclude |
| INVALID_EMAIL_SYNTAX | Exclude/correct |
| UNKNOWN_VERIFICATION | Verify |
| UNMAPPED_SEGMENT | Assign valid Segment ID |
| MISSING_REQUIRED_VARIABLE | Enrich or hold |
| SUPPRESSED | Do not import |
| DUPLICATE_ACTIVE_CONTACT | Keep out of overlapping campaign |
We do not correct errors inside an undocumented copy. We repair the controlled source, increment its version and rerun validation.
Protect against spreadsheet and CSV hazards
CSV is plain data, but spreadsheet applications may interpret cells beginning with =, +, - or @ as formulas. Import/export systems should sanitize or safely quote untrusted values when a file may be opened in spreadsheet software. We test delimiters, quotes, embedded newlines and UTF-8 text.
We also avoid exposing suppression reasons or internal notes to people who only need the campaign file. The launch dataset contains the minimum operational fields.
Compliance and sender identity
This guide is operational, not legal advice. Requirements vary by market and context. The campaign team must use current official regulator guidance and legal counsel.
At minimum, we do not use deceptive sender/routing information, we accurately identify the sender, we include required address/identity information, we provide the required opt-out path and we honor applicable opt-outs through suppression. The FTC's CAN-SPAM compliance guide says US commercial email has no automatic business-to-business exception.
The readiness checker links to current official requirements. Evergreen copy should avoid freezing volatile provider thresholds without a maintained source and review date.
Launch metrics that preserve learning
By segment and batch, record:
- eligible rows;
- accepted/rejected imports;
- attempted sends;
- later steps stopped by reply/opt-out/bounce;
- bounce categories;
- complaints;
- opt-outs;
- positive/neutral/negative replies;
- qualified next steps;
- response handling time;
- data errors found after launch.
Opens are not a sufficient success measure. Tracking may be incomplete and an open does not establish relevance.
We annotate every material change. Without versioned data and campaign state, a higher reply count cannot be attributed responsibly.
Common launch mistakes
Uploading before cleaning
We spend verification and QA effort on duplicates and malformed rows.
Mapping by column name alone
Ambiguous fields such as Status can create dangerous misclassification.
Using a blank fallback
Empty variables create broken or misleading messages. Fallbacks must operate at the sentence/block level.
Importing overlapping campaigns
One recipient can receive inconsistent messages. Assign one primary campaign and enforce cross-campaign suppression.
Treating “Verified” as permanent
Verification is time-bound and does not replace current monitoring.
Skipping the pilot
A small mapping error scales into every row and sequence step.
Scaling from opens
We prioritize operational correctness, replies and qualified outcomes.
Ignoring follow-up capacity
Every scheduled step contributes to the send plan.
Final launch checklist
- [ ] Raw source and working version are preserved.
- [ ] Ten native Getlead columns are mapped correctly.
- [ ] Workflow fields are explicitly separate.
- [ ] Cleaning and duplicate rules completed.
- [ ] Suppression completed.
- [ ] Verification decision applied.
- [ ] One Segment ID assigned per live contact.
- [ ] Required variables and full-block fallbacks tested.
- [ ] Sequence and stop rules documented.
- [ ] Capacity includes every scheduled step.
- [ ] Authentication and sender identity checked.
- [ ] Opt-out path tested.
- [ ] Reply and incident owners assigned.
- [ ] Test sends cover every rendering path.
- [ ] 50-row pilot has stop conditions.
- [ ] Batch review and version record are ready.
Continue through the hub
If the CSV is not clean, return to JTBD-04. If the audience is too broad, use JTBD-05. If volume does not fit the infrastructure, use JTBD-06 and the Volume Planner. If there are more eligible prospects than operational capacity, apply JTBD-08 prioritization.
Frequently asked questions
Can we import a CSV before verification?
We should not place unknown records into the standard verified campaign. Clean first, verify unique candidates, then apply the documented eligibility policy.
Why use a 50-row pilot?
It is a controllable operating batch that can be manually reviewed. It is not a universal benchmark or guarantee of statistical confidence.
What happens if First Name is missing?
If the template requires it, hold the row or use a complete alternative greeting block approved during QA. Never render an empty variable.
Should one CSV contain several segments?
It can, but Segment ID must be explicit and each contact must enter only the assigned campaign. Separate exports can reduce operational error.
Do verified addresses ever bounce?
Future delivery is not guaranteed. The status reflects the real-time SMTP result at verification time; mailbox and server conditions can change.
When can we scale beyond the pilot?
After data, rendering, infrastructure, message and reply operations pass review and the next batch fits the documented capacity.
Handoff record for Sales, RevOps and Growth
The launch is complete only when the operating teams share the same source of truth. We create a handoff record that does not expose unnecessary personal data:
Campaign and segment IDs
Source CSV version
Eligible, held and excluded row counts
Verification policy and run date
Suppression run owner and date
Template and sequence versions
Sender group and capacity plan
Pilot start/review dates
Reply routing owner
Incident owner
Dashboard/report location
Approved next-batch limit
Sales receives the definition of a qualified reply and the account context required for follow-up. RevOps receives stable IDs, status mappings and CRM ownership rules. Growth receives the campaign hypothesis and the exact variables that changed. Deliverability or infrastructure owners receive sender groups, monitoring and pause authority.
We also define state transitions:
Eligible → Imported → Scheduled → Sent
↓
Replied / Opted out / Bounced / Paused
Every terminal state stops inappropriate later steps. A positive reply should not remain scheduled. An opt-out must enter suppression. A permanent bounce should not be retried through another campaign. A manually paused record keeps its reason and owner.
When a CSV is re-imported, stable contact and campaign identifiers prevent the same person from being treated as new. If the platform cannot prove idempotent import behavior, operations should use a pre-import duplicate check against active and historical campaigns.
The handoff review asks one final question: “Could another trained operator reproduce this launch from the record?” If the answer is no, the workflow still depends on undocumented knowledge. We complete the missing mapping, policy or ownership before the next batch.
This discipline improves SEO content quality and product operations at the same time. The guide does not end at generic advice; it gives the reader an observable completed state, and every connected page advances a specific next job through crawlable links.