Reports and dashboards
A normal CRM gives you charts. The useful part is where they read from.
Reporting here runs on the same PostgreSQL database the records live in. There is no separate analytics store to copy data into, which means there is no sync to fail, no lag to explain and no second version of the truth to reconcile in a meeting. On top of that sit report templates you can start from, dashboard widgets that open into the records behind them, saved views that arrive on a schedule instead of being remembered, and product analytics over what you actually sell.
How it works
What you get beyond a chart
Three things, and the reason the first one matters is the second.
Templates to start from
A library of report templates, seedable, each of which becomes a real report you own and can change. Nobody should have to invent a pipeline-by-stage report from an empty query builder.
A number you can open
A dashboard widget carries a drilldown: it declares what a click on it should query, so a figure opens into the records that produced it. That is the difference between a dashboard that starts an argument and one that ends it, and it is the usual reason a reporting screen gets abandoned in favour of an export.
The list that arrives instead of being remembered
A saved view can be put on a schedule and sent to you on a chosen day and hour. Each send is claimed against a ledger before it goes out, so a scheduler that runs twice does not mean the list arrives twice. Most weekly reporting is one person opening the same filtered list every Monday, and this is aimed squarely at that.
In the product
The library, before anyone builds anything.
The mechanism
What is actually in the reporting layer
“Reads the live database” is the architectural claim. These are the four things built on top of it, and each exists because a number on a screen is only useful if somebody can get from it to the rows underneath.
Reading the records directly is a decision, not an absence
A report is a filtered, grouped, aggregated query against the same tables the application writes to. That is the entire architecture, and stating it as a positive is fairer than stating it as a lack: there is nothing to extract, nothing to load, nothing to schedule overnight, and no window during which the dashboard and the record disagree. The trade is real and worth naming too — a query over live records competes with the application for the same database, which is the reason this suits an operating business asking about this quarter rather than an analyst asking about seven years.
A drilldown is what makes the number arguable
Each widget declares what a click on it should query, so a figure opens into the rows that produced it. That is the whole difference between a dashboard somebody trusts and one they quietly rebuild in a spreadsheet, because the first question anybody asks a surprising number is which records are in it — and a dashboard that cannot answer that gets one use.
The number reaches people by being sent, not by being framed
For the people who will act on a figure but will never log in to find it, the route is a saved view on a schedule: your filtered list, on the day and hour you chose, claimed against a ledger before it sends so that a scheduler running twice does not deliver twice.
It is worth saying what that is instead of. A dashboard is read inside MADDOX. An embed token can be minted, named and revoked in the settings, but nothing in the product serves an embedded dashboard to an outside page today — so it is not a way to put a live figure on your intranet, and this page is not going to describe it as one. Publishing a dashboard outward is honest future work rather than a feature you would be buying.
Product analytics is recalculated when you ask, not assumed
Analysis over what you actually sell — which products move, which do not — is recomputed on demand rather than carried forward from whenever somebody last looked. A stale figure that looks current is worse than an obviously old one, and recalculating on request is the cheapest way to never have the first kind.
Who it is for
For the person who gets asked for the number
Usually at short notice, and usually by someone who will act on it.
- A sales operations lead maintaining the weekly pack.
- An owner who wants the list to arrive rather than to be remembered.
- Anyone who has been asked where a number came from and had to go and find out.
- Anyone who has been asked why two dashboards disagree.
Related
Questions
The things people actually ask.
Where does reporting read from?
The same PostgreSQL database that holds your records. There is no separate analytics engine in the product and no copy of your data to keep in step.
Is there a lag?
There is no pipeline to lag. A report reads the records as they are; the only delay is the query itself.
Can I get from a number to the records behind it?
Yes. A dashboard widget carries a drilldown, so a figure opens into the rows that produced it rather than asking you to take it on trust. It is the first thing anybody wants from a surprising number.
Can a dashboard appear outside MADDOX?
Not today, and we would rather say so than let a settings screen imply otherwise. An embed token can be created and revoked, but nothing in the product currently serves an embedded dashboard to an external page. The way a number reaches somebody who will not log in is a saved view on a schedule, which sends them the list itself.
What is product analytics?
Analysis over what you sell — which products actually move — recalculated on demand rather than assumed from the last time somebody checked.
Open a template and change one thing.
That is usually the whole distance between a chart and a decision.