Article summary
Handle South Korean 010 mobile phones with +82 normalization, source evidence, TXT quality checks and careful interpretation of WS Registration results.
A South Korea WhatsApp registration project often fails at the boundary between domestic 010 and international +82 10. Domestic notation retains the trunk zero; the international form after +82 does not. Even after correct normalization, a registration task says only whether a registration state was returned in that run. It does not prove recent activity, identity or permission to message.
Use a replayable rule for 010 conversion
| Source record | Candidate international form | Action |
|---|---|---|
| 010-1234-5678 | +82 10 1234 5678 | Transform when reliable Korea evidence exists |
| +82 10 1234 5678 | +82 10 1234 5678 | Remove separators only |
| 821012345678 | +82 10 1234 5678 | Normalize after confirming the country code |
| 1012345678 | Do not decide automatically | Quarantine when country evidence is absent |
Country is not inferred from length
Order country, customer selection, store source or a verified country field should precede pattern logic. The ITU’s Republic of Korea national numbering plan resource provides an external reference for +82 rules. It does not replace the organization’s evidence for why each record is Korean.
Run three layers of quality control
- Character layer: remove whitespace, hyphens, parentheses and stray characters.
- Country layer: reconcile +82, the domestic zero and country evidence.
- Record layer: deduplicate the task input, preserve contact_id mapping and isolate shared-number collisions.
The final TXT contains one phone per line and no customer name, order, address or support note.
Understand the WS Registration boundary
Standard WS Registration and WS Fast Registration center on phone and registration result. If the business needs the business-account field and WhatsApp mapped phone, evaluate WS High-Precision Registration rather than assuming a basic task returns them. AppShai accepts TXT and exports the corresponding Excel schema after completion.
Registered does not prove four things
- It does not prove that the CRM contact is the current account holder.
- It does not prove recent activity.
- It does not prove permission to receive marketing.
- It does not prove permanent validity or prevent number reassignment.
Store the observation with checked_at and keep permission, relationship and activity in separate fields.
A sample acceptance run is faster than repairing a full batch
Create a sample containing domestic 010, +82, a duplicate, a blank line and one deliberate anomaly. Reconcile row count, headers, missing values and exception handling before processing the full list. This is far easier to reverse than discovering after completion that every phone retained an extra trunk zero.
Resolve collisions during the Excel import
Load the exported workbook into staging and never overwrite phone_raw. If a normalized number is already attached to another contact_id, create mapping_conflict for accountable review. When a new result differs from an older one, retain both observations and let a dated view expose the current state. An opt-out always has priority.
When Activity is actually required
Choose WS Activity only when an approved question genuinely needs activity time or active days; Registration does not provide those conclusions. Quality in a +82 workflow does not mean forcing every row into registered or not registered. It means every transformation has evidence, every missing value has semantics, every observation has a date and every collision can stop automation.
