CRM hygiene for teams using AI calling

CRM hygiene for AI calling comes down to five rules. Store every Indian number as +91 and ten digits, and compare numbers on the ten. Deduplicate on that number before anyone is dialled. Keep a list of statuses where each one means one thing. Tag every lead with where it came from. And keep "do not call" as its own record, separate from "not interested". An AI agent dials what the CRM says, at scale and without hesitating, so every error in the CRM becomes a call: to the wrong person, to the same person twice, or to someone who asked not to be called again.

One number format: +91 and ten digits

The same phone is written +91 98201 34567, 09820134567, 919820134567 and 9820134567 by four different people. Any system that matches only the spelling it was handed will treat those as four buyers.

Our rule is simple. For comparison, every Indian number is reduced to its last ten digits, which is the part that identifies the subscriber. For display, it is shown as +91 98201 34567. The carrier makes this unavoidable: in our own call logs the same handset appears as ten digits on an inbound call and with the country code on an outbound one.

The rule has to be the same everywhere a number is compared: the lead list, the suppression list, and any CRM you sync with. A CRM that matches leads only on the plain ten-digit number finds no record for any +91 form. Worse is a mismatch between the lead list and the do-not-call list, because a number the CRM recognises but the suppression list does not is a call placed to someone who asked not to be called.

Buyers abroad are the exception. Keep their full international number with its country code; our post on calling NRI home buyers covers them.

What spreadsheets do to phone numbers

Most leads reach a CRM through a spreadsheet at some point, and spreadsheets damage phone numbers in ways that are hard to see.

• Scientific notation. Open a file with 919876543210 in a General-format column and Excel can show it, and save it, as 9.19877E+11. That is lossy: only six of the twelve digits survive. Expand it and you get 919877000000, which looks like a real mobile number and belongs to someone else. Our import refuses these rows and asks for the file to be exported again with the phone column formatted as Text. Guessing would mean the agent rings a stranger.
• Formula wrappers. Excel sometimes writes a long number as ="9820134567" to protect it. A leading = is never meaningful in a phone column.
• Leftover apostrophes. An export that prefixed a value with an apostrophe to stop it being read as a formula leaves '+919820134567 behind, which nothing can dial.
• Invisible characters. A header copied from a web page can carry a non-breaking or zero-width space, so a column that looks exactly like "Phone" does not match "Phone".

Deduplicate before anyone is dialled

The same buyer arrives from Meta, from a portal and from a channel partner. Three records mean three calls in an afternoon, and a buyer who now thinks your project is spam.

• Within a file. Our import reports a phone number that appears twice in the same file, rather than quietly creating both rows.
• Across sources. Match on the ten-digit key. Keep one record, credit the source that brought the buyer first, and note the others on the lead.
• Names as given. Do not "fix" names automatically. Flipping "Mehta, Anjali" into "Anjali Mehta" looks tidy until the same rule turns "Sharma and Co, Pvt Ltd" into nonsense. Joining a First Name and a Last Name column is safe; reordering one name is not.
• One script for the columns people search. A name spoken in Hindi is often transcribed in Devanagari. That is the right name and the wrong alphabet for a lead list someone searches, sorts and exports, so we write names and localities in Latin script in those columns and keep the original words in the transcript. The same goes for budgets: "૪૦ લાખ" (40 lakh, in Gujarati numerals and script) in one row and "50 lakh" in the next cannot be sorted or compared, so both are stored as lakh in Latin script. A buyer who mixes Hindi and English in one sentence produces the same mix of scripts.

After any import, check what each column was mapped to, starting with a handful of rows. An earlier version of our import read a column titled just "Lead", which in some real-estate CRMs holds the enquiry's serial number, as the buyer's name. Every row imported with a four-digit number where the name should be. Bare "Lead" is no longer read as a name, but the general lesson stands: an import that looks as if it worked is not the same as one that did.

Statuses that mean one thing

Our dashboard uses nine statuses. Whatever list you use, each status should record one fact, and it should change what the dialler does.

• One status, one fact. Who owns the lead belongs in an assignee field. Whether a visit is booked belongs in a site-visit field. What happened on the last call belongs in a call outcome. A status that tries to carry all three ends up reading "Visit, Rahul, call back" and means nothing to a dialler.
• Qualified is defined in writing. Otherwise it means whatever the person updating it wants it to mean. See lead qualification and how to measure cost per qualified lead honestly.
• Imports do not guess. A portal export may have a "stage", "disposition" or "call status" column. Map its values onto your list; a value that does not match stays New rather than being guessed.
• A status change changes behaviour, whoever makes it. "Not interested" typed by a salesperson, written by the agent or set by a re-import must stop the calls the same way. Our follow-up cadence guide explains why that matters.

Tag every lead with its source

Without a source on every lead you cannot tell which portal is worth renewing, which campaign is producing buyers rather than form-fillers, or which channel partner sends people who visit.

Leads reach our dashboard tagged with where they arrived from, such as Meta Ads, an inbound call to the agent or a spreadsheet import. See integrations for the connections, and portal and Meta leads for how the sources differ.

One trap is worth naming. "CSV Import" says how a lead arrived, not where it came from. Before importing a portal export, add a Source column with the real origin, such as "99acres", "MagicBricks" or the channel partner's name. Our import reads a Source column and uses it instead of the default. Once set, keep the original source fixed and record later touches separately.

"Not interested" is not "Do not call"

These are two different records, and treating them as one fails in both directions.

• Not interested is a sales judgement about this project, now. The lead is kept. Follow-up calls stop. A person can reopen it when the buyer's situation changes, or when the buyer calls you.
• Do not call is a compliance record about the number, for good. It is checked before every dial, in every mode and every campaign, and it is never reopened from the sales side.

A refusal recorded only as a "Not interested" status is not a do-not-call record: a status is something a dialler consults, and a lead carrying it can come back round the queue and be rung again. So the two are kept separate, in both directions:

• "Stop calling me", "dobara call mat karna" (don't call again), "ફોન ના કરતા" (phone na karta: don't phone), "put me on DND": the number goes on the suppression list the moment it is said, the call ends, and it is never dialled again.
• "Not interested", "abhi nahi" (not now), "budget nahi hai" (there is no budget), "call me later", "my wife will decide": an ordinary objection, handled on the call. The lead is kept.

The second direction matters as much as the first. A rule that turns every "no" into a do-not-call entry would quietly delete a client's pipeline. Both are tested: opt-out phrasings in Gujarati, Hindi and English that must be suppressed, and ordinary refusals in the same languages that must not be.

There is also a third list. The national register, the NCPR, is where people record their DND preferences. BlackWolf's suppression list is not the NCPR, and scrubbing against the NCPR needs your own DLT access. See DND and NCPR explained and compliance.

"Not interested" can carry obligations of its own. The DPDP Act (PDF), opens in a new tab illustrates legitimate use with a person who asks a real-estate broker for help finding a flat to rent: once she says she no longer needs help, the broker "shall cease to process" her personal data. And under TRAI's September 2026 amendments (PDF), opens in a new tab, a relationship based on an enquiry holds only while it "has not been previously terminated by either party." Decide with your lawyer what you keep about a lead who said no, and why. Our DPDP Act glossary entry and DPDP guide for sales teams go further. This is not legal advice.

A weekly routine

• Export every number not in +91 and ten-digit form, and fix it.
• Run a duplicate report on the ten-digit key.
• List leads with no source, and find out where they came from.
• Review statuses changed by hand this week, with the reason for each.
• Check that numbers added to the suppression list this week are not sitting in any other tool that dials.
• Play back five leads marked Qualified and check them against your written definition.

This post is part of our operations series, which starts with sales follow-up cadence. For how the agent writes each call into the CRM, see AI calling for real estate.

What to do next

Run the duplicate report on the ten-digit key this week, before your next campaign goes out. It is the quickest way to see how much of your list is the same buyers twice.