Databases and Reporting

Data designed so it can be trusted, and reports that answer the questions you actually ask.

What you get

Data designed so it can be trusted, and reports that answer the question you actually asked.

Most reporting problems are not reporting problems. They are data problems wearing a disguise. When two reports disagree, the cause is almost never the chart: it is that the same thing was captured twice, in two places, in two formats, by two people who each thought they were the one keeping the record.

Who this is for

• Organisations where two reports on the same thing give different numbers
• Anyone reconciling spreadsheets by hand before a management meeting
• Businesses whose data lives in several systems that do not talk to each other
• Teams who can see what happened but cannot see why
• Anyone who has stopped trusting a number and started checking it manually

What is included

• A data structure designed around what you need to know, not around how the first spreadsheet happened to be laid out
• Validation at the point of entry, so bad data is caught when it is typed rather than found months later
• Reports and dashboards built around your real questions
• Scheduled reports that arrive without anyone remembering to run them
• Export to spreadsheet, so nothing is trapped
• Historical data brought across and reconciled rather than abandoned

Getting the structure right first

The unglamorous part decides everything else. If a customer can be captured as "ABC Ltd", "A.B.C. Limited" and "abc ltd" then no report about that customer can ever be complete, and no amount of clever charting will fix it.

So we work out what the real entities are, how they relate, and where each fact should live once. Then entry is designed so the same information cannot be recorded three ways. It is not exciting work, and it is the difference between a system that produces answers and one that produces arguments.

Reports people actually use

A dashboard nobody opens is a failure regardless of how it looks.

We start from the decisions you need to make rather than from the data you happen to have. What would you do differently if you knew this? If there is no answer, the number does not need a chart. That single question removes most of what typically clutters a reporting screen.

Then the reports get built to be readable at a glance, to load quickly, and to be trusted, which mostly means being able to click through from a total to the records behind it. A number you cannot verify is a number you will eventually stop believing.

How we work

We look at what you are already producing, including the spreadsheets people maintain quietly on the side. Those side spreadsheets are the most useful thing in the room: they show exactly where the official system is failing.

Then we agree what the reports need to answer before building anything, because reporting requirements gathered afterwards produce dashboards that technically work and nobody uses.

Questions we are often asked

Our data is a mess. Is it too late? No, and it is the normal starting point. Cleaning and restructuring existing data is part of the work rather than a prerequisite you have to complete first.

Can you work with the systems we already have? Often, depending on what they allow us to read. We check what is genuinely accessible before it becomes an assumption in the plan.

Will we still be able to use Excel? Yes. Export is built in. The aim is to stop Excel being the system of record, not to stop you using it.

Can reports be sent automatically? Yes, on a schedule, to the people who need them.

Who can see what? Access is controlled by role, so sensitive figures are visible only to the people who should see them.