What Data Analytics Can Do for a Small Business

Most small businesses already collect more data than they use. Every sale, booking, invoice and customer record is stored somewhere: in the shop system, in the accounting tool, and in a few spreadsheets that someone keeps up to date. And yet the big decisions, like what to stock, where to spend and which customers to chase, still come down to gut feel. Data analytics is the work of turning those records into answers you can act on.

We sell this work (Data Analytics is one of our services), so read this as an explanation from an interested party. We've tried to write it so it's useful even if you never contact us.

Three kinds of questions

Data analytics sounds like one thing, but it answers three different kinds of questions. It helps to know which one you're asking, because each one needs different work.

What is happening? This is the simplest kind. How much did we sell last month, by product and by branch? Which customers bought last year but not this year? How much stock is sitting unsold? The answer is usually a dashboard: one page of numbers and charts that stays up to date by itself, so nobody has to build it again every Monday.

Why is it happening? This is harder. Sales went down last quarter, but why? Was it one product, one branch, one kind of customer, or one month? Answering it means cutting the numbers in different ways until the cause shows up, then checking that it's a real cause and not a coincidence. The answer is usually a short write-up in plain words, with the few charts that prove it.

What will happen next? This is a forecast or a prediction. How much of each product will we sell next month? Which customers are likely to stop buying? A forecast is built from your own history, so it can only see patterns your data already holds. That is both its strength and its limit.

It's tempting to ask for the third kind first. But a forecast built on numbers nobody trusts is worse than no forecast at all, so the work usually starts with getting "what is happening" right.

Start with the decision, not the data

A common mistake is to start with the data: "We have all this, let's see what it says." That road leads to a lot of charts and very few decisions.

Start instead with a decision you have to make, and make it specific. "How much of each product should we order for December?" is a good question. "What does our data tell us?" is not, because nobody can tell when it has been answered.

A good question also tells you which data matters. To plan December stock, you need past sales by product and by week, what was in stock at the time, and when prices or promotions changed. You don't need the email newsletter list. Knowing that early saves weeks.

Cleaning is the biggest part of the job

Here is the part that surprises owners: most of the work in a data project isn't the analysis. It's getting the data into a state where the analysis can be trusted.

Real business data is messy in very ordinary ways:

• The same customer appears three times, as "J. Santos", "Juan Santos" and "JUAN SANTOS".
• A product was renamed halfway through the year, so it looks like one product stopped selling and a new one started.
• A month is missing because the export failed and nobody noticed.
• Two systems both record sales, and their totals never quite match.

None of this is anyone's fault. It's what happens when people use tools to do their jobs. But every number built on top of it carries the mess forward. If one customer is counted three times, your "customers lost this year" figure is wrong before anyone draws a chart.

So the first real step is cleaning: removing duplicates, merging names, finding the gaps, and agreeing which system is right when two of them disagree. It isn't exciting work, but it decides whether you can believe anything that comes after it.

Sometimes cleaning shows that the data can't answer the question yet. Maybe the records only go back eight months, or the field you need was never recorded. That is a useful answer too. The honest result is "not yet, and here is what to start recording so it can answer next year."

How to know you can trust a forecast

A forecast is a guess about the future, made by a model that learned from your past. The question to ask about any forecast is simple: how well would it have done if we had used it before?

There is a standard way to check this, and you should expect it from anyone who builds one for you. Hold back a stretch of past data, for example the last six months. Build the forecast using only what came before. Then let it predict those six months, and compare its guesses with what really happened. The gap between the two is the honest measure of how good it is.

Two more things separate a forecast you can use from one that only looks good:

• It gives a range, not just one number. "Between 400 and 520 units, most likely around 460" tells you how much room for error to plan for. A single number hides that.
• It says how sure it is, in plain words. A forecast should come with its limits written down: what it can't see (a new competitor, a price change you're planning), and when it should be checked again.

If someone shows you a forecast without telling you how it did on past data, ask. If they can't answer, don't build decisions on it.

What you should end up with

The result of a data project shouldn't be a slide deck you look at once. It should be something your team keeps using:

• Dashboards that update themselves from your own systems, showing the handful of numbers that matter, built for the people who will actually read them.
• One clean place for your data, so sales, stock and customer records can be looked at together instead of in three separate tools.
• Plain written notes on how each number and each forecast was made, so anyone can check it, run it again or change it later.
• Everything in your own accounts. The code, the data and the dashboards should belong to you, not to whoever built them.

The last point matters more than it sounds. If the work lives in someone else's account, you don't own an answer. You rent one.

When it isn't data analytics you need

Two nearby problems look like this one but have a different fix.

If someone on your team rebuilds the same report by hand every week, copying numbers from one place to another, that is an automation problem. The fix is to make the report build itself, which is Automation & Integration work. Our post on finding what's worth automating shows how to spot it.

If what you want is something that answers your staff's or your customers' questions in plain language, that is an AI assistant, not a dashboard. We wrote about what an AI assistant can and can't do too.

Data analytics starts where the report stops. It's for when you have the numbers but not the answers.

Where to start this week

You can do the first step yourself, at no cost. Write down the three decisions you make most often that you wish you made with better information. For each one, write down where the data that would help lives today: which system, which spreadsheet, whose computer.

That one page tells you most of what you need to know. It shows whether your data can answer the question, how much cleaning stands in the way, and which question is worth paying to answer first. If you'd like someone to read that page with you and tell you honestly whether your data can answer it, that is exactly where our work starts.