You have the numbers. They are in the accounting system, the CRM, the job scheduler, the online store, and a few spreadsheets someone maintains by hand. What you do not have is an answer to a simple question on a Tuesday afternoon: which customers spent less this quarter than last, and why. Getting that answer means asking someone to pull an export, waiting a day, and receiving a spreadsheet that answers a slightly different question.
Then you saw a demo where somebody typed “show me revenue by region” into a box and a chart appeared. You wondered why yours cannot do that.
AI data analysis for business is exactly that idea: asking your own data questions in plain English and getting a correct answer back. It works well, but only when a few unglamorous things are true first. This article covers what those are, how the trick works, why you cannot trust the first answer, and which reports are worth automating rather than asking for.
What AI data analysis for a business actually is
Imagine hiring a sharp analyst who has never seen your business. On day one you ask, “which jobs lost money last month?” She cannot answer. She does not know where the job data lives, what “lost money” means to you (before or after overhead?), or that the job numbers in the scheduler and the invoices in accounting are matched by a code somebody types by hand. After a month of learning the systems and the definitions, she can answer in a minute.
An AI analyst is the same, except it never gets the month. Every question is day one. So the month of learning has to be done up front, in a form the AI can use: the data gathered in one place, the columns named for what they contain, the definitions written down. Once that exists, the AI part is straightforward. It translates your English question into a database query, runs it, and explains the result. That step is called text-to-SQL (SQL being the standard language for asking a database questions), and the current models are genuinely good at it when the database is tidy. Most failed “AI analytics” projects fail because someone bought the AI part and skipped the month.
1. Get the data into one place first
An AI can only query what it can reach. If your numbers are spread across five systems, the first job is to copy them, on a schedule, into a single database you control. This is called a data warehouse when it is big and a reporting database when it is small; for most businesses it is a Postgres database (free, widely used) on a small server, refreshed nightly.
The copying is done by connectors. Most SaaS systems have an export API (a way for software to fetch data automatically), and tools like n8n, Make, Airbyte or Fivetran move the data with little or no code. Where a system has no API, a scheduled export to a spreadsheet is a legitimate, if fragile, fallback. Do not let anyone talk you into querying the live systems directly; a badly formed query can hurt the system your staff are working in. Copy, then query the copy.
2. Clean the columns and write down what they mean
A table with columns called f1, f2 and custfld_3 is not something an AI or a new analyst can use. Rename columns to what they hold. Make dates dates, not text. Make money a number in one currency. Decide which of your three “customer name” fields is the real one.
Then write a short document, a data dictionary, that says for each table what one row represents and for each important column what it means and how it is calculated. “Gross margin is revenue minus direct cost, excluding overhead allocation.” This document is given to the AI along with the question, and it is the single biggest lever on answer quality. The preparation work in AI Readiness Checklist for Small Business, 20 Points to Pass is largely this. If two people in your business would define “active customer” differently, the AI will pick one and not tell you which. Settle it in the dictionary.
3. Understand what text-to-SQL is doing
When you ask “which customers spent less this quarter than last”, the system builds a prompt containing your question, the list of tables and columns, and the dictionary. The model writes a database query. The query runs against the reporting database. The model then explains the rows that come back, or draws a chart.
This is worth understanding because it tells you where things go wrong. The model can misread your question (it took “this quarter” as calendar, you meant fiscal). It can write a query that is valid but wrong (joined the tables on the wrong key, counted invoices instead of customers). It can get correct rows and describe them wrongly. None of these look like errors on the screen. They look like answers.
So the query itself must be visible. Any tool that shows you a chart but will not show the query that made it should not be trusted with a decision. A developer, or a bookkeeper who has learned a little SQL, should be able to read the query and confirm it asked what you asked.
4. Treat every first answer as a draft
The trust problem is the whole difficulty. A wrong number that looks right is worse than no number. So build habits that catch mistakes. Ask the same question two ways and compare. Ask for the total and check it against a number you already know (last month’s revenue from the accounting system). Ask the AI to explain its query in plain words before you accept the chart.
Better tools do some of this automatically with a sanity check (does the row count seem plausible, does the sum match the known total). The evaluation discipline in AI Evaluation and Evals: Testing an AI Feature Before Launch applies here: keep thirty questions with known-correct answers, and every time the model or the data changes, rerun them. Our view is that ad hoc questions to an AI are for exploring, not deciding. When a question matters enough to act on, it graduates to a saved, reviewed report.
5. Save the questions that matter as fixed reports
You do not actually have a thousand questions. You have perhaps a dozen you ask every week and a long tail you ask once. The dozen should not be re-asked through an AI each time, with a fresh chance of a subtle misread. They should be written once as queries, checked by a person, and scheduled: run every Monday, deliver to email or chat.
The AI then has a second job, which is the more useful one: reading the fixed report and narrating what changed. “Revenue is up eight percent on last week, driven by two large orders from one customer; margin is flat; three jobs went over budget, listed below.” That is the report an owner actually reads. How to build it is the subject of Automated Business Reporting With AI That You Can Actually Trust.
6. Give the AI read-only access and nothing else
The analysis system should connect to the reporting database with a login that can read and cannot write, delete or change anything. This is a one-line setting in any database and it removes an entire category of disaster. The model cannot be talked into dropping a table, because the account it uses cannot drop tables. Also set limits on how long a query may run and how many rows it may return, so an accidentally enormous query hits a wall instead of taking your server down.
7. Respect who may see what
The moment you connect an AI to all your data, the question “who can ask it what” becomes real. Payroll, individual customer details, and margin by client may be fine for the owner and not for the sales floor. The reporting database should either hold only what everyone may see, or the analysis tool should know who is asking and filter accordingly. Do this at the database level, with separate views per role, not by hoping the prompt says “do not show salaries”.
If the data includes personal information about customers or staff, the privacy questions in AI Data Privacy for Business, What Happens to Customer Data apply. Sending rows to a model provider is sending data to a third party; check the terms, and send only what the question needs.
8. Start with three questions, not a dashboard
Do not begin by building a dashboard with forty tiles. Begin with the three questions you most often wish you could answer on the spot. Get the data for those in one place, define the terms, and get correct answers. Live with that for a month. Your questions change once answers are cheap, and the dashboard you would have built would have been wrong.
The three-question version also proves the data pipeline, which is the fragile part. If the nightly copy breaks and nobody notices, every answer is a day stale and confidently so. Put an alert on the pipeline before you put a chart on the wall.
Picture a business like this one
The business below is a composite of the kind of company that writes to us, not a client. The numbers describe the shape of the problem, not a case study.
Picture a business like this one: a home-services company with sixty field staff, a scheduling system, an accounting package, a CRM for quotes, and a payroll provider. The owner’s question every month is which job types and which crews make money. Answering it takes the office manager two days of exports and a spreadsheet nobody fully trusts, and by the time it is done the month is half over.
What gets built for a company like this:
- Nightly copies of jobs, quotes, invoices and hours into a small Postgres reporting database.
- A cleaning step that matches jobs to invoices and hours by the job code, and flags the ones that do not match.
- A two-page data dictionary defining job margin, completed job, and crew.
- Four scheduled reports: margin by job type, margin by crew, unmatched records, and quotes that have gone quiet.
- An AI narration on each report, and a chat interface for ad hoc questions, both read-only, both showing the query.
What changes is that the monthly question becomes a Monday email, and the owner spends the saved time on the exceptions: the crew whose margin has slipped for three weeks, the job type that is consistently quoted too low. The ad hoc chat gets used for exploring (“which customers had two or more callbacks this year”) and its answers get checked against the fixed reports before anyone acts.
What it costs to run
A small managed Postgres database is between $15 and $60 a month at the sizes most businesses need, or included with a platform like Supabase. The copying can be done with n8n or Make (roughly $20 to $60 a month), or with a dedicated connector service like Fivetran or Airbyte Cloud, whose pricing scales with data volume and can climb; check the current pricing pages before choosing.
The model cost is modest. A text-to-SQL question with a decent dictionary is a few thousand tokens (the units models are billed in, roughly three quarters of a word each), so a few cents per question on a capable model and much less on a small one. A business asking a few hundred questions a month and narrating a handful of reports would see a model bill well under $50. A dashboard layer (Metabase, which is free to self-host, or a hosted tool with a monthly fee) is optional and worth having once the questions settle.
The mistakes we see most
- Buying the chat box before the data is in one place. The demo looks great on the vendor’s clean sample; on your five systems it can answer nothing.
- Trusting the chart. The query was wrong, the chart was pretty, the decision was made.
- Undefined terms. “Active customer” means three things in the same company, and the AI picked one silently.
- Connecting with a login that can write. One bad query away from a very bad day.
- Dashboards nobody reads. Forty tiles, no narration, no owner.
- Nobody watching the pipeline. Stale data answered confidently is worse than no data.
When to bring in help
If your data already lives in one system with decent built-in reporting, use that first. Many accounting and CRM products now include a plain-English question feature over their own data, and for single-system questions it may be all you need. A clean spreadsheet export and an AI assistant reading it is a fine way to explore for a month before committing to anything.
The moment the questions cross systems (jobs from one, money from another, hours from a third), you need a reporting database, connectors, matching logic and a dictionary, and that is a developer’s job. So are the read-only access, the row limits, the per-role views and the alerts on the pipeline. The general rules for keeping an AI from confidently misleading you are in AI Hallucination Guardrails for Business Applications.
Levelbrook builds this for businesses, from the reporting database to the question interface, at a fixed price from a written scope, running in your own accounts so the data and the tools are yours. If you have a Tuesday-afternoon question you cannot get answered, the form below is where a conversation starts.