Bad Data In, Bad Decisions Out: How SMEs Should Prepare Their Data for AI and Automation

An SME can buy a capable AI tool and still receive poor results. It can build a technically correct automation and still move the wrong information. The problem is often not the model or workflow. It is the data underneath it.

Customer names appear three different ways. Product codes have changed without a mapping. Required fields are blank. One spreadsheet says an order is complete while another says it is pending. Important decisions are recorded only inside email or WhatsApp. Nobody knows which file is authoritative.

People compensate for these problems through memory and judgement. An experienced employee recognises that “ABC Pte Ltd”, “A.B.C.” and a particular telephone number refer to the same customer. Software does not reliably make that connection unless the business defines it.

AI can sometimes infer what messy data means, but inference is not governance. Automation can move information faster, but speed makes inconsistency travel faster too.

Preparing data does not require an expensive enterprise data programme. It requires a business to decide what information matters, where the trusted version lives, who owns its quality and how errors will be corrected.

Data readiness is a business question

Teams sometimes treat data cleaning as a technical task to complete immediately before implementation. That is too late.

Most data problems reflect unresolved business questions:

• What exactly counts as an active customer?
• When is an enquiry considered qualified?
• Which product code should be used after a catalogue change?
• Who may change a delivery address?
• Which system owns payment status?
• How long should a closed record be retained?

A consultant or software vendor can help structure these questions. The answers must come from accountable business owners.

IMDA’s AI for Enterprise Impact Playbook includes data and governance as a core readiness dimension alongside strategy, workforce, deployment and value creation. This is important: data preparation is not a housekeeping exercise separate from AI strategy. It determines which use cases are feasible and trustworthy.

The six dimensions of usable business data

Before connecting data to AI or automation, assess six dimensions.

1. Purpose

Know why each important field is collected and how it will be used. “We may need it someday” is not a sufficient design principle, especially when the field contains personal data.

Purpose helps determine the necessary accuracy, access and retention. A telephone number used for a one-time delivery has a different lifecycle from a contact number used for an ongoing service relationship.

2. Accuracy

The data should reflect reality closely enough for the decision or action being made. Accuracy requirements rise with consequence.

An outdated industry label may slightly reduce the quality of a marketing summary. An incorrect bank account or delivery address can cause direct harm.

Singapore’s PDPA requires reasonable efforts to ensure personal data is accurate and complete when it is likely to be used to make a decision affecting the individual or disclosed to another organisation. Even where personal data is not involved, the same operational principle is useful: verify fields in proportion to their impact.

3. Completeness

A record can be accurate but unusable because an essential field is blank. Decide which information is required at each process stage.

Do not make every field mandatory at first contact. Collect the minimum needed to progress responsibly. A qualification stage may require service interest and contact method; fulfilment may later require an address and confirmed scope.

Measure missingness by field and source. If thirty per cent of website enquiries lack a required location, the form or process needs attention rather than a one-time cleanup.

4. Consistency

The same concept should use the same definition and format across the process. Dates, currency, status labels and identifiers frequently cause problems.

“Closed”, “Done”, “Completed” and “Delivered” may appear equivalent but represent different operational events. Agree on controlled values and document them.

Consistency also means deciding which system is authoritative. If the CRM and accounting platform disagree on a billing address, employees need a rule for which system owns that field and how updates are synchronised.

5. Ownership

Every important dataset or field group needs a business owner. Ownership means approving definitions, resolving conflicts, setting quality expectations and reviewing changes.

The owner does not personally correct every record. A sales manager may own opportunity stages while sales coordinators maintain individual records. An operations manager may own service-status definitions while frontline staff update them.

Without ownership, data quality becomes everybody’s concern and nobody’s work.

6. Protection and lifecycle

Usable data is not merely accessible. It is accessible to the right people for the right purpose and retained for an appropriate period.

Map where information is collected, stored, copied, disclosed, archived and disposed of. Remove unnecessary exports and personal-device copies. Apply role-based access and record when sensitive data is transferred to a third-party service.

PDPC guidance recommends understanding personal-data flows across the lifecycle and operationalising policies through business processes and systems. Data preparation should improve protection, not create a new uncontrolled master spreadsheet.

Start with one use case, not every file

“Clean all company data” is not a workable project. The scope will expand faster than the team can make decisions.

Choose one proposed use case and trace the data it requires.

Suppose the business wants to automate quotation preparation. The relevant data might include customer details, approved service descriptions, current pricing rules, discounts, tax treatment and quotation status.

Ask:

1. Which fields are required for a correct output?
2. Where does each field originate?
3. Which system or owner is authoritative?
4. How often does it change?
5. What errors already occur?
6. What happens if the value is wrong?
7. Does it contain personal or confidential information?

This produces a bounded data-readiness plan tied to business value.

Build a simple data inventory

Create a register for the datasets used by the selected process. Useful columns include:

• dataset or system name;
• business purpose;
• owner;
• important fields;
• source and authoritative system;
• personal or confidential data category;
• known quality issues;
• update frequency;
• access roles;
• retention or disposal rule; and
• downstream automations or reports.

Keep the first inventory small enough to maintain. It should expose dependencies, not attempt to catalogue every document the company has ever created.

The inventory often reveals that a “single AI project” depends on several uncontrolled sources. That insight is valuable. It allows the business to narrow the project or improve the source before spending on integration.

Clean the process before cleaning the records

If the process continues creating errors, a cleanup provides only temporary relief.

Investigate why the data became messy:

• Are employees retyping information because systems are not connected?
• Do two teams use different definitions?
• Are required fields hidden or difficult to complete?
• Is a spreadsheet being used beyond its intended scale?
• Do staff lack permission to correct an obvious error?
• Are customers asked for the same information several times?
• Does the process create duplicate records by design?

Fix the source of recurring errors. Use validation, controlled choices, clear field descriptions and automated duplication checks where appropriate.

Do not remove all free text. Notes capture context that structured fields cannot. Separate reusable facts from narrative explanation and define where each belongs.

Resolve duplicates using business rules

Duplicate records are rarely solved safely by clicking “merge all”. Two customers may share a name. One company may have several branches. A contact may legitimately represent more than one organisation.

Define matching rules using reliable identifiers such as a system ID, verified email, telephone number or company registration detail where appropriate and lawfully held. Then identify ambiguous cases for human review.

Keep a merge log for important records. Preserve the source and reason so the decision can be understood or reversed.

After cleanup, prevent recurrence. Search before creating, validate identifiers and define how integrations update existing records.

Create a business data dictionary

A data dictionary is a plain-language definition of important fields. It can begin as a shared document containing:

• field name;
• meaning;
• permitted format or values;
• source;
• owner;
• example;
• when it becomes required; and
• known exclusions.

For a field called “Customer status”, define whether it means an active contract, a purchase within twelve months or simply a contact record. AI and analytics cannot resolve a definition the business has not agreed on.

The dictionary also helps vendors configure systems without inventing assumptions. It becomes part of the handover and future change process.

Prepare documents for AI retrieval

Some AI use cases depend on policies, manuals, proposals or product documents rather than database fields.

Document readiness requires its own discipline:

• remove obsolete and duplicate versions;
• label the approved version and owner;
• use clear headings and descriptive titles;
• separate public, internal and restricted content;
• record effective and review dates;
• state exceptions explicitly; and
• ensure scans are legible and searchable.

A retrieval system may find several plausible passages. If the source set includes a five-year-old policy beside the current one, the model can provide an outdated answer with confidence.

Do not ask AI to compensate for poor document control. Establish the approved source first.

Test data with real exceptions

Before automating, create a test set containing normal and difficult cases.

For customer data, include missing fields, duplicate names, changed addresses and international formats. For invoices, include credits, partial payments and unusual tax treatment. For documents, include conflicting wording and incomplete scans.

Define expected outcomes. Run the workflow or AI system against the test set and record where it fails.

NIST’s AI Risk Management Framework resources emphasise the connection between AI performance and the quality, reliability and representativeness of underlying data. A test set made only from perfect examples will hide the operational reality.

After deployment, monitor the incoming data. Quality can deteriorate when a new channel is added, staff behaviour changes or a system update alters a field.

Decide what not to migrate

Migration is an opportunity to reduce clutter and risk.

Do not automatically move:

• obsolete templates and policies;
• duplicate records with no operational value;
• fields collected without a current purpose;
• stale contacts outside the retention approach;
• unverified notes presented as facts; or
• data the new process is not authorised to use.

Archive what must be retained for legal or business reasons with appropriate controls. Delete what should no longer be kept. Document the decision.

More data does not automatically improve AI. Relevant, governed and representative data is more valuable than a large uncontrolled collection.

A four-week data-readiness sprint

An SME can make meaningful progress in a month.

Week 1: Define and map

Select one use case, identify the required outputs and map the source data. Name the business owner and record the current baseline for errors or manual correction.

Week 2: Profile and decide

Measure missing, duplicate, inconsistent and outdated values. Agree on definitions, authoritative sources and acceptable quality thresholds.

Week 3: Clean and prevent

Correct the priority records, standardise formats, remove obsolete material and implement controls that stop the same errors from returning.

Week 4: Test and govern

Run representative cases, document limitations, assign ongoing quality checks and decide whether the use case is ready to pilot.

The outcome may be “not yet”. That is a valuable decision if it prevents the business from automating unreliable information.

Good data makes simple technology more powerful

Data preparation is sometimes presented as a preliminary obstacle before the interesting AI work begins. In practice, it is where an SME creates much of the value.

Clear definitions improve reporting. A trusted customer record improves service. Controlled document versions reduce mistakes. Named owners make future system changes easier. These benefits exist even if the business later decides that a simple workflow is more appropriate than AI.

Start with one decision or process. Define the required information, identify the trusted source, correct recurring errors, protect the data through its lifecycle and test real exceptions.

AI and automation should operate on top of that discipline. Otherwise, the business is not removing manual judgement. It is replacing informed human correction with faster, less visible error.

Sources and further reading

• IMDA: AI for Enterprise Impact Playbook
• PDPC: Accountability Within an Organisation
• PDPC: Data Protection Obligations
• NIST: AI Risk Management Framework Playbook – Measure