Consulting Work About Book Writing Contact

A Smarter Q&A for Power BI, Built From Scratch

Power BI ships with a natural-language Q&A feature. You type a question, it reads your data model, and it answers. It is a genuinely good idea, and on paper it is exactly what a lot of report users say they want. In everyday use, though, it tends to disappoint, and the reason is worth unpicking.

The native visual answers questions with visuals. Ask it something and you get a chart, a table, a card. That is fine when you are exploring, but it is the wrong shape of answer for most of the questions people actually put to a report. If someone wants the average cap rate for a neighbourhood, they want the figure, not a bar to read off by eye. If they want the five biggest deals by value, a tidy ranked list of names and numbers beats a column chart they then have to decode.

I ran into exactly this on a commercial real estate analytics project. The model was solid, the reports were quick, everything behaved. But the moment someone wanted a fast, conversational answer, the built-in Q&A simply did not feel intuitive to the people living in those reports every day.

So I built something narrower, and better

Instead of the open-ended native tool, I wrote a small custom visual that behaves like a focused Q&A panel. It does not take freeform typing. It offers a curated dropdown of the questions people genuinely ask of this data, and when you pick one it works the answer out from whatever is currently filtered and returns it as clean, readable text.

It is deliberately compact. A slim dark header with a collapse toggle lets it sit in the corner of a page without fighting the rest of the layout. Under that, the dropdown. Under that, the answer, with bold names where they help, currency formatted properly, and a line of context so the number is not left floating on its own.

The questions are written for the dataset in front of it. On that real estate platform they included things like the top five transactions by value, the average cap rate, average price per square foot and per buildable square foot, the total transaction count, and volume broken down by property type. Each one is wired to its own small computation that filters, sorts or aggregates and hands back a sentence.

Why the smaller idea wins here

Three things make the difference, and none of them is really about looks.

It answers in words. Ask for the average cap rate and you see the percentage and how many transactions it rests on. Nothing to interpret, nothing to hover over. For a specific question, a chart is just an extra step between you and the answer.

The questions are known. Freeform language sounds liberating until you watch ten people phrase the same question ten ways and the engine guess wrong on three of them. A fixed set removes that doubt entirely. Each question maps to one computation, so the answer is the same every time, and it is right every time.

I control how it looks. The native visual gives you very little say over styling. This one I can make match the report exactly: the header, the dropdown, a card for a single figure, a numbered list for a ranking. It reads as part of the dashboard rather than a guest on it.

There is also nothing external in the loop. Every answer is worked out locally from the data Power BI already hands the visual. No API, no service to call, no round-trip to the internet. That means no latency, no cost per query, and no chance of a model returning something unexpected. Same data, same filters, same answer, every single time.

And because it is a proper visual, it reacts to slicers like everything else on the page. Choose a borough, a date range, a property type, and the answers move with the selection. Nothing to re-pick, nothing to refresh.

One last practical point: it is a native TypeScript custom visual built on the Power BI Visuals SDK, so it runs wherever Power BI runs, from Desktop to the Service to Publish to Web, and embedded surfaces including Salesforce. No special cases.

The part that took the real work

The interesting engineering was in handling data at scale. Custom visuals receive their data through a dataView, and by default that arrives in a fairly small slice. On a dataset of several thousand transactions, that is a quiet trap: your average ends up computed on a fraction of the rows.

I dealt with it by having the visual pull data in larger windows and keep asking for more until Power BI confirms there is nothing left, and only then compute. So a count is a real count and an average is a real average, not a number drawn from whatever happened to load first.

It also de-duplicates at the row level. In plenty of real models the same transaction appears across several rows because of the relationships around it. The visual groups by a unique transaction identifier and averages the numeric fields, mirroring what a well-written DAX measure would do in the model itself.

Why I keep coming back to this

Most people reading a report are not analysts. They open it, set a couple of filters, and want a clear answer in plain language. A small Q&A panel with a curated question set fits that behaviour almost perfectly. It is quiet, it takes up little room, and it gives back exactly what was asked.

It is easy to grow, too. A new question is just another computation mapped to the right fields, and reordering or removing them is trivial. The set evolves with the business.

I first built this for commercial real estate, but there is nothing real-estate-specific about the idea. Any dataset with well-defined KPIs and a handful of questions people ask on repeat is a candidate: retail, finance, healthcare, logistics. The structure stays the same. Only the questions, and the sums behind them, change.

If your reports could do with a calmer, clearer way to surface the numbers people keep asking for, that is the kind of problem I enjoy. Get in touch and tell me what your team keeps asking their dashboards.

← All writing