What Business Data Should Be Ready Before AI Connects to ERP or CRM?

When a company already has an ERP or CRM and wants to add AI, the first question should not be "Which AI model should we use?" It should be "Which business data will the AI read and use to produce a recommendation or action?" This distinction matters because an ERP or CRM may contain a large amount of information without that information being ready for AI. In projects we work on, we usually begin by mapping five major data groups: customers, products, transactions, inventory, and workflows.

Customer data is required for use cases such as sales assistants, lead scoring, customer segmentation, product recommendations, and repeat-purchase prediction. Providing only a name and phone number is rarely enough. A useful customer record may include customer_id, company name, contact person, WhatsApp number, email, region, customer type, assigned salesperson, purchase history, purchased product categories, payment terms, and customer status.

Product data also needs consistent identity. A distributor may have thousands of SKUs with internal codes, barcodes, brands, categories, product types, sizes, colors, purchasing units, selling units, suppliers, prices, and active status. If the ERP uses one SKU, the marketplace uses another, and sales staff refer to the product using a shortened name in WhatsApp, AI data preparation needs a mapping layer that identifies them as the same product.

Transaction data provides business context. AI should be able to distinguish quotations, sales orders, invoices, returns, payments, and cancelled transactions. If the company wants AI to identify customers likely to buy again, cancelled transactions or returned orders should not automatically be treated as completed sales.

That is the core of AI data preparation: the objective is not to feed the system as much information as possible. The objective is to provide the right information with clear identity, status, context, and relationships.

One common mistake is assuming that a company is AI-ready simply because its database contains hundreds of thousands or millions of transactions. Data volume can be valuable, but the quality of identities and relationships between records is often more important. If the same customer appears several times, products use different identifiers across systems, or transactions have unclear statuses, AI will analyze data that is already structurally unreliable.

Imagine a distributor has three customer records: "PT Maju Jaya", "PT Maju Jaya Indonesia", and "Maju Jaya". If all three belong to the same company but do not share a common customer_id, the customer's purchase history may be split into three separate profiles. An AI CRM system could then conclude that each customer has a relatively small transaction value, while the combined history actually represents one of the company's largest accounts.

Product identity creates similar problems. The same product might appear as "SPC Oak 4mm", "SPC Oak Brown 4 MM", and "Oak Brown SPC Flooring". A human who works with the catalog every day may immediately recognize the relationship. A system cannot safely assume they are identical without proper product mapping.

AI data preparation should therefore include a simple data dictionary. For each important field, define its meaning, data type, whether it is required, who owns it, when it is updated, and which system is the authoritative source. For example, selling prices may come from the ERP, customer profiles from the CRM, and marketplace transaction history from a marketplace connector.

We also recommend avoiding names as the primary identity. Customer and product names can change because of typing errors, branding changes, abbreviations, or different formatting. A stable internal ID is much safer for connecting tables and systems.

For AI connected to an ERP, transaction and inventory data are often among the most valuable sources of business insight. However, the data needs sufficient business context. If a business owner asks, "What products should I purchase next week?", AI cannot rely only on historical sales. It may need current inventory, open sales orders, outstanding purchase orders, suppliers, lead times, returns, and minimum stock levels.

Suppose a product sold 1,000 units last month. That does not automatically mean the company should purchase another 1,000 units. Perhaps 700 units came from a one-time project. Perhaps there was a major promotion. Or perhaps the product was out of stock for two weeks, meaning the recorded sales were actually below underlying demand.

AI data preparation for forecasting therefore needs information that helps distinguish normal patterns from exceptional events. Transaction records should ideally contain dates, customers, channels, products, quantities, prices, discounts, salespeople, warehouses, and transaction status. For B2B businesses, project information or customer type can provide additional context.

Inventory also needs clear definitions. A system may show 500 units physically on hand while 200 units are already reserved for sales orders. In that case, only 300 units may actually be available for sale. If AI reads only on-hand inventory, its sales or purchasing recommendations can be misleading.

Channel context is particularly important for Indonesian businesses. A company may receive orders through physical stores, sales representatives, its website, WhatsApp, Tokopedia, Shopee, TikTok Shop, or other marketplaces. If each channel is not mapped properly, AI may analyze customer and product behavior in isolated silos.

Many Indonesian companies conduct a significant part of their sales activity through WhatsApp, but much of that communication never reaches the CRM. The CRM may contain the final quotation or invoice while the conversation that explains the customer's intent remains inside a salesperson's personal or business chat.

This becomes a problem for AI CRM systems. For example, a customer contacts a salesperson through WhatsApp asking for pricing for 500 units of a particular product. The salesperson sends a quotation, the customer asks for a discount, and then the conversation stops for two weeks. If that context is not recorded in the CRM, AI has limited information for recommending a relevant follow-up.

AI data preparation in this situation does not mean sending every raw WhatsApp conversation to an AI model without controls. The company should determine which information is actually useful to the CRM: customer_id, inquiry time, requested product, quantity, customer requirement, related quotation, follow-up status, communication outcome, and next action.

When WhatsApp Business API or a WhatsApp gateway is integrated with the CRM, selected conversations can be associated with the correct customer and sales opportunity or ticket. AI can then summarize conversations, classify inquiries, draft follow-up messages, or identify leads that have not been followed up.

There is a trade-off. Retaining every conversation provides more context but increases storage requirements, privacy controls, filtering requirements, and governance responsibilities. For some use cases, storing structured summaries is considerably more efficient than providing the entire conversation history to the model.

The sales workflow must also be explicit. AI needs to understand the difference between a new lead, contacted, quotation sent, negotiation, won, lost, and follow-up. Without consistent definitions, AI recommendations become difficult to trust because the underlying business process is inconsistent.

We generally do not recommend giving an AI system unrestricted access to an entire ERP or CRM from the beginning. Start with one clearly defined use case, such as quotation drafting, WhatsApp customer service, product recommendations, sales follow-up, or inventory forecasting.

Take a limited sample of production data for the audit. For example, review 500 customers, 1,000 SKUs, and several months of transaction history. Do not rely only on data already cleaned by the IT team because that may hide the actual problems employees encounter in production. The purpose of the audit is to expose the conditions the AI system will really face.

Check for duplicates, missing values, inconsistent formats, orphaned records, invalid statuses, and data that cannot be traced to an authoritative source. Then classify each dataset as ready, needs cleaning, needs mapping, or unavailable.

For example, customer data may be 95% available but split between the CRM and sales spreadsheets. That is primarily a mapping and integration problem. If the company wants AI to predict repeat purchases but transaction dates are inconsistent and customer_id values do not exist, the problem is much deeper and concerns the underlying data model.

AI data preparation should also be driven by the use case rather than an ambition to clean the entire database at once. Cleaning millions of records before understanding which AI workflow will actually be deployed can consume significant time and budget without producing immediate business value.

Once the data is ready, define the system of record. The ERP may be the authoritative source for inventory and transactions. The CRM may own customer profiles and sales activities. A marketplace may remain the source for marketplace transactions. A WhatsApp gateway may become the source for selected customer conversations. AI should retrieve this information through controlled APIs or data pipelines.

The final step is permission design. An AI system that only provides inventory recommendations does not need permission to modify stock. An AI that prepares quotation drafts does not automatically need access to change the price list. An AI that creates invoice drafts does not necessarily need permission to post accounting transactions.

A staged approach makes the integration easier to test. If AI produces an incorrect recommendation, the team can determine whether the root cause is data quality, mapping, workflow logic, prompting, model behavior, or system integration. Without this separation, every failure tends to be blamed on "the AI," even when the actual problem is in the underlying database.