Jovis AI
Self-service analytics was supposed to let business teams answer their own questions. Many companies instead ended up with a larger dashboard library, a more complicated BI tool, and the same queue of requests to the data team.
The promise failed because access to charts was treated as access to understanding. A chart can show that conversion fell. The decision owner still needs to know which segment moved, whether the definition changed, which accounts explain the difference, and what happened around those accounts. Those follow-up questions are where most operational analysis begins.
The better replacement is not unrestricted access to every table or a chat box attached to a warehouse. It is governed exploration: a way for people to pursue ordinary follow-up questions using agreed definitions, approved sources, visible evidence, and clear access boundaries.
Why the dashboard version of self-service reached a ceiling
Dashboards work well when a team knows the question in advance. A data team can agree on a metric, model the data, create a view, and give everyone a stable place to monitor it. That is valuable infrastructure.
Investigation is different. Consider a customer-success leader who notices that enterprise renewals weakened. Their next questions depend on the first answer:
- Is the decline concentrated in a region, product, or contract size?
- Which accounts account for most of the change?
- Did product usage or support activity change before the renewal outcome?
- Are those signals unusual relative to comparable accounts?
No practical dashboard can anticipate every branch. Adding more filters often shifts complexity to the user without giving them the definitions or context needed to interpret the result. Adding more dashboards creates discovery problems and conflicting versions of the same metric.
This is why a company can have broad BI access and still depend on a data-team request queue. The bottleneck is not always permission to view a chart. It is the work required to translate a business question into the right sources, joins, definitions, and comparisons.
Diagnose the failure before replacing the tool
“Low adoption” is not a sufficient diagnosis. Look at where people stop.
They cannot find the right starting point
If five dashboards contain a version of pipeline, a sales leader must already know which owner, refresh schedule, and filter set apply. Search and catalog improvements can help, but the deeper issue is a weak contract around which asset answers which job.
They do not share the same definitions
Terms such as active customer, qualified opportunity, and resolved ticket sound obvious until two teams calculate them differently. A self-service interface cannot repair an unresolved business definition. The meaning needs an owner and a governed implementation. A semantic layer for AI agents can make those metrics and entities available consistently, but the organizational agreement still comes first.
The answer cannot cross system boundaries
An operational question often spans a CRM, billing platform, product events, support records, and internal documents. A dashboard designed around one subject area may identify the movement without explaining it. The user returns to screenshots, spreadsheets, and requests because the relevant context remains fragmented.
People cannot inspect how the result was produced
A fluent answer is not self-service if the reader cannot see its period, filters, definition, and supporting records. Without that path, a cautious user asks an analyst to verify it; an incautious user may act on a misunderstood result. Neither outcome reduces the data team’s burden safely.
Build self-service around a defined business job
Start with a repeated question that has a real decision attached. “Let everyone analyze data” is too broad. “Help customer-success managers identify onboarding accounts stalled at a required step and decide who should intervene” is specific enough to design.
Write down five parts of the job:
| Design question | Example |
|---|---|
| Who asks? | Customer-success manager |
| What starts the investigation? | Weekly onboarding review or a threshold breach |
| Which sources are approved? | CRM, onboarding events, support cases |
| Which definitions matter? | Stalled account, required step, enterprise customer |
| What decision follows? | Assign outreach, fix a process, or continue monitoring |
This scope makes access easier to reason about and evaluation more meaningful. It also gives the data team a finite foundation to maintain.
Separate the foundation from the investigation
The data team should still own the hard reusable layer: reliable source models, metric definitions, identity resolution, quality checks, and access policies. Business users should not have to reproduce that logic with every question.
The investigation layer should let an authorized person ask a follow-up in business language, refine it, and inspect the evidence. This is where a governed AI agent can help. The agent needs a defined job and bounded context; it should not be treated as a universal analyst with unrestricted access.
That division changes the data team’s role from answering every question to building and improving the system through which routine questions are answered. Complex analysis, new metric design, and high-stakes decisions still deserve specialist attention.
Evaluate whether the new approach is actually self-service
Do not measure success by logins or prompts alone. Test complete question-to-decision paths.
Choose ten representative questions from a real team and record:
- whether the user reached a usable answer without an analyst taking over;
- whether the answer used the agreed source and definition;
- whether the user could inspect the supporting context;
- how often permissions correctly blocked unavailable data;
- whether the investigation changed or confirmed a decision;
- which questions still required expert analysis.
Include ambiguous and adversarial cases. Ask what happens when a term has two meanings, a source is stale, an account lacks an identifier, or the user requests data outside their role. The goal is not to make the system answer everything. It is to make its useful boundary predictable.
The access-control principles in NIST’s guidance on least privilege provide a useful baseline: give a user or process only the access needed for its assigned task. Applied here, that means each workflow should use the smallest practical set of approved business sources rather than inheriting broad warehouse access.
Keep dashboards, but give follow-up questions somewhere to go
Dashboards remain the right tool for shared monitoring, recurring scorecards, and stable comparisons. The mistake was expecting them to support every branch of discovery. The practical model is a stable monitoring surface paired with a governed path for exploration.
Before adding the next dashboard, collect the questions people ask immediately after seeing the current one. Group the recurring questions by decision, source, and owner. One of those groups is a better pilot for self-service than a company-wide rollout.
Self-service succeeds when a person can move from a signal to a well-supported decision without rebuilding business logic or waiting in a queue. That requires more than an interface. It requires the definitions, permissions, sources, and evidence that make exploration safe enough to become routine.