IOSOR

IOSOR Learn

Bulk lookup campaign CSV hygiene: normalize, dedupe, and budget before send

A bulk-lookup CSV must normalize to E.164, dedupe, respect stale line-type cache, and cap budget before the campaign send. Finance and ops share the same columns.

Marketing wants a list. Finance sees a streak of lookup debits that do not match the SMS sent afterwards. Bulk lookup is not pouring a spreadsheet into the API. Hygiene comes before spend: normalize to E.164, dedupe, respect a stale line-type cache, and cap the wallet. Teams that skip hygiene treat dead numbers as delivery accidents, duplicate rows as “coverage,” and an old mobile tag as routing truth.

IOSOR packages lookup beside messaging on one white-label prepaid ledger. Catalog live means the check is ready; in setup is not a production gate you cache around. Near USD 1,000+ monthly, preventable-spend samples and lookup→send correlation enter commercial review. Recon before send: lookup reconnaissance before send. Single lookup: lookup before you send. Stale cache: stale lookup cache and line-type.

CSV columns finance and ops both need

Finance and ops must open the same CSV and read the same story. Minimum columns: normalized E.164, raw input, lookup timestamp, line type, cache hit or fresh check, amount debited, send decision (send / skip / re-check), related campaign or batch id. A “mobile” tag without a timestamp is opinion, not evidence. A lookup row without a send decision is a receipt, not a control.

Column Who uses it If it is missing
E.164 Ops and finance Duplicate spend, sends that do not match
looked-up-at Ops Unknown whether the cache is stale
Send decision Finance Lookup and blast cannot be reconciled

E.164 and dedupe before lookup spend

Normalize and dedupe before lookup money runs. The same line written +1…, 001…, and local format debits three times. Normalize to E.164, dedupe on that number, then call lookup live. Garbage rows (too short, letters, obvious test strings) drop at import — they are not queried as “unknown.” Ops owns the normalization rule; finance owns the incident definition when a duplicate row still debits.

Stale line-type cache risk

A cached line type is a routing signal with a timestamp, not a tattoo. Yesterday’s mobile can be a VoIP range today. Stale cache sends OTP into a dead range or adds friction to the customer who ported yesterday. You still pay the lookup row and the wasted segment. TTL is a product rule, not a database taste. Do not cache “unknown” as mobile.

Budget caps and export cadence

Budget caps belong to the batch, not to “we will reconcile later.” Set a row cap and an amount cap per lookup run; export cadence (daily or at batch close) sits before the blast, not as a month-end surprise.

Red flags

  • Bulk lookup without normalization
  • Same E.164 debited twice because of format variants
  • Stale “mobile” treated as routing truth
  • Unknown cached as mobile
  • CSV with no row or amount cap
  • Lookup reconciled to send only at month-end
  • Hygiene promised while the channel is in setup
  • Client errors that name upstream brands

Start with IOSOR

Take last week’s campaign CSV. Normalize every row to E.164, drop garbage, dedupe on the normalized number, then run lookup once. Cap the batch by row count and prepaid amount before the blast. Export the same file finance and ops will open: line type, cache hit, debit, send-or-skip decision.

IOSOR takeaway

Do: hygiene before lookup money. Format variants of one line are one debit. A cached line type has a timestamp; stale mobile is not routing truth.

Don't: pour the spreadsheet into the API and reconcile at month-end. Duplicate rows are not coverage. Unknown cached as mobile is a prepaid leak.

Was this guide helpful?

Related guides