What customer data needs before it can support AI

Test customer identifiers, event timing and outcome labels against a concrete service-follow-up example before using the data in an AI evaluation.

By Twin Global4 min read · Published 29 October 2026

An illustrative evaluation loop connects source evidence, testing, human review and the operating decision.

A customer profile can look complete on screen while still being unsuitable for a particular AI task. It may identify the person correctly but omit when a purchase happened, overwrite earlier service status or contain an outcome that was recorded after the decision the model is supposed to help make.

The preparation question is specific: could the business reconstruct the information available at that decision point, and later verify what happened? That is a different task from selecting an AI pilot or choosing a model.

Define the decision and the later outcome

“Use AI to understand customers” leaves too much unresolved. State who will use the result, when they will receive it and which later event will be used to judge it.

For a proposed service-follow-up model, the outcome might be a completed service visit within 30 days. That is measurable if the service records are reliable. It is also narrower than predicting whether a customer needs service: a customer may need help but never book, or may book and cancel.

Write down that difference before assembling the dataset. Otherwise a precise-looking score can answer a different question from the one the team believes it is using.

Keep the customer, account and event connected

A person can have several products, and an account can include more than one person. Preserve those relationships when preparing customer records. A shared phone number should not silently make every event belong to one individual.

For meaningful events, retain an identifier, source, event time and arrival time where available. An offline transaction may reach the platform later. Reports and model inputs need a way to distinguish the business sequence from the order in which records arrived.

Review corrections as well as duplicates. If a source only keeps the latest status, ask whether the earlier state can be recovered for the period being evaluated.

Illustrative readiness example: service follow-up

At the start of a week, an appliance-service team wants to prioritise eligible customers for a service invitation. The candidate dataset should describe what was known at that moment. It can then be linked to later completed visits for evaluation.

Record	Appropriate use	Readiness question
Product and customer reference	Link earlier product and service history.	Can the reference be traced consistently across the source systems?
Previous completed service date	An input if available before the invitation decision.	Does the date describe completion, booking or a later correction?
Visit completed after the decision	A later outcome for the agreed observation period.	Has the full 30-day period elapsed, and is the service record complete?
A later booking confirmation	Exclude from the earlier decision inputs.	Would this information really have been available when prioritising the customer?

Make labels explainable

A label is the outcome the model learns from or is evaluated against. Define the event and observation period, including cancellations, reversals and incomplete records. A missing visit is not a trustworthy negative example when the source was unavailable or the observation period is still open.

Have the operating team review a sample of positive, negative and uncertain cases. This often reveals differences between the meaning of a status in a database and the way staff describe the work.

Google’s machine-learning guidance highlights both information leaking from later outcomes into training inputs and differences between training data and the information available in production. For customer programmes, reconstructing the decision time is a practical way to investigate those problems.

Prepare permitted use and evaluation together

Agree which information is suitable for this task, who can access it and how long the working dataset is needed. Combining records for customer service does not automatically settle every proposed modelling or communication use.

Keep a simple operating baseline for comparison, such as an agreed service-age rule. Evaluate results on a later period and inspect important groups separately, including records from different sources or with incomplete histories. Record false alerts and the work required to review them.

The new dataset should support the actual decision process. A useful result includes an appropriate action, a responsible team and a way to identify cases the system cannot judge reliably.

Build the necessary foundation, then evaluate

PangoCDP can contribute connected customer information and audience context. An enterprise data platform may prepare the history and outcomes needed for evaluation. Neither makes a ready-made predictive service part of every customer-data implementation.

Twin can assess the source records and shape a focused data-and-AI scope around the task. If you are still choosing that task, begin with our first AI project guide; if the task is clear, bring a sample of the records and a precise definition of the outcome.

Sources and examples

Discuss the data your AI task needs