Why analytics tools that only read data are failing the people who use them
The first dashboard I ever built taught me everything I needed to know about why BI tools disappoint. But I’ve seen the pattern over and over again since then.
I managed pricing strategies for a large region of hotels and spent a lot of time working with each of them on their approach. This dashboard pulled information from several different sources: occupancy trends, competitive set rates, rate optimization, channel mix, the works. Beautiful visualizations. Real insights. The hotel owners loved it.
And then came the obvious next question: “Okay, so what should we do about this?”
That’s when I realized I needed something the dashboard couldn’t give me. I needed a way to turn analysis into recommendations. A place where the hotel and I could agree on specific actions. A system to track which recommendations they accepted, which ones they implemented, what outcomes we expected, and whether those outcomes materialized.
In other words, after creating my first dashboard, I needed my first data app. I just didn’t know that’s what it was called.
Display-Only by Design
The problem with most BI tools: they can only read. Tableau, Power BI, Looker. They’re designed to display information, not to do anything with it. They incorporate data from lots of different sources. They display it in beautiful, impactful ways that genuinely helps users understand what they should do.
But doing valuable work with data almost always leads to action. You spot a trend, you need to respond. You find an anomaly, you need to investigate. You use a dashboard to get to a targeted list of customers or at-risk accounts, and then you need a way to send that list to other systems where the real action happens. The dashboard got you to the insight. Now what?
At the very least, you need some form of write-back. Ways to manage data related to what you’ve discovered. “We saw these customer issues and investigated them.” “This territory needs rebalancing.” “These accounts are at risk and here’s our response plan.”
The Excel Escape Hatch
This is why Excel refuses to die.
I’ve seen this pattern play out at client after client: someone builds a beautiful dashboard, and the first question a user asks is how to export the data to Excel. Not because they love spreadsheets, but because Excel lets you read and write.
Consider the budget process. In theory, you have sophisticated planning tools. In practice? It’s often just emailing Excel files back and forth across business units, across versions, across weeks of painful reconciliation and scenario comparisons.
One client got tired of this. They built budget inputs and scenario selections directly into their reporting interface, right next to where people were going for the numbers anyway. The process that used to take weeks of email ping-pong collapsed into days of focused collaboration.
This read/write flexibility is exactly why Excel remains so stubbornly popular. But Excel breaks down the moment you need what enterprise tools are supposed to provide: version control, audit trails, real-time collaboration, row-level security, connection to your actual data infrastructure. The moment you take an export, it’s out of date. And you’ve lost the governance that made your analytics investment worthwhile in the first place.
The Duct Tape Era
Some vendors have noticed this gap. They’ve bolted on “write-back” capabilities and “automation” features. Power Automate. Tableau Extensions. Various “embedded analytics” plays.
Here’s the honest assessment: most of these solutions are painful to implement and maintain. They require significant technical expertise, often break when the underlying platform updates, and feel like afterthoughts because they are afterthoughts.
That assumption is incomplete, and retrofitting write capabilities onto read-only architecture creates fragile, frustrating experiences for everyone involved.
Two Paths Out
Two developments are making this better.
First, a new generation of BI tools actually understands this problem. Sigma, for example, has built data apps as a core capability rather than an add-on. Their platform lets you create applications that combine real-time analytics with user inputs, form validation, and write-back to your cloud data warehouse. Finance teams can build budget tracking that flows directly back to Snowflake. Sales teams can update forecasts without leaving the interface. The security, database integration, and governance you already have in place? It all still works, because you’re not exporting anything.
This matters because the hard problems with data apps have always been the boring stuff: authentication, permissions, keeping data in sync, maintaining audit trails. When a platform handles that infrastructure natively, building useful applications becomes dramatically more accessible.
Second, modern development approaches have reduced the effort needed to build custom interfaces. You can now feasibly build data applications using tools like Streamlit, or connect React frontends directly to semantic layers like Cube. What used to require a dedicated development team can now be prototyped in days. If your BI vendor can’t solve the problem, you’re not stuck anymore.
AI Needs Somewhere to Write
Once you start building data apps, you quickly find use cases where AI would help. Not the “chat with your data” interface that vendors have been pitching. Something more practical.
You’re looking at a list of at-risk accounts and you want AI to analyze each one and recommend next steps based on their specific metrics. You’re building a campaign tool and you want it to generate personalized messaging based on customer data. You’re reviewing operational exceptions and you want AI to summarize the patterns and suggest which ones need attention first.
This kind of AI integration requires a platform that can both read data and write results back. If you build an application that generates AI recommendations but can’t capture which ones users accepted, track whether they worked, or feed outcomes back into your analysis, you’ve built an expensive suggestion box.
Data apps are the natural home for this kind of human-AI collaboration. Platforms like Sigma are embedding AI functions directly into their application layer, so you can add text summarization, sentiment analysis, or predictive models as part of operational workflows rather than as a disconnected chatbot experience.
The Real ROI Problem
If you’re frustrated that your analytics investments haven’t delivered the value you expected, consider this: maybe the problem isn’t your data, your analysts, or your adoption programs.
Maybe the problem is that your tools can only show you information without helping you do anything about it.
The organizations getting this right aren’t building better dashboards. They’re building data applications that close the loop between insight and action. They’re designing for the complete workflow, not just the visualization step.
The technology to do this is accessible now. Whether you build on a platform like Sigma that handles the infrastructure natively, or connect your own frontends to your data layer, the read-only era of analytics is ending. The question is what you’ll build when your tools can finally do something.