Your Contacts Are Your Caller ID: How We Rebuilt Contact Importing

For an AI receptionist, your contact list isn't an address book. It's the memory that lets the AI greet a returning customer by name, pull up their history, and route them like someone who matters, all in the two seconds between the first ring and the answer. That recognition hinges on one humble thing: the phone number, stored exactly right.

We rebuilt contact importing in District AI from the ground up. Here's what we found, what shipped, and where we're headed.

The problem: imports that looked fine and weren't

We ran a real import of a real address book, 335 contacts from Outlook, and then audited what actually landed in the database. The result: 44 of the 335 numbers, about 13%, were stored in a form that could never match an incoming call.

The failures were mundane, which is exactly why they're dangerous:

• Local numbers without a country code. "416-555-0142" is obvious to a human. To caller-ID matching, it isn't +14165550142, so it isn't anybody.
• Office extensions welded into the number. "(416) 555-0142 x442" was being stored as a fifteen-digit number that dials nothing.
• International prefixes. A UK number saved as "00 44 7700 900123" needs translating to +447700900123 before it means anything.

None of these produced an error. The contacts imported "successfully" and sat there, unmatchable. Your address book is full of numbers like these, everyone's is, because humans write phone numbers for humans.

What shipped: preview first, repair automatically, write nothing blind

Importing now works the way it always should have:

1. Connect and fetch, live. Outlook and Google connect with one click and read your contacts in real time. There's no cached copy going stale.
2. Preview everything before anything is written. Every contact appears in a review table with a status: ready, repaired, duplicate, or invalid. You see exactly what will happen before it happens.
3. Repair, don't guess. Extensions are split off and kept visible. International prefixes are normalized. Local North American numbers get their country code, flagged in amber so you can confirm the assumption. And when a number genuinely can't be resolved, we reject it and show you, rather than storing something that looks like data and behaves like noise.
4. Confirm, then import. You choose the rows. Duplicates, both against your existing contacts and within the file itself, are excluded automatically. A summary tells you exactly what was imported and what was skipped, and why.

This same flow now backs all four import sources: Outlook, Google Contacts, Apple contacts (via vCard export from your iPhone or iCloud), and CSV, which keeps its flexible column mapping for whatever spreadsheet your last system exported.

Where this goes next

Being honest about what today's version is: one-way, on-demand import. That's the right foundation, but it's a foundation. The direction from here:

• Bi-directional sync. When your AI receptionist captures a new caller or enriches an existing contact, that update should flow back to the system you live in, not sit in ours.
• More sources. The import pipeline is built so a new source is a small addition, not a rebuild.
• CRMs. Salesforce and HubSpot for teams that run on them, and just as importantly the field-service platforms our customers actually live in. Same rule there as everywhere: preview first, repair before writing, and never let a bad phone number through quietly.

We'll ship those the same way we shipped this: against real data, audited after the fact, and honest about the failure rate before we called it done.

If you've ever imported contacts somewhere and wondered why the system doesn't recognize people it supposedly knows, the answer is probably in that 13%. It was in ours.