For questions a dashboard cannot answer on its own
Data Analytics
A dashboard shows what happened, but it rarely settles what a business should do next, and that gap is where most reporting budgets get wasted. This practice builds the analysis layer that closes it, from agreeing what a metric means to modelling a decision that repeats.
How an analytics engagement actually answers something
Metrics definition, exploratory analysis and the models built for a recurring decision.
90 secSample frame · video pending01Before any analysis starts
Not every question deserves a full analysis.
Commissioning a rigorous study for a question that will not change a decision wastes everyone's week. Four questions separate genuine analysis work from a chart someone could sketch by hand.
Would a different answer actually change anything?
If the decision is fixed regardless of the finding, the analysis is theatre. Confirm the stakes before committing analyst time.
Does the definition dispute predate the question?
Analysis built on a contested metric just produces a more confident version of the same argument. Settle the definition first.
Is this a one-off question or a recurring one?
A single answer needs exploratory work. A choice made every cycle deserves a model built once and reused.
Is the underlying data even reliable yet?
Analysis on ungoverned data inherits every one of its problems. Pipeline and warehouse issues need fixing before conclusions can hold.
| Exploratory finding | Decision model | |
|---|---|---|
| Best for | A specific question this quarter | A choice repeated every cycle |
| Shelf life | Answers this one moment | Refreshed and reused over time |
| Effort to build | Lower, tightly scoped | Higher, validated against history |
| Ongoing cost | None after delivery | A review cadence to maintain |
| Failure mode if skipped | A guess stands in for evidence | The same guess repeats every cycle |
02Agreed before any code
The ledger that keeps the work honest
Every analytics engagement fixes the split before work starts: what you bring, what we build, what comes back, and what never leaves your control regardless of scope.
- Your side
You bring
- The conflicting reports and the teams that produce them
- Whatever definitions currently exist, written or assumed
- The decisions that keep stalling on the disagreement
- Our side
We build
- One agreed definition per core metric, written down
- Analysis logic rebuilt against that single definition
- A record of why each definition was chosen
- Your side
You receive
- Metrics that mean the same thing in every meeting
- A documented definition set your analysts can reference
- Confidence that a number will not silently drift
Never leaves you
- Which metrics matter enough to standardise first
- Business judgement about what a metric should measure
- Final approval of every published definition
Where the line sitsDefining a metric precisely is engineering. Deciding which metric the business should actually care about stays entirely a call for your leadership.
03From question to defensible answer
Four stages, each closing on an artefact
Analysis goes wrong quietly when the question was never pinned down precisely. This system closes every stage with something a stakeholder can actually inspect.
Frame the question precisely
Vague business questions get rewritten into something a dataset can actually answer, agreed with the stakeholder before analysis begins.
A question written in testable termsRun the analysis
Statistical checks separate a real pattern from noise, and every assumption behind the finding is written down alongside it.
A defensible read of the dataDocument the result honestly
The finding ships with its confidence level and what would change it, so a leadership team can weigh it accurately.
A finding stated with its limitsHand over what was built
For recurring decisions, the model and its refresh process move to your analysts, so the next cycle does not require calling us.
A model or answer your team owns
04What actually drives the number
Four drivers, not a flat rate card
Analytics work is priced against the question, not a template, because these four factors change the effort by multiples.
Whether metric definitions are already settled
Analysis on agreed definitions is fast. Analysis where every team defines a metric differently starts with a slower reconciliation.
Data reliability underneath the question
Clean, tested pipelines make analysis quick. Untested sources need validation work before any finding can be trusted.
One-off finding against a standing model
A single answer is scoped tightly. A model built to recur needs validation against history and a refresh plan.
How the finding needs to be defended
An internal finding needs less rigour than one presented to a board or used in a regulated decision.
05Evidence and proof
Answers that survived contact with a board meeting.
Analytics proof is a decision that moved, not a chart that impressed. Every record here waits for written client approval before production.
Explore case studies
Three reported versions of one metric became one.
Koru Health had finance, product and clinical operations each quoting a different number for the same metric. A single documented definition ended the meetings arguing about whose number was right.
- Competing metric definitions
- Reduced to one
- Time spent reconciling reports
- Cut sharply
A recurring enrolment decision stopped being a guess.
Pillar Learning made a cohort-sizing call every term with no model behind it. A validated decision model gave the same call a documented, repeatable basis.
- Cohort decisions backed by a model
- Every term since
- Time to produce the recommendation
- Days to hours
We stopped asking whose spreadsheet to trust. The finding came with its own limits written down, which is rarer than it should be.
Sample · pending client approval
06Read this first
When an analytics engagement is the wrong spend
Selling deep analysis to a team that just needs a working dashboard would cost more than it earns us in trust. The exits are marked before the pitch. When the work is justified, it runs on Python and SQL for analysis, with notebooks and version control keeping every finding reproducible.
- Business intelligence
You need the numbers displayed, not interpreted
A governed dashboard layer solves visibility. Analysis solves a question dashboards cannot answer on their own.
- Data engineering
The underlying pipelines are not trustworthy yet
Analysis inherits every flaw in the data beneath it. Fix the pipeline layer before commissioning a study.
Your analysts should own this work directly
If your team has the skills and just needs capacity, extending it internally avoids adding a delivery layer.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped study | The question is specific and time-bound | Priorities and the question itself | Analysis and the finding |
| Delivery pod | Questions will keep arriving over time | Roadmap decisions each cycle | Analysis, tooling, documentation |
| Team extension | Your analysts already run well | Standards and review | Named analysts and continuity |
07Straight answers
Asked before an analytics budget moves.
01How is data analytics different from business intelligence?
Analytics answers a specific question or builds a model for a recurring decision, often as a one-off or periodic exercise. Business intelligence maintains the standing dashboards people check daily. Many engagements use analytics to define what a dashboard should even show.
02Do you need our own data team to be involved?
Ideally yes, because the people closest to the business question catch framing mistakes early. Analysis done entirely at arm's length from stakeholders tends to answer a slightly wrong question very precisely.
03What tools do you use for analysis?
Python and SQL most often, with notebooks kept in version control so a finding can be rerun and checked later. The tool is chosen for reproducibility, not novelty, since a finding nobody can retrace is not worth much.
04Can you validate analysis another vendor or team produced?
Yes, and it starts with checking the assumptions and the underlying data rather than the conclusion. Many disputed findings trace back to a metric definition nobody agreed on in the first place.
05How do you know a finding is actually reliable?
Through stated confidence levels, checks for common statistical pitfalls, and an explicit list of what would change the conclusion. A finding without stated limits is a claim, not an analysis.
06What does an analytics engagement cost?
Scoped studies are priced against how settled the metric definitions are and how reliable the underlying data already is. Standing decision models add a validation and refresh cost beyond the initial build.
07Do you build the models yourselves or teach our analysts?
Both, by design. Your analysts are involved in every review, so the model and its assumptions are understood, not handed over as a black box nobody can maintain.