Meraki's administrators run a children's language school with more than 2,600 students. When they need to know which groups have unpaid dues, or how a class is progressing, they can ask Claude in plain language. Claude answers from the school's own platform, through a connector we built for it.
That setup did not start with AI. It started with a platform that already recorded the right things: sessions, payments, attendance, progress. Asking good questions of your data only works when the software underneath writes the answers down.
This post is about that order of work. Which decisions to start with, what your software has to record, and how managers get answers without waiting for someone to build a report.
Start with five decisions, not fifty metrics
Most analytics projects start with a list of charts. A better start is a list of decisions people make every week or month, and what they need to know to make them well.
Pricing: which plans or discounts bring customers who stay?
Staffing: where is the team overloaded next month?
Sales: which lead sources turn into paying customers?
Cash: who owes what, and since when?
Product: which features do customers actually use?
Write yours down, with the person who makes each one. Five is plenty for a first pass. Each decision points to a few numbers, and each number points to data some system must record. That chain tells you what to build, and what to skip.
Check that your software records it
This is where most projects stall. The decision is clear, but the data was never captured, or it was captured in a way nobody can query.
| Symptom | What is missing | Fix |
|---|---|---|
| "We know the total, not who" | Records without a customer or user attached | Link every transaction to an account |
| "We can't see what changed" | Values overwritten instead of stored as history | Keep status changes and dates as rows |
| "It's in someone's spreadsheet" | A process that runs outside the system | Move that step into the app |
| "Two systems disagree" | No agreed source of truth | Pick one owner per number, sync the rest |
Fixing these is ordinary development work: a few columns, an event log, a sync job. It is also the part that makes everything after it cheap. A dashboard on top of bad data only shows the wrong number faster.
Three ways to get answers
Once the data is there, there are three common ways to put it in front of the people who decide.
Fixed reports and dashboards. Best for the numbers someone checks every week: cash, pipeline, workload. Cheap to run once built. We cover this in why dashboards beat manual reports.
A BI tool on a copy of the data. Metabase, Power BI or Looker Studio on a read-only replica. Good for analysts who want to explore. Needs someone who knows the data model.
Plain-language questions through an AI assistant. Managers ask "which customers paid late twice this quarter?" and get an answer from the live system. Good for the one-off questions nobody built a report for.
Most businesses end up with the first and one of the other two. The mistake is buying the tool before the data is right.
How the Meraki setup works
Meraki is a web and desktop platform for a children's language school. It handles lessons and voice exercises with AI pronunciation scoring, subscriptions and payments, and a front desk wired to a time clock and a receipt printer. Since September 2025 it has recorded more than 150,000 learning sessions.
On top of that we built an MCP server. MCP (Model Context Protocol) is an open standard that lets an assistant like Claude call tools in your software. Meraki's tools let super-admins, signed in over OAuth, read students, groups, payments, dues and progress, and make the changes an administrator would make in the admin panel.
Two design choices matter for anyone copying the idea:
The assistant uses the same rules as the app. It calls the platform's own actions, with the same permissions and validation. It never gets raw database access.
Only the people who should see the data can ask. Access is limited to super-admins and goes through the same login as the platform.
The full build is in the Meraki case study, and the wider question of what AI can do inside an existing product is in adding AI to an existing platform.
What it costs, roughly
The cost follows the chain above. Fixing what the software records is usually the largest part, because it touches the core flows and needs tests. Dashboards on clean data are quick. A BI tool costs a subscription and some setup. An MCP server on top of an app with clear actions and permissions is a modest project; on an app where the logic is scattered across controllers, it starts with cleanup.
We check which of these applies before we quote. If your data already lives in a tool with good reporting (your accounting system, your CRM), the right answer may be to use that tool's reports and build nothing.
Where to start this month
List the five decisions and who makes them.
For each, name the number and the system that should hold it.
Try to produce each number from that system today. Note where you had to use a spreadsheet.
Those gaps are your first project.
Next step
Bring your list of decisions to an intro call. We will tell you which numbers your current systems can already give you, what is missing, and the smallest change that closes the gap. Book an intro call.