Blog / Tutorial
Why your SMS campaign failed: the phone number format problem
You uploaded 3,000 contacts, the dashboard said the import succeeded, and 1,100 messages never arrived. The provider's support page talks about carrier filtering and you start wondering whether you got flagged as spam.
Usually it is much more boring than that. The numbers were never routable.
What a provider actually needs
E.164 format. A plus, the country code, then the subscriber number, with nothing else. +14155550100. No spaces, no parentheses, no leading zero from the local dialling convention, no dashes.
Your phone book almost certainly does not look like that. People save numbers the way they would dial them locally: 0401 234 567 in Australia, 07700 900123 in the UK, (415) 555-0100 in the US. All of those are correct for dialling and useless for an API.
The leading zero problem
This one catches almost everyone with an international list. In most countries the local format starts with a trunk prefix, usually 0, which you drop when you add the country code. 07700 900123 becomes +447700900123, not +4407700900123. Paste the second version into Twilio and you get an invalid number error, or worse, a successful queue and a silent failure.
Doing this by hand across six countries in a spreadsheet is where afternoons go to die. The transformation is different per country and you have to know which country each number belongs to before you can apply it.
Why the upload said it worked
Most platforms validate shape at send time, not upload time. The CSV parsed fine, so the import reported success. The rejection happens later, per message, and often lands in a log you never open. Twilio in particular behaves this way, which is why people assume the problem is deliverability rather than data.
Fix it at the source
The cleanest fix is exporting in E.164 to begin with, so the file is correct before it reaches anyone. That requires something that knows each number's country, which means reading the number rather than guessing from your own locale. We go deeper on this in the E.164 explainer, and the same logic applies when formatting numbers for a CRM.
Pluck runs each number through libphonenumber on the device, works out the country, and writes the E.164 version into the export. Nothing to find and replace afterwards.
Spreadsheets quietly destroy phone numbers
Open a CSV of phone numbers in Excel and watch +447700900123 become 4.47701E+11, or a leading zero vanish because the column got typed as a number. The file still looks fine until you scroll.
If you must open the export, import it as text rather than double-clicking, and set every phone column to Text before Excel guesses. Or avoid the round trip and upload the export directly.
Extensions, WhatsApp numbers and the rest
Entries like +1 415 555 0100 ext. 22 parse as invalid and fail. So do numbers saved with a note in the field, which is more common than you would think in a business phone book.
A parser catches these before export and flags them. A spreadsheet silently passes them to your provider, which silently fails to deliver them.
Validate, do not just reformat
Reformatting assumes the number is real. Validation checks it against the numbering plan for its country, so a seven-digit mobile in a country that uses nine digits gets caught. libphonenumber, the library Google maintains for exactly this, is what sits behind most good implementations.
Get Pluck for iPhone
Pluck does the steps in this guide on your iPhone, with no server, no account, and no analytics. Group your contacts by country, find duplicates the iOS tool misses, and export to CSV, Excel, TXT, or vCard.