This is not a proposed final screen. Analytics is excluded from the build order until you run the definition round you own — "what to show and how" — so this sheet exists to make that round something you can react to in one sitting instead of specify from nothing.
Nothing here is a recommendation you have already made. The screen in section 2 is one arrangement, drawn so the choices are concrete. Strike it entirely and the inventory in section 1 is still the useful half.
Two things are already ruled and are obeyed here. Bars, meters, split bars and traffic lights are banned — you restated that independently of the bulk tick — and charts were never banned, which is a claim that only ever existed inside the round-3 analytics sheet's own prose, on the screen you called "horrendous". So: sparklines and figures yes, gauges no.
Three copy defects from the render audit are fixed on sight, whatever you rule: "Connected (CONNECTED)" was a code where a word belongs, dates rendered as raw ISO ("since 2026-07-18") on a screen that writes "26 Jul" elsewhere, and "Whatsapp" appeared twice for WhatsApp.
CostAnswer.costPerLeadUsd
Live. One figure, plus its two inputs.
Lead with it
OutcomesAnswer.automationRatePct, .split, .bySituation
Live. A rate, a three-way split, and the same broken down per situation.
Keep
VolumeAnswer.totalInbound, .byChannel, .dailyInbound, .busiestDay
Live. A daily series and a per-channel breakdown.
Keep
DeliveryAnswer.failureRatePct, .failuresByClass, .metaState
Live, but this is the Dashboard's job today, per channel and in real time.
Overlaps Home
OutcomesAnswer.labels — right, wrong, and since when
Thin. It only becomes a trend once people label for a few weeks.
Say it is thin
CampaignsAnswer — two counts and nothing else
Two numbers with no outcome attached. It cannot say whether a campaign worked.
Cut, or fund it
The payload already knows when it cannot answer. Every question carries
availability: live | thin | empty and a computed reason, so a question
with no data can say why in its own words instead of drawing an empty chart. That is the single
most useful thing about the existing API and the current screen barely uses it.
Every inbound message, by the day it arrived.
Every turn ends one of three ways. No gauge: the numbers are the answer.
From the right and wrong marks people leave on its replies.
Every figure here is a field the payload already returns. Nothing in this
arrangement needs an API change. The "not enough yet" block is the
availability: "thin" path rendered as words, which is the behaviour the current
screen has the data for and does not use.
1. Which questions stay? I have kept 1, 2, 3 and 5, left 4 (delivery) to the Dashboard where it is already per-channel and live, and cut 6 (campaigns) because two counts with no outcome attached cannot tell you whether a campaign worked.
2. Is cost per lead really the headline? It is the only number on the screen that joins
money to an outcome, which is why I led with it. It is also the most fragile: it divides by
leadsCaptured, and if lead capture is inconsistent the figure lies confidently.
3. Does Analytics own "per situation"? bySituation is in the payload and I
have not drawn it. It is the most genuinely analytical thing here and it is also a second home
for something Behaviour arguably owns.
4. What is the time range for? I have drawn 30 / 90 days / this year. If nobody ever looks past 30 days, the control is furniture and should go.