DASHBOARDS & GRIDS
Delivered analytics vs self-serve BI
Self-serve BI hands the team a tool and asks them to build. Delivered analytics hands them the dashboards, configured to the business, ready to use.
- Anyone can build any report, in principle
- Someone has to learn the tool and model the data
- Two people build the same report two ways
- The queue moves from engineering to the power user
- Dashboards and grids configured to the business, ready on day one
- One definition per metric, shared by everyone
- Changes requested, not built
- A brand-new report shape waits for the next configuration
Two promises
Self-serve BI promises that anyone can answer their own questions: here is a tool, connect it to the data, drag the fields, build the chart. Delivered analytics promises something narrower and, for most teams, more useful: here are your dashboards, configured to how your business works, open them. The first hands over a capability. The second hands over the result. Which one a team needs depends on whether it wants to build or to use, and most teams, asked honestly, want to use.
What self-serve asks of a team
Someone has to learn the tool. Someone has to model the data - which tables, which joins, what "order" means - and keep the model current as the systems change. Someone has to build each report, and when two people build the same report, they build it two ways. In practice that someone becomes one or two power users, and the queue that used to sit with engineering now sits with them. The tool was meant to remove the bottleneck; it moved it. Reports that need engineering is the queue it was supposed to fix.
There is a second, quieter cost. When each report is built by whoever needed it, the organization accumulates reports nobody can explain. Six months later a number on a slide traces back to a workbook a departed colleague built, with a filter nobody remembers choosing. Self-serve creates this by design, because building is distributed and documenting is not.
What delivered analytics gives
Dashboards and data grids configured around the business before anyone opens them: the sales overview with its KPIs and period comparison, the orders grid with guided filters and saved views, access scoped by team. One definition per metric, built into the configuration, so sales and finance see the same number. When the business needs a change - a new filter, a new widget, a new grid - it is requested and configured, not rebuilt by whoever has time. The team's effort goes into reading the numbers and acting, which is what it was hired for.
Delivered does not mean static. Filters, click to focus, period comparison and saved views give each person a working surface over the configured dashboards; what is fixed is the definition of the numbers, not the way of looking at them. The regional manager still narrows to her region and saves it; she just does not have to decide what counts as an order first.
Side by side
| Criterion | Self-serve BI | Delivered analytics |
|---|---|---|
| Who builds the dashboards | The business team, after learning the tool | The provider, from your requirements |
| Time to first useful dashboard | Weeks to months, plus training | At deployment |
| Definitions | Per authorTwo people, two versions of revenue | Set once, shared |
| Changing a dashboard | Someone rebuilds it | Request the change; it is configured |
| A brand-new question | Build a report, if you can | Ask the assistant, or request a widget |
| Data modelling | Your team, in the tool | Done in the indexed layer, once |
| Ongoing cost | Power users' time, licences per builder | A configuration relationship |
| Fits when | A data team wants to explore freely | Business teams want to use, not build |
The fastest way to tell the two apart in a demo: ask who built the dashboard you are looking at, and who will change it next month. If the answers are "a power user" and "the same person, if they have time", it is self-serve wearing a finished coat. If the answers are "configured to our requirements" and "we ask", it is delivered.
The one-off question
Self-serve's strongest argument is the question nobody anticipated. It is a real need, and delivered dashboards alone do not meet it. But a self-serve tool meets it only for the person who can build a report, which excludes most of the people who have questions. A conversational assistant over the same indexed data meets it for everyone: ask in a sentence, get a chart or a table, ask the next thing. Delivered analytics for the recurring questions, an assistant for the new ones, and the self-serve tool's job is done by two things that need no builder. Dashboards vs chat draws that line.
The cost comparison is usually framed as licences and is really about time. A self-serve rollout is paid for in the hours of the people who learn, model and build, which are the hours of the people the business can least spare, and the bill arrives again every time the data changes. A delivered rollout is paid for in a configuration conversation: what do you need to see, by whom, how often. The second is a smaller number and, more importantly, a predictable one.
When self-serve fits
A data team that explores for a living, has the modelling skills, and wants to build its own views over a warehouse: self-serve BI is built for them, and a delivered product would frustrate them. The mistake is buying that experience for a sales team or an operations desk, who will use three dashboards and a grid for years and never want to build a fourth. Match the model to the team, and expect the answer to differ between teams in the same company. For most of the business, delivered is the model that gets used, because using is the job.