Article summary
An auditable Viber number-check CRM workflow covering TXT preparation, Excel field mapping, exceptions, acceptance, and rollback.
Importing Viber number-check results into a CRM is not a copy-and-paste exercise. A reliable workflow defines the task first, matches records through stable keys, writes check outputs into dedicated fields, and preserves a reversible import batch. Duplicate formats, shared phones, and missing values then become visible exceptions instead of silent damage to customer history.
This guide is for operations, sales support, and CRM administrators using the current file workflow: upload TXT and export Excel after the task. It does not assume a direct Viber-checking API.
Direct answer: Build a mapping table with CRM ID plus normalized phone, write Viber outputs only to dedicated fields, preserve source and permission, and save before/after values with a rollback batch.
Define the destination: registration, activity, or demographic fields
Viber Registration, Activity, and Demographic checks are different tasks. Registration returns phone and registration status. Activity may return phone, active days, mid, and offline time. Demographic checking has a separate and broader field set.
Start with the business question. If support only needs a registration signal, collecting broader fields “for later” adds interpretation and retention obligations without improving the current decision.
| Business question | Evidence required | Role of this workflow |
|---|---|---|
| Is the phone registered on Viber? | Registration result and date | Update channel status |
| How should activity be recorded? | Activity fields under one definition | Create a point-in-time snapshot |
| May the team contact the person? | Form, order, conversation, opt-out | This workflow does not create permission |
| Which lead is higher priority? | Inquiry, order, observed interaction | Check fields are supporting evidence only |
Use three working tables before touching the customer master
| Object | Ready state | Exception action |
|---|---|---|
| Source table | CRM ID, raw phone, source, permission | Missing ID or source goes to exceptions |
| Mapping table | Raw and normalized phones remain traceable | One-to-many matches need review |
| Import table | Only join key and approved Viber fields | Remove unrelated personal fields |
| Rollback table | Old value, new value, import batch | No bulk overwrite without it |
The mapping table is the control point. Phone-only matching is ambiguous when a contact has several numbers, a phone is shared, or records are duplicated. CRM ID provides a path back to the intended object.
Eight steps from Viber TXT to CRM
- Step 1: Freeze the source snapshot
Record query, export date, and owner. - Step 2: Normalize phone numbers
Verify country code and deduplicate while preserving raw values. - Step 3: Create TXT
Place one number per line with no header or extra columns. - Step 4: Run a sample
Validate accepted rows, Excel columns, and blanks. - Step 5: Run the production task
Record task ID, service, operator, and date. - Step 6: Map fields explicitly
Map every export column to a dedicated CRM field. - Step 7: Preview the import
Count inserts, updates, skips, conflicts, and blanks. - Step 8: Commit and sample
Compare CRM, Excel, and source; retain rollback data.
AppShai tasks accept UTF-8 TXT with one phone number per line; Excel is the completed task’s export. Do not place names, email addresses, companies, notes, or a header in TXT, and do not submit CSV or XLSX as the upload file.
Example Viber field map
| Export field | Meaning | Recommended destination | Does not establish |
|---|---|---|---|
| Phone | Task input/result key | viber_checked_phone | Contact name |
| Registration status | Registration field | viber_registered | Marketing consent |
| Active days | Activity field | viber_active_days | Online now |
| mid | Viber task field | viber_mid | CRM customer ID |
| Offline time | Activity field | viber_offline_at | Last customer reply |
Demographic-task fields need a separate governance review. Avoid generic fields such as status or activity that can overwrite evidence from another channel.
Investigate five common import failures
| Failure symptom | Likely cause | Investigation order |
|---|---|---|
| Excel has fewer rows than unique TXT numbers | Rejected format, blank, or task exception | Review accepted rows and exceptions |
| One phone matches several CRM records | Shared phone or duplicate customer | Resolve with CRM ID and source |
| mid is blank | Not returned or not applicable | Keep unknown; do not fabricate |
| Dates become text or shift timezone | Wrong import type | Use ISO format and fixed timezone |
| New blank overwrites old result | Update rule too broad | Update only on explicit return |
Keep an unexplained blank or missing row as unknown or pending review. Do not fill gaps with “no,” “not registered,” or zero merely to complete a report. Link the raw TXT, exported Excel, and exception file through the same task ID.
Acceptance tests for a CRM import
| Acceptance measure | Method | Purpose |
|---|---|---|
| Match coverage | Matched records ÷ valid result records | Find key defects |
| Conflict count | Keys linked to several records | Estimate review workload |
| Blank preservation | Blanks not converted to no/zero | Protect semantics |
| Rollback coverage | Updates with old value and batch ÷ all updates | Control change risk |
| Sample consistency | Cell-by-cell sample against Excel | Detect mapping errors |
These measures evaluate pipeline quality, not campaign success. Replies, qualified inquiries, opt-outs, and complaints belong to the downstream communication measurement.
Design access, retention, and rollback
Raw TXT and Excel can contain identifiable phone numbers. Limit access, set retention, and log who ran which task for which purpose. Remove intermediate files when the business purpose and retention rule no longer justify them.
| Data layer | Owner | Must preserve | Must not overwrite |
|---|---|---|---|
| Source list | Business owner | Source, purpose, permission, CRM ID | Check result |
| Normalized file | Data operator | Raw phone, normalized phone, exception reason | Source record |
| Task snapshot | Task operator | Task ID, date, service, input/output counts | Previous result |
| CRM import | System admin | Field dictionary, import batch, rollback file | Permission and lifecycle stage |
Final pre-import checklist
- Task matches the business question.
- TXT has one phone per line and no extra data.
- Excel columns match the current service definition.
- CRM uses dedicated Viber fields.
- Conflicts and blanks route to exceptions.
- Rollback was created and sample-tested.
When a task is justified, review current fields on the AppShai Viber Number Checker. A file workflow may look less glamorous than a real-time API, but it can be easier to audit, replay, and reverse.
Frequently asked questions
Can Excel overwrite the CRM phone field?
It should not. The phone is a join key and source record. Use a mapping table and incremental dedicated Viber fields instead of replacing the raw number.
Can Viber Activity become the last customer interaction?
No. A check returns supported activity signals. Customer interaction comes from sales or support conversations; keep the two fields and dates separate.
Can a team automate without an API?
Yes. It can automate controlled file templates, mapping, validation, and import logs internally. Do not describe that internal process as an undocumented AppShai Viber-checking API.
