On the record, as it is filled
Phone numbers get checked and formatted as you type, before anyone saves.
Clean
Know which phone numbers actually work
Your CRM stores whatever was typed in. It cannot tell you if a number actually connects. Verification checks it and saves the result on the record.
What changes once phone numbers are checked
Before Plauti
- Agents dial numbers that were never valid to begin with.
- Numbers arrive in a dozen formats, with or without country codes.
- Nothing on the record says whether a number was ever checked.
WithPlauti
- Bad numbers get flagged before anyone dials.
- Every number lands in the format you choose, automatically.
- The result and the check date sit in fields you own.
What we check
Each check saves the result, a standardized version of the number, and the date it ran.
Phone numbers
Checks the country code and the number itself, then puts it into one consistent format.
Records you already have
Run a job over the records already in your CRM. Filter which ones, and schedule it to repeat.
Where verification runs
Batch jobs over existing records
Filter the record set, pick the numbers to check, then let auto-process handle the outcome, fixed where it can be, flagged where it can't.
Status, value and date on every record
Results land in fields you choose, one per check. "Is this number reachable, and when did we last check?" becomes a question the record can answer on its own.
Reporting with the tools you already have
The outputs are ordinary fields, so coverage and error-rate dashboards live in your CRM's own report builder, no separate tool, no second data store.
Your automations, and forms
Verification runs inside your own automations, and the same rules apply to web forms and portals, before that number ever becomes a record.
Does it work the way you need it to?
The four things admins check before running this on real data.
Scope and permissions
You choose which records and fields to check, and which checks run on each. Your existing profiles, permission sets, and sharing rules apply as they are.
- Works on standard and custom record types.
- Results go into fields you own.
- Separate access for running jobs and checking single records.
What leaves your CRM
Only the field being checked goes to a specialist partner. The result comes back and is written to the record.
- No bulk export, no copy of your CRM held outside it.
- Phone numbers stay in the region you pick.
What a check costs
One credit per phone number checked.
- Same cost however the record came in.
- Checking a number again costs again.
- Use the validation date to decide when.
Running it at volume
Jobs work through your existing records in batches, and can repeat on a schedule.
- Large runs take time, so plan them outside busy hours.
- Keep them clear of heavy integration windows.
- Users running jobs need API access switched on.
Frequently asked questions
Isn't this what a validation rule already does?
No. A validation rule checks that a field is filled in and looks roughly right. It cannot tell you whether a number actually dials. Verification checks that, on new records and existing ones.
What exactly gets checked?
The country code and the number itself, standardized into the format you choose.
Does our data leave the CRM?
Only the phone number being checked goes to a specialist partner for the check itself; the result is written straight back to the record.
Can it check the numbers already in our database?
Yes, batch jobs run over existing records, filtered however you choose, and can repeat on a schedule.
What does a check cost?
One credit per phone number checked, regardless of how the record came in.
Try it on one record type first
Walk through it in a product tour with nothing to install, or book a demo and we'll show you how it fits your setup.