Bulk BAND Number Checker: CSV Upload and Result Export Guide

A Naver BAND list is a channel list, not a contact list. It answers one question per row: is this number likely reachable on BAND, or does this person live on another app? In the Korean market that question decides campaign routing — BAND-heavy audiences respond in BAND communities, and sending them down a channel they do not use wastes the row twice: once in spend, once in goodwill.

The CSV is where that split becomes visible and permanent. This guide covers how to prepare the file, what the export actually contains, how to read the slices, and the routing and re-check habits that keep the list useful past the first campaign. The tool behind it is the BAND Number Checker.

Quick answer

Each row of the CSV should hold one phone number plus a record ID that ties it back to your source. Run the bulk check and export. The export splits rows into likely-on-BAND, valid-but-not-on-BAND, invalid, and unknown. Read the on-BAND slice as your campaign list, the valid-but-not-on-BAND slice as your fallback list for other channels, and treat invalid as repair work and unknown as a retry queue.

Preparing the CSV

The upload wants as little ceremony as possible: a phone column and an ID column are enough. But Korean-market files have three preparation details that decide whether the results come back clean:

1. Normalize numbers to E.164 before upload

Korean mobile numbers are commonly written as 010-1234-5678 domestically. That local format is fine for humans and ambiguous for machines — some source systems drop the leading zero, some prefix it with +82, some prefix it with 82 without the plus. Before upload, normalize to full international format: +821012345678. If your source data mixes formats, normalize in the spreadsheet first; every mixed-format row is a row the checker has to guess about, and guessing is where avoidable "unknown" results come from.

2. Keep a record ID per row

record_id — whatever your source calls it: customer key, form submission ID, CRM row number. It is the only thing that joins the export back to the source after the check. Without it you get an answer per number and no way to act on it in context. Keep it as text; leading zeros in IDs are data, not noise.

3. Do not pre-filter the list

Common instinct says "delete the obvious junk first." Resist it. Rows that look like junk to a spreadsheet (duplicates, odd formats, old entries) are exactly what the check exists to classify, and deleting them beforehand destroys the evidence. Duplicates in particular are worth keeping: the same number appearing under two record IDs is a data-quality finding about your source, not noise.

What the export contains

Each row comes back with the original inputs plus the check result:

Reading the export: a worked example

Say a K-commerce team checks 8,400 numbers ahead of a group-buy launch. The export comes back something like 63% likely on BAND, 24% valid but not on BAND, 9% invalid, 4% unknown. (These figures are illustrative, not a verified performance figure — your split depends entirely on your list.)

What each slice means operationally:

• Likely on BAND (63%) — the campaign list. These rows go into the BAND community workflow: group-buy announcements, seller updates, community posts.
• Valid but not on BAND (24%) — the fallback list. The numbers are real; these people just live on KakaoTalk, SMS, or elsewhere. Do not delete them. They route to whatever channel they do use, which is usually a list you already have.
• Invalid (9%) — repair work. Format-broken or dead rows. Fix at the source where the record has an owner; suppress where it does not.
• Unknown (4%) — the retry queue. No result this round. Retry after a few days before deciding anything; a single check is a sample, not a verdict.

The 24% fallback slice is where the money hides. Teams that read only the on-BAND rows treat a quarter of their reachable audience as waste, then wonder why the next campaign underperforms. The check did not delete those people — the export is what makes them visible.

Routing the export

Re-check cadence

Channel presence is a moving target — people install and delete apps, change numbers, migrate between platforms. The working cadence for BAND lists is quarterly, plus a fresh check before any major campaign. The checked_at column is what turns two exports into a trend: a segment that was 63% on BAND in spring and 51% by autumn is telling you something about your audience that no single export can.

Mistakes to avoid

• Treating "valid" as "on BAND." Validity and channel presence are different answers. The channel signal is the entire point of this check — a valid number you cannot reach on BAND belongs in the fallback list, not the campaign.
• Deleting the not-on-BAND rows. They are the fallback list. Deleting them throws away a quarter of the audience in a typical split.
• Deciding on unknowns. Unknown is a queue, not a dead end. Retry before you conclude anything.
• Treating the export as permanent. Presence drifts. Quarterly re-checks and pre-campaign checks keep the routing honest.

Making the CSV work beyond one campaign

The export format is deliberately boring so it slots into the rest of your stack: join on record_id to your CRM, filter on on_band for the community workflow, and diff checked_at snapshots to watch drift. Teams that keep every export rather than overwriting it get a second artifact for free: a history of how their audience's channel mix has moved, which is exactly the input the next quarter's channel budget conversation needs.

For the single-number version of this question, how to check if a number is on BAND covers the one-off workflow. For the full step-by-step of the bulk tool, see How to Use BAND Number Checker.

FAQ

Why is the on-BAND signal the point of the check?

Because campaigns route on it. A validity check alone cannot tell you which app a person uses; the on-BAND split is what turns a raw number list into two usable work lists.

What number format should I upload?

E.164, e.g. +821012345678 for Korean mobiles. Normalizing before upload removes the most common source of avoidable unknowns.

How often should I re-check?

The base rhythm is quarterly, plus before any major campaign. Presence on any app drifts as people change devices and habits.

Is the export safe to join back to my CRM?

Yes — results come back keyed to your record_id, so the join is a standard spreadsheet or database operation with no cleanup.

What's the move for unknown rows?

Hold them in a retry queue and re-run after a few days. Unknown means no answer this round, not a bad number.

Related ZelNum pages

• How to Use BAND Number Checker for Bulk List Checks has the full step-by-step workflow.
• How to Check If a Number Is on BAND for single-number lookups.
• BAND Number Checker — the bulk tool this guide covers.