Analytics purchases follow a recognisable pattern. A business feels it lacks visibility, evaluates several tools, and chooses on features and price. Six months later there is a working installation, a handful of dashboards built during onboarding, and roughly the same decision-making as before.

The tool is rarely at fault. The questions that determine whether analytics software helps are almost entirely about the business buying it, and they are best answered before a demo rather than after a contract.

Questions about your business

What specific decisions will this support? Name three, with the person who makes each. If the answer is "we need better visibility", stop here — that phrase describes a feeling, not a requirement, and it will not survive contact with an implementation.

Who will actually build and maintain the reports? Analytics tools are not self-operating. Someone needs to model the data, define metrics and keep them correct as systems change. If that person does not exist and is not being hired, you are buying a tool for nobody. This is the most common reason implementations quietly fail.

Is the underlying data good enough? Optional fields, free text where lists belong, inconsistent definitions, records created for the wrong reasons. Analytics software will faithfully display all of it. See dashboards do not fix bad data.

Do the teams agree on definitions? If sales and finance count revenue differently today, they will count it differently in the new tool, and the tool will make the disagreement more visible and more heated.

What is the real question behind the purchase? Frequently it is "I do not trust the numbers I am being given" or "I cannot get an answer without asking someone." Those are different problems — the first is a data-quality problem, the second is an access problem. Only the second is solved by analytics software.

Questions about the tool

How does data get in, and what happens when a source changes? Connectors break. Understand who fixes them and how you find out. A pipeline that fails silently produces stale dashboards that look current, which is worse than an obvious outage.

Can a reader drill from a number to the underlying records? This is the single most valuable feature for building trust and it is often weak. Without it, every questioned figure becomes a request to an analyst.

Where are metric definitions stored? Definitions buried inside individual charts guarantee drift, with two charts computing "active customers" differently. A shared definition layer is worth paying for.

What does it cost at three times your current volume? Pricing by rows, queries, users or refreshes can scale in ways that are not obvious at signature. Model it.

How do you get your data and your work out? If you leave in three years, what comes with you? Raw data should be exportable, and you should know whether report definitions can be extracted in any usable form. See why owning your domain and business data matters.

What are the access controls? Analytics tools tend to accumulate sensitive information — salaries, margins, customer details — and are often given broad permissions during setup. Decide who sees what before, not after.

What happens when nobody logs in for a month? A tool with no active owner degrades. Ask what maintenance is required to keep it accurate rather than merely running.

Alternatives worth ruling out first

The reporting in the systems you already own. CRMs, accounting packages and job-management systems have reporting that is frequently underused because nobody has explored it. Check this properly before buying anything; it is free and it is already connected to your data.

A well-built spreadsheet. For a stable set of questions at modest volume, an exported model maintained by one person is often entirely adequate and considerably cheaper. See when a spreadsheet is still the right tool.

Fixing capture instead. If the problem is that data is missing or inconsistent, no reporting layer will help. The money is better spent on making the fields required and the lists controlled.

A handful of alerts. If the real need is to know when something goes wrong, alerting is cheaper, more reliable and more likely to be acted on than a dashboard someone has to remember to open.

A sensible sequence

  1. Write the three decisions and who makes them.
  2. Answer them once, manually, however painfully. This validates that the data exists and reveals its faults.
  3. Fix the worst data-capture problems you discovered doing so.
  4. Try to answer them again using the reporting already available in your existing systems.
  5. Only if that fails, and only if you have a named owner, buy a tool.

Most businesses that follow this sequence do not reach step five, and end up with better answers than they would have had. The ones that do reach it arrive with clean definitions, a real owner and three questions — which is exactly what makes an implementation succeed.

Before you sign

  • Three specific decisions, with named decision-makers, are written down
  • A named person owns building and maintaining the reporting
  • The underlying data has been checked by hand against source records
  • Metric definitions are agreed across teams in writing
  • The reporting already available in existing systems has been exhausted
  • Drill-down to underlying records is supported
  • Cost has been modelled at three times current volume
  • Export of both data and definitions has been confirmed
  • Access controls have been decided before rollout

Analytics software is a good purchase for a business that already knows what it wants to know and cannot get to it quickly. It is a poor substitute for deciding what you want to know.