Getting your leads into the system

The quality of your list controls the quality of your calling programme. The import process is a pipeline with five stages, and it does not guess. Each rejected row comes back with a reason and an instruction. An upload alone does not start calls. Any invited member of your team can bring in a list, not only an admin.

The five stages

Each list moves through the same pipeline, in this order:

1. Upload — your spreadsheet goes into secure file storage.
2. Match the columns — you confirm which column holds which field.
3. The validation — the platform checks each row and creates nothing.
4. The reject report — each failed row comes back with a reason.
5. Commit — the only step that creates leads.

Stage one: upload

You export your list as a spreadsheet and upload it. The file can be up to 64 megabytes. That size holds more than 100,000 rows. The file goes from your browser directly into secure file storage. The file does not go through the platform's own servers. Thus a large file does not use the capacity of the platform.

Before the next stage starts, the platform asks the storage service if the full file is there. An incomplete file does not enter the pipeline.

The upload keeps running if you leave the page. A line under the Upload leads menu entry shows its live progress — the upload percentage, then each later stage — so you can check on it from any screen, and a reload finds it again in progress rather than starting over.

Stage two: match the columns

The platform reads your column headings and proposes a match for each column. The platform compares each heading with a curated list of synonyms. For example, "Company", "DBA" and "Merchant Name" all identify the business name. The platform does not make approximate matches. A wrong automatic match is worse than no match, because a field with wrong data looks correct.

You must confirm the proposed matches before the next stage starts. Each lead must have four fields:

• the business name;
• a contact name;
• a phone number;
• which state or territory the lead is in, because state law sets the hours a lead can legally be called. The wizard requires a State column, a ZIP code column, or both; it refuses to proceed with neither.

A business address is not required on its own. It still matters: when a file has no state column, the platform reads the state from the end of the address instead. When neither a state column nor a usable address names the state, the platform finds it from the ZIP code. A ZIP code that straddles two states applies both states' calling hours, to be safe. A lead that none of these three sources can place cannot be matched to a legal calling jurisdiction.

Each list must also have its consent evidence: where and when the person gave consent, and the source of the list itself. Each file column can feed exactly one platform field — the platform never lets two fields share one column. The commit button stays off, with a plain list of what is still missing, until every required field has a match and the list itself has a name.

The platform remembers your matches once an upload reaches stage five, and proposes the same matches on your next upload of a similarly-shaped file. It does not remember a match from an upload you only tried and then cancelled.

Stage three: the validation

The platform then checks each row and creates nothing. This stage finds these problems:

• phone numbers — the platform converts each number to the strict international format, or rejects it;
• missing required fields;
• missing consent evidence;
• addresses that the platform cannot match to a legal calling jurisdiction;
• a state your campaigns never call, read from the state, address, or ZIP code;
• numbers that are already on suppression or do-not-call records;
• duplicates.

The platform reports all the problems on a row at the same time, not one problem for each upload attempt. For example, you do not repair a phone number, upload again, and then find that the same row has no consent date.

Stage four: the reject report

Each row that fails the validation comes back in a report that you can download. The report has one line for each problem. Each line has one of two labels:

• Fixable. These problems are: an unmatched column, an empty required field, a phone number in an unusable format, missing consent evidence, or an unknown calling jurisdiction. Repair these rows in your own records. Then upload only these rows again.
• Gone. These rows are: duplicates of leads already in the system, numbers on a suppression or do-not-call record, rows in a state your campaigns never call (labelled “state we don't call”), or rows that your own rules exclude. No action is necessary. Do not upload these rows again.

You can also download the report as a single, ready-to-fix spreadsheet: the exact file you uploaded, row for row, with one column added that states what to do with each row. You can repair it in place and upload the same file straight back.

For a single fixable row, you do not need to download or upload anything: you can correct its fields directly in the report on screen, and the platform treats your correction as a small upload of its own. You can undo a correction, which restores the row's earlier values.

In a real test with a 100,000-row file, approximately 11,000 rows came back in this report. A first import that rejects a tenth of the list is normal, not a failure. This result shows that the checks operate correctly.

Stage five: commit

Commit is the only step in the full pipeline that creates leads. Three separate protections guard the commit step against double clicks and retries. If you press the button two times, the platform creates each lead only one time. Commit also works in batches on a large file. If something interrupts it partway through, the platform picks up from the last completed batch rather than starting over, so an interruption never creates a duplicate lead and never silently drops a row.

Before the platform commits a new upload, the client admin must confirm, in a box they tick, that the client has consent on record for every lead in the file, then type their own full name as a signature. Only the client admin can sign. A member or a staff member who prepares the upload sees the text and a link to send to the admin. The button to confirm stays disabled until both are done. The platform keeps that typed name on the batch's own record, permanently, alongside who confirmed it and when.

Commit is also the moment the platform screens every new number against the do-not-call registers, once, for the batch. A second report — the scrub outcome report — then shows how many numbers that screening removed, and why:

• a federal do-not-call registration;
• a state do-not-call registration;
• a known litigator;
• a number reassigned to a different person;
• an invalid number.

This is a separate count from the reject report. The reject report shows what the upload itself refused, before a lead exists. The scrub outcome report shows what compliance screening removed after a lead was created, so a client's row count never drops silently between the two.

New leads do not get calls immediately. The leads wait in the queue until a campaign's release plan admits them at a pace the platform can sustain. The commit step starts no calls.