How to Create a CSV File for Outbound Sales in 2026

You're trying to create a CSV file because the list has to move somewhere real, probably into HubSpot, Salesforce, Pipedrive, or a sheet somebody else is already using. The problem is rarely the save step. The problem is that the CSV has to survive the importer on the other side, and most files break because nobody treated them like a contract with the downstream system.

Table of Contents

• Why Your Sales CSV Keeps Breaking Imports
• Choosing Delimiters, Encoding, and Headers
  • Start with the delimiter
  • Save the file as UTF-8
  • Keep headers simple and stable
• Building the File in a Spreadsheet
• Generating the File Programmatically in Python
• Cleaning, Deduping, and Verifying Before You Upload
  • Dedupe before the import
  • Verify the record formats
  • Check completeness and sample rows
• Mapping Fields to HubSpot, Salesforce, and Pipedrive
  • A practical comparison
• Pre-Import Checklist and Common Questions

Why Your Sales CSV Keeps Breaking Imports

An SDR exports a prospect list, uploads it, and the CRM rejects rows for a reason that looks annoyingly small. A title contains a comma. A name has an accent. The header row doesn't match the import wizard. That's the normal failure pattern, not an edge case.

CSV, or comma-separated values, is a plain-text format used to store tabular data, where each row is a record and each column is separated by a delimiter such as a comma, tab, or semicolon; users typically create a CSV by entering data in a text editor or spreadsheet and saving with a .csv extension (Adobe's CSV overview). That definition matters because a CSV is not a workbook, not a database, and not a forgiving export container. It's just rows, columns, and a very literal reader on the other end.

Practical rule: if the receiver can't infer your intent from headers, encoding, and separators, the file fails.

A clean way to think about this is to treat the CSV as a promise to the CRM. The delimiter says how fields are separated. The encoding says how characters should be read. The headers say what the columns mean. When any one of those shifts, the importer starts guessing, and guessing is where broken loads come from.

If you need a quick refresher on the file format itself before you touch the data, a tutorial for CSV beginners like this guide from CleanMyList helps anchor the basics without overcomplicating the workflow. In sales ops, though, the skill isn't opening a CSV. It's making one that another system can ingest without a cleanup project.

Choosing Delimiters, Encoding, and Headers

Start with the delimiter

Comma is the default, but the right delimiter depends on the data and the destination. If your fields themselves tend to contain commas, you either quote those fields or choose a safer delimiter for the workflow. The key is consistency. Mixed separators are what create the “looks fine in a text editor, fails in the importer” problem.

Save the file as UTF-8

Encoding is where accented names, umlauts, and non-Latin characters usually get mangled. UTF-8 is the safe choice because it keeps names readable instead of turning them into broken symbols or silent corruption. Public-sector CSV guidance recommends UTF-8 encoding for exactly this reason, along with one subject area, a single header row, one data type per column, simple headers, and one value per cell to avoid import errors (UK government CSV guidance).

Keep headers simple and stable

Use one header row only. Don't stack notes above it, don't add blank preambles, and don't rename columns halfway through a file series. A header row like email,first_name,last_name,company,title,linkedin_url is easy for humans and machines to read. If a title includes a comma, quote the field value, not the header. The header is the contract, and the row data is where quoting matters.

A practical decision matrix looks like this:

• Delimiter: comma by default, tab or semicolon when your dataset or regional format makes commas risky.
• Encoding: UTF-8, always, when names can include special characters.
• Headers: one row, simple names, one value per cell, no decorative text above the data.
• Quoting: wrap fields that contain the delimiter, especially titles and notes.

That combination keeps the file portable across spreadsheet tools and CRMs. It also keeps you from rebuilding the same list three times because the first export was technically a CSV but operationally useless.

Building the File in a Spreadsheet

Most outbound teams still start in Google Sheets or Excel, and that's fine if the sheet is disciplined. The file should look like a table, not a scratchpad. If a column mixes comments, secondary phone numbers, and company notes, you've already made the import harder than it needs to be.

For a canonical outbound list, I'd keep the first pass lean:

email	phone	first_name	last_name	company	title	linkedin_url	industry	employee_count

That shape gives you enough context for enrichment and routing without turning the sheet into a junk drawer. Keep one data type per column. Don't put freeform notes inside company, and don't paste multiple phone formats into phone because later validation becomes messy.

Practical rule: if a column can't be imported cleanly by itself, it doesn't belong in the first CSV.

Titles need extra care because they're full of commas and weird punctuation. VP, Sales is valid text, but it has to be quoted as a field value if you export from a spreadsheet. Phone numbers should be normalized before export so the same person doesn't appear as 415-555-1212, (415) 555-1212, and +14155551212 in three different rows. Consistency matters more than formatting preference.

If you want a simple way to keep bulk edits safer before export, safe bulk edits from a spreadsheet is a useful reference for teams that live in Sheets and need tighter control over data changes. The point isn't to make spreadsheets exciting. It's to make them less fragile.

When you export, use File, Download as, Comma-separated values (.csv) in Google Sheets or the equivalent CSV export in Excel. Choose CSV (Comma delimited) (.csv) specifically, because spreadsheet programs can otherwise keep workbook-specific formatting that doesn't survive the export (CSV export guidance). One extra gotcha, Google Sheets exports only the active sheet, so make sure the right tab is selected before you download.

Generating the File Programmatically in Python

If the source data already lives in a list, API response, or enrichment workflow, Python is cleaner than clicking through a spreadsheet. It gives you predictable quoting, repeatable output, and less room for somebody to accidentally sort the wrong column before export.

import csv

prospects = [
    {
        "email": "jane.doe@acme.com",
        "phone": "+14155551212",
        "first_name": "Jane",
        "last_name": "Doe",
        "company": "Acme Inc",
        "title": "VP, Sales",
        "linkedin_url": "https://www.linkedin.com/in/janedoe"
    },
    {
        "email": "michael.ross@northstar.com",
        "phone": "+442071234567",
        "first_name": "Michael",
        "last_name": "Ross",
        "company": "Northstar",
        "title": "Head of Revenue"
    }
]

fields = ["email", "phone", "first_name", "last_name", "company", "title", "linkedin_url"]

with open("prospects.csv", "w", newline="", encoding="utf-8") as f:
    writer = csv.DictWriter(f, fieldnames=fields, quoting=csv.QUOTE_MINIMAL)
    writer.writeheader()
    writer.writerows(prospects)

That pattern is boring in the best way. Every row is a dictionary, every key maps to a column, and utf-8 keeps non-English characters intact. The built-in CSV module also handles quoting any field that needs it, which is exactly what you want when commas show up inside titles or notes.

For technically sound CSV creation, plain-text entry or programmatic generation is the safer path, and you should quote any field containing commas and save with UTF-8 encoding when non-English characters are present to avoid delimiter collisions and character corruption (NCF India CSV creation guidance).

If your source is already a DataFrame, pandas.DataFrame.to_csv() is the heavier option. It's fine when the data pipeline already lives in Pandas, but the standard library version is enough for most outbound list builds. The main win here isn't speed. It's reproducibility. The same input produces the same file every time, which is exactly what you want when the CSV is feeding a CRM import.

Cleaning, Deduping, and Verifying Before You Upload

The CSV isn't ready just because it opens. It's ready when the rows are clean enough that the next system won't choke on them. In outbound, that means deduping, validating, and checking whether the file still makes sense after cleaning.

Dedupe before the import

Start with email, because that's the most common unique key in sales workflows. If phone is the primary identifier in your stack, dedupe on phone too. Duplicate rows don't just clutter the CRM, they distort activity counts and make outreach sequences harder to trust.

Verify the record formats

A phone number should be normalized to a single format, ideally E.164, so the same contact doesn't arrive in multiple local styles. Emails need a syntax check and an MX check before upload, because the goal is to stop bad data before it starts bouncing through the sending stack. A practical scrubbing reference like EmailScout's email scrubbing guide is useful if your team wants a lightweight way to think about validation before load.

Check completeness and sample rows

Many teams get lazy. They clean the obvious junk, then ship the first file they can open. A more reliable habit is to sample a few records after cleanup, confirm the critical columns are still populated, and make sure the file still aligns with the import schema.

The first exported file is not always the one downstream systems can safely ingest.

A quick validation pass should also include header consistency, row counts, and field counts before handoff. That line of checking is especially useful when the CSV was assembled from multiple sources or enriched in stages. If you're piping data through a waterfall process, the output should already be shaped for the next tool. Pipecorn's waterfall enrichment guide is a relevant example of that mindset.

Mapping Fields to HubSpot, Salesforce, and Pipedrive

Different CRMs can ingest the same CSV shape, but they don't all interpret it the same way. The easiest files to live with are the ones that already resemble what the destination expects. That's why a disciplined header row beats a clever one.

A practical comparison

Outbound CSV header mapping across major CRMs	HubSpot	Salesforce	Pipedrive
email	Matches contacts by email by default	Common field in the import wizard	Used for person records
first_name	Standard contact field	Standard field mapping	Standard person field
last_name	Standard contact field	Standard field mapping	Standard person field
company	Useful for company association	Maps through import mapping	Can merge on company name
title	Standard contact field	Standard field mapping	Standard person field
linkedin_url	Often mapped as a custom field	Usually custom mapped	Often custom mapped
phone	Standard contact field	Standard field mapping	Standard person field

HubSpot is generally forgiving with extra columns, but the safest route is still to keep the file tidy and focused. Salesforce's import flow is more deliberate, it asks for a mapping step, so clear headers save time. Pipedrive works well when the person and organization data are cleanly separated, and company naming consistency matters when the importer tries to connect records.

A clean output shape pays off. If the CSV already contains verified email addresses and mobile numbers in the columns the CRM expects, the mapping step becomes routine instead of a debugging session. That's also why systems that produce cleaned outbound data can save a lot of manual rework. Pipecorn's Sales Navigator to HubSpot integration flow follows that same logic by keeping the output aligned to the columns downstream tools already know how to read.

The takeaway is simple. Don't build a CSV for the person exporting it. Build it for the importer, then keep the header names stable across runs. That's how you turn CSV creation from a one-off file task into a repeatable sales ops process.

Pre-Import Checklist and Common Questions

Before upload, run this list once:

• UTF-8 confirmed.
• One header row.
• E.164 phones.
• Deduped on email.
• Sample row reviewed.

A few questions come up every time the file is close but not quite ready. Do you include the header row when re-uploading after an error? Yes, if the importer expects headers. What if the CSV is too large for the CRM upload flow? Split it into smaller chunks or use a workflow built for larger loads. What if the import fails without warning? Check the sample rows, header consistency, and field counts first, then try the same file in a more transparent import path.

If you want the next list to need less scrubbing, pair your CSV workflow with a real-time enrichment source before the export step. Pipecorn's upload list workflow fits naturally into that handoff.

---

If you want cleaner outbound CSVs without babysitting sheets all day, Pipecorn helps sales teams source verified emails and mobile numbers, then push them into the tools they already use. Visit Pipecorn if you want your next prospect list to arrive in CRM-ready shape instead of becoming an import cleanup project.