How to Prepare Your Business Data for AI: A Practical Guide for Alberta Companies

Most AI projects do not fail because the model is not clever enough. They struggle because the business information behind it is scattered, stale, inconsistent, or locked inside somebody’s head.

A customer service assistant cannot give a reliable answer when three documents list different cancellation policies. A quoting workflow cannot move faster when product names change between the CRM, accounting system, and price sheet. An internal search tool cannot find the right procedure if the approved version sits beside six old copies named “final.”

This is the unglamorous part of AI implementation, but it is often where the useful work begins.

The good news is that an Alberta small business does not need a perfect data warehouse before using AI. You need a clean, controlled set of information for one well-defined workflow. I would rather build from 30 trusted documents than pour 30,000 mystery files into a system and hope the model sorts them out.

Start with the job, not the files

“Get our data ready for AI” is too broad to be useful. Data only becomes good or bad in relation to a specific job.

Suppose you want AI to help prepare quotes. The system may need current pricing, service descriptions, travel rules, approved terms, customer details, and past quote examples. It probably does not need employee reviews, every email ever sent, or ten years of bookkeeping records.

If the first project is after-hours lead intake, the source set changes. You may need service areas, qualifying questions, scheduling rules, escalation instructions, and CRM fields. That is a much smaller problem.

Before cleaning anything, write one sentence:

When [a clear trigger happens], the system will use [named information] to produce [a reviewable result].

For example: “When a commercial quote request arrives, the system will use the current service catalogue, rate sheet, and travel policy to prepare a draft for the estimator.”

That sentence gives the data work a boundary. My AI readiness assessment for Alberta businesses can help if the workflow itself is still fuzzy.

Build a source inventory you can explain

Once the job is clear, list every source the current process uses. Do this with the employee who handles the work, not from a boardroom guess about how the process ought to work.

A basic inventory can include:

• Source name and location
• Owner responsible for keeping it current
• Information the workflow takes from it
• Last review date
• Who can access it
• Whether it contains personal or confidential information
• Known duplicates or conflicts
• What happens when the source is unavailable

Include software systems, shared folders, spreadsheets, PDFs, templates, inboxes, and informal reference material. If the employee keeps a paper cheat sheet beside the monitor, that belongs in the inventory too. It may be the most honest description of the process you have.

Walk through five recent examples and note which sources were actually opened. This often exposes a gap between the official procedure and the real one. It also keeps you from spending a week cleaning a folder nobody uses.

Decide which source wins

AI cannot resolve a policy dispute the business has not resolved.

If the website says one thing, the sales deck says another, and the operations manager follows a third rule, choose an authoritative source before connecting a model. Record who owns that source and how changes get approved.

I use a simple priority:

1. Approved system of record
2. Current policy or procedure owned by a named person
3. Reviewed working document used by the team
4. Historical material kept only for reference

Archive or clearly label the rest. Do not leave old versions in the same retrieval set and expect the AI to understand that “Pricing Final 4 Revised” lost an argument to a newer spreadsheet.

This matters especially when using retrieval-augmented generation, or RAG. RAG helps an AI answer from your business material, but it does not make conflicting material agree. Better retrieval can find the wrong policy faster.

Clean only what affects the pilot

Data cleanup can become an endless side project. Keep the first pass tied to the output you want.

For a quoting pilot, I would check:

• Are service names consistent across the source documents?
• Are prices current, with effective dates where needed?
• Are units clear, such as hourly, daily, per kilometre, or per item?
• Are taxes, discounts, minimum charges, and travel rules explicit?
• Are exceptions separated from standard pricing?
• Can an estimator trace each draft line back to a source?

For customer service, I would look for current hours, locations, service areas, response commitments, escalation contacts, return rules, and approved answers to common questions.

Fix duplicates, obvious formatting problems, incomplete labels, and contradictions that affect those fields. Leave unrelated cleanup for later. A narrow pilot should not quietly turn into a company-wide records migration.

Separate facts, examples, and instructions

Businesses often mix three different kinds of information in the same folder.

Facts describe the business now: current prices, hours, territories, product specifications, staff roles, or contract terms.

Examples show how past work was handled: old proposals, completed tickets, previous estimates, and customer messages.

Instructions tell the system or employee what to do: routing rules, approval limits, escalation steps, and writing guidelines.

The distinction matters. A past quote can teach a system about structure, but it should not automatically become a source of current pricing. A polite email from a former employee is an example of tone, not an approved refund policy.

Label each source by its purpose. When possible, put volatile facts such as prices and availability in structured fields rather than burying them inside long documents. Keep instructions short enough that a manager can review them without needing a map.

Add useful structure without rebuilding everything

Small businesses often hear “structured data” and picture a large database project. Sometimes a clean spreadsheet is enough.

Consistent columns, names, formats, and identifiers make automation more reliable. If one customer appears as “Northern Field Services Ltd.,” “Northern Field,” and “NFS,” decide whether those are the same account and give the record one stable identifier. If dates appear in several formats, pick one. If a status field includes “won,” “closed won,” “yes,” and a green cell, standardize it.

Free-form notes still have value. AI is good at extracting meaning from text. The workflow becomes safer when important operational decisions do not depend on interpreting an unlabeled paragraph.

Focus first on fields that control an action:

• Customer or job identifier
• Request type
• Owner
• Status
• Due date
• Approval state
• Source reference

A CRM automation project is much easier when those basics mean the same thing to sales, operations, and accounting.

Set access rules before connecting tools

Convenient access is not the same as appropriate access.

List the minimum information the pilot needs, then limit the connection to that scope. A lead qualification workflow may need contact details and the submitted request. It does not need payroll, legal files, or unrestricted access to the owner’s inbox.

Before choosing a tool or vendor, get clear answers to these questions:

1. What information leaves your systems?
2. Where is it processed and stored?
3. How long is it retained?
4. Is your information used to train a vendor’s models?
5. Can access be limited by role, folder, record type, or account?
6. Are actions and source lookups logged?
7. How do you revoke access and delete retained information?
8. Which subcontractors or model providers may receive the data?

Use test records that have personal details removed during early development. Give each staff member an individual account. Keep production credentials out of prompts, documents, and shared spreadsheets.

Businesses subject to Alberta’s Personal Information Protection Act should confirm their privacy obligations with qualified counsel. Technical controls support compliance, but an AI consultant should not present technical setup as legal advice.

Design for traceability

A useful AI output should show its work where accuracy matters.

If the system drafts a quote, the estimator should be able to see which rate sheet and policy supported it. If it summarizes a work order, the reviewer should be able to open the original note. If it answers an internal question, it should identify the source and version used.

Traceability changes the review from “Does this sound right?” to “Is this supported by the right source?” That is faster and much less vulnerable to confident nonsense.

Do not let the model fill gaps silently. Missing prices, uncertain customer identities, or conflicting instructions should produce an exception for a person to resolve. The system should say what it could not confirm.

This is one reason I prefer limited permissions for early AI agents. Drafting, classifying, and preparing a review queue are reversible. Sending a binding quote or overwriting a customer record may not be.

Test with real mess, not ideal examples

A demo usually uses a clean request written by somebody who knows how the system works. Customers and employees will not cooperate that neatly.

Build a test set from recent work after removing information that is not needed. Include routine examples and awkward ones:

• Missing fields
• Misspelled names
• Duplicate customers
• Outdated attachments
• Conflicting requests
• Short notes with little context
• Requests that belong to another department
• Cases that must be escalated

Write the expected result for each example. Then compare the AI output with that result. Track incorrect facts, missed escalations, unnecessary edits, and cases where the reviewer could not verify the source.

Do not grade the pilot on whether the prose sounds polished. Grade it on whether the right information reaches the right person with less effort.

Use a four-week preparation plan

Week 1: define and observe

Choose one workflow and follow five to ten recent cases from start to finish. Name the trigger, output, process owner, systems, exceptions, and one business measure.

Week 2: select and clean sources

Create the inventory, choose the authoritative material, remove relevant duplicates, resolve policy conflicts, and standardize the few fields that control the workflow.

Week 3: secure and test

Set permissions, prepare de-identified test cases, define approval points, and test failures as carefully as successes. Confirm that a reviewer can trace important outputs to their sources.

Week 4: run beside the current process

Process a limited number of real cases with human review. Compare handling time, corrections, missing information, and turnaround against the baseline. Ask the employee doing the work whether the pilot removed effort or created another queue to babysit.

If the workflow performs well, expand carefully. If the source information remains unreliable, fix that before adding more automation. The cost of AI for a small business depends heavily on how much process and data cleanup has to happen before the useful build begins.

What good enough looks like

Your business data is ready for a first AI pilot when:

• One workflow has a clear start and finish
• A named person owns the process and its source information
• The system uses a small set of current, approved sources
• Important fields have consistent labels and formats
• Personal and confidential information is limited to what the job needs
• Reviewers can trace important outputs back to source material
• Exceptions go to a person instead of being guessed
• Access can be revoked and the old process still works
• One business result has a baseline

That is good enough. You do not need every record cleaned or every department connected.

The operating details will differ by company and location. A field service business working around Grande Prairie may care about offline notes, travel rules, and incomplete job records. An Edmonton firm may need tighter document permissions across a larger team. I work with companies in Edmonton and across Alberta to define those boundaries before software starts making decisions.

If you want help preparing business data for AI, book a consultation with me. Bring one workflow, a few real examples, and the documents your team currently trusts. We can find out what is ready, what needs cleanup, and whether the pilot is worth building.