AI-ready data starts with knowing which customer is which

AI-ready for which job?

AI-ready data is data an AI application can use reliably for a defined task. In a customer workflow, that means finding the correct person, understanding their records and respecting the rules attached to those records. A clean spreadsheet is only part of the preparation.

Start with a specific question: could this system identify the customer behind an inquiry, find their current booking and show the relevant history to the right employee? That gives you something to test. It also narrows the first data project to the sources the workflow actually needs.

The checklist below follows the work we do when evaluating a business’s applications and bringing its data together. The shared-contact examples are illustrative; no client records appear here.

1. Inventory the sources and the APIs

List the CRM, booking platform, website forms, messaging tools and any spreadsheets used to fill their gaps. For each source, record the objects it owns, its stable IDs, the fields available through its API and whether the integration can write changes.

Check history as well as the current screen. An export may contain the latest customer status but omit the events that explain how it changed. Ask whether messages, canceled bookings, attachments and timestamps are available separately.

2. Match people without merging everyone they know

Customer matching, also called entity resolution, identifies records that refer to the same person or organization. AWS Entity Resolution supports rule-based and machine-learning approaches to matching records across sources. The tool you choose still needs matching criteria that fit your business.

A planner may arrange events for several customers. A household may share an email address. Two employees may use the office phone number. Treating any shared contact detail as proof of one identity can collapse different people into the same record.

Preserve the source records and store the evidence behind a proposed match. Separate a confirmed identity from a related person or company. Put uncertain cases in a review queue, then check the matching rules against a hand-reviewed sample before applying them more broadly.

Include both mistakes in that review: different people incorrectly merged, and one person still split across records. The cost of each mistake depends on what the connected workflow will do next.

3. Normalize fields and keep the right relationships

Normalize phone formats, date handling, status values and names while keeping the original values available. Document what each field means. “Active” in a marketing list may mean something different from “active” in a booking system.

A person can have several inquiries, bookings and conversations. Those objects need their own records and links. Copying the latest event date onto a customer field can hide an earlier booking that is still relevant.

Useful tags describe something the team can act on, with an understood source. Remove or isolate test tags and placeholders. Enrich records with verified information from available sources, and distinguish an observed fact from an inferred category. Do not invent missing customer details to fill the blanks.

4. Carry history and access rules with the data

Bringing records together should preserve the context that makes them usable. Keep location, owner, source timestamps and communication preferences attached to the relevant records. A shared customer identity can still have different histories and permissions in different parts of the business.

For a first release, test access with the actual roles that will use the application. A location manager, an account owner and an automated workflow may need different views and actions. Verify those differences in the resulting screens and API responses.

This is one reason AI integration work starts with a systems map. An agent’s access depends on the application you build around it.

5. Reconcile the import and try an update

Run a small import first. Compare source and destination counts, then inspect samples covering ordinary records and known exceptions. Follow the relationships: does the right booking belong to the right person, and does the original message remain accessible?

• A repeated import should not create duplicate people or events.
• A corrected source field should update the intended destination record.
• A failed import should leave a visible checkpoint for recovery.
• An uncertain customer match should stay reviewable.
• An update should respect the source system’s ownership and access rules.

Keep the checks with the integration. The data will change after launch, and a mapping that worked on the first export can fail when someone adds a new status or changes an intake form.

Start with one connected customer journey

You do not need to reorganize every system before shipping useful software. Choose a journey, identify the necessary records and prove that the connections hold. That prepared data can support the next product or workflow.

Our How We Work process puts data preparation before product integration. Where the existing applications prevent useful connections, we also evaluate what should stay and what should be rebuilt. We can review the systems behind your first use case.