Why AI readiness depends on how customer data moves

AI readiness starts with customer data. An AI system needs relevant information in time to support a decision. It also needs the results of customer interactions to flow back into the shared data environment. When exposing one useful customer attribute takes months, model capability is only part of the constraint.

The September MarTech Conference panel “Built for yesterday: Why your data architecture can’t keep up with AI” brought together Koertni Adams, head of content and product marketing at MessageGears; Jacqueline Freedman, CEO and founder of Monarch Advisory Partners; Mike Maynard, chairman of Napier Partnership Limited; and moderator Kevin Haag, senior vice president of data strategy at Qualify Digital. Their comments focus the architecture decision on four questions: how quickly data arrives, whether required context is accessible, whether outcomes flow back into shared systems, and whether the organization can maintain the resulting architecture.

AI readiness starts upstream of the AI tool

AI can accelerate campaign planning and content generation, while execution still depends on access to behavioral data, purchase history, service interactions, and other customer information. Adams described cases in which useful customer information remained difficult to activate, tying AI execution to the architecture that supplies its context.

Freedman warned, “A new shiny tool doesn’t always fix broken issues that are outside of it.” Her point puts the use case before the product category. Executives first need to identify what an AI system must know to make a useful decision or generate an appropriate interaction. Those requirements reveal the data and architecture needed to support it.

Stale data makes marketing reactive

Adams set a demanding threshold for data freshness: “If your data is an hour or more old, by default your execution’s always going to be reactive.” This is Adams’s assessment rather than an independently established industry benchmark. Adams works at MessageGears, a marketing technology company with a commercial interest in how companies design and operate customer-data infrastructure.

Her threshold gives executives a testable question. Consider a customer event that must pass through ingestion, transformation, synchronization, and activation before it can affect an interaction. If that process introduces an hour of delay, the action uses an earlier state of the customer. The useful metric is the end-to-end time between the original event and when a marketing system can act on it.

That distinction changes how leaders diagnose a missed trigger or poorly timed campaign. The problem can appear in an activation platform even when the delay arose earlier, as data was collected, processed, or transferred. Before approving a platform migration, leaders should locate the delay in the information flow and test whether it matters for the intended use case.

Access to context can be harder than generating the campaign

Adams described a case in which activating a single new customer data point could require a dedicated data-science sprint, a new custom integration, and complex SQL queries. She characterized the request as becoming a multi-month project. If AI accelerates campaign creation while a required attribute still takes months to activate, the data dependency sets the pace.

Customer context can include behavioral signals, purchases, and service interactions. Adams summarized the dependency as: “Your AI’s only as strong as the information that it has.” Because Adams’s employer has a commercial stake in customer-data architecture, this is a vendor perspective rather than an independent benchmark.

Maynard applied the context problem to B2B marketing, arguing that engagement can involve complex buying committees. He also argued that data volume is a poor objective by itself. In his example, a signal such as how long a buyer plans to keep a vehicle can be more useful than dozens of lower-value behavioral measures.

The executive task is to identify information that materially changes a decision and make it available when the decision occurs. Freedman recommended testing an AI initiative against a business problem or an existing process and considering whether board pressure is driving adoption. Maynard put the concern this way: “Just throwing AI at it for AI’s sake is a waste of time.”

AI needs a feedback loop

Data also has to travel back after activation. A feedback loop is the return path through which the outcome of an interaction becomes input for later analysis and decisions. Adams described campaign responses that fail to reach a central warehouse when systems and records remain disconnected.

When those outcomes remain inside downstream applications, teams can work from different records of customer activity. Marketing may see campaign interactions in its activation systems while BI and data-science teams work from a central environment without those events. The architecture test is bidirectional: required context must reach the point of action, and relevant outcomes must return to the shared data environment.

Composable architecture is one option

A composable architecture uses modular components that organizations can select and replace independently. Freedman favors this approach and framed the choice as: “Do you want a best-in-class stack or do you want a movable monolith?” Her position reflects an architecture preference rather than a universal rule.

Maynard offered a different consideration for smaller B2B organizations. He argued that they often lack the engineering capacity to operate and maintain dozens of integrations between point solutions. In his framing, an all-in-one suite with “good enough” capabilities can be a rational choice when the alternative creates an integration burden the organization cannot sustain.

The trade-off is organizational as well as technical. A modular stack requires people to implement, monitor, change, and repair its connections, while a suite can reduce some of that integration work. Executives should weigh the value of component choice against the capacity required to keep information moving reliably.

Freedman also warned that changing the architecture cannot repair a flawed process: “AI cannot fix your bad wiring. It will just make bad processes move really, really fast and go really, really wrong really quickly.” Her warning shifts attention from software selection to ownership, workflows, and decision rules. Those operating questions matter before automation expands the speed or scale of execution.

Diagnose the information flow before choosing the architecture

Freedman recommended a detailed data audit that identifies repositories containing customer information, establishes who owns them, and determines whether coherent single-customer views exist. She also advised leaders to walk through their own customer journey from initial signup through post-purchase support and see the touchpoints firsthand.

Adams recommended beginning with a targeted AI campaign rather than “boiling the ocean,” then testing, refining, and optimizing it before pursuing an enterprise-wide transformation. A bounded use case gives leaders a concrete setting in which to measure latency, identify inaccessible attributes, trace broken return paths, and examine operating demands.

Maynard recommended staying focused on customer needs and the data required to serve them. For each AI use case, executives can ask what information is required, how fresh and complete it must be, how resulting activity will return to the shared data environment, and whether the organization can sustain the architecture that enables those flows. Those answers provide the basis for choosing a composable stack, an integrated suite, or changes to the existing environment.

Key highlights

• Start AI readiness upstream: AI execution depends on timely access to behavioral, purchase and service data. Define the business use case and the customer context it requires before selecting AI tools.
• Measure end-to-end data latency: Track the time from a customer event to the point where a marketing system can act on it. When an interaction arrives too late, locate the delay across ingestion, transformation, synchronization and activation before changing platforms.
• Prioritize decision-critical context: A few customer attributes that materially change a decision can matter more than large volumes of lower-value data. Data owners should identify these attributes and reduce the time required to make them available.
• Build the feedback loop: Campaign and interaction outcomes need a reliable path back into the shared data environment. Architecture owners should verify that activation systems both receive relevant customer context and return resulting activity.
• Match architecture to operating capacity: Composable stacks offer component choice but require resources to maintain integrations; integrated suites can reduce that burden. Technology leaders should choose an approach their organization can operate reliably.
• Diagnose information flows first: Audit customer-data repositories, ownership, latency and return paths around a bounded AI use case. Use those findings to determine whether the existing environment needs targeted changes or a broader architecture shift.