Where a finding usually dies
A BI tool that stands on its own ends at the chart. Someone spots the deviation - and then leaves. Into a messenger to ask whose it is. Into a task tracker to assign it. Into a third system to do something about it. Each hop loses context, and each hop is somewhere the finding can stop: the person who could explain the number never sees the question, the task is filed without the figure that justified it, and by the time anyone checks, the report has moved on.
None of that is anybody's fault. The tool that found the problem has no idea what the company does about problems. It cannot see the request queue, it does not know who owns the region, and it has nowhere to put a decision.
That loop is the whole point.
What you can do from a screen with a number on it
- Discuss it where the data is. Comment threads hang on the dataset, on the project, on a range
of cells in a spreadsheet, and on a task in a process - with
@-mentions that reach the person through email, Telegram or Slack instead of hoping they open the right screen, plus an inbox of their own mentions and a badge when something is waiting. - A thread is a working record, not a chat box. Reactions, quoting and replying, edit history, attachments, and resolve-and-reopen - so "we decided this in March" is a question with an answer.
- See what happened to the data. Datasets and projects carry an activity timeline: who changed what, and when. A number that moved has a history, not a rumour.
- Put the work on the same screen. A live task board from a process is a widget like any other, so the open requests and the money behind them are one screen instead of two systems and a guess about how they relate.
- Act from the page. A form that files a request, a button that runs an agent action, a command palette - the page where the number is can be the page where something starts.
- Ask on the spot. A chat with an AI employee is itself a widget, so the follow-up question does not need a different tab either.
No analytics over your systems
Analytics has always been a layer over the systems where the work happens: a BI stack pointed at the CRM, at Jira, at whatever the project office runs on, connected to them and permanently one export, one sync and one argument about definitions behind them.
Here there is no "over". The CRM, the request queue, the price list and the project portfolio are apps on this platform, and the analytics is inside them, reading the same records at the moment they change instead of a copy taken last night. There is nothing to integrate, because there is nothing separate to integrate with.
That is a claim about apps built here, so the boundary matters: a system that stays outside is connected as a source, and everything on Connect data that already exists applies to it. Once the work itself moves onto the platform, the analytics does not have to be pointed at it, because it is already there.
What it looks like in practice
| The finding | What happens next, on the same screen |
|---|---|
| Margin in one region is below plan for the third week | The thread is on the dataset, the regional manager is mentioned and answers where the figure is, not in a separate chat |
| A batch of requests has been sitting unassigned | The task board is a widget on the dashboard; the work is picked up from the screen that showed the backlog |
| A price looks wrong on a product line | A form on the same page files the change request, and it goes down the approval route it is supposed to |
| Nobody can remember why the target was moved | The activity timeline says who changed it and when, and the thread says why |
See it built
Sales CRM · project portfolio · corporate portal · price management · your own