Vendors

The vendor is the paying subscriber: they source leads, own the customer relationship, and read the dashboard the platform reports back to them. See Reading the tables for the conventions.

Capabilities

Vendors read the full tenant, not a filtered slice — lead.view, milestone.view, invoice.view, csat.view and activity.view are all held at full scope, the same as a manager. What they do not hold is anything on the requirements or bidding path: no brd.view, no proposal.view, and no write on a lead beyond sourcing it. The dashboard is a reporting surface, so expert.rate is the vendor’s only write on delivery.

Every vendor figure reads the whole organisation. The dashboard, the figure pages, the customer pages, the KPI dictionary and the vendor assistant count every lead, satisfaction response and invoice in the tenant — whichever vendor seat it is attributed to, or none — so they agree with /csat and every vendor seat sees the same numbers. Nothing from another organisation is ever counted.

A seat with narrowed access sees no figures. If an administrator narrows a vendor seat’s lead.view, csat.view or invoice.view to its own records, or removes one (through the role template or a per-user override), that seat is told its organisation’s figures need full access: the Command Centre and the KPI dictionary show a notice in place of every figure (the definitions stay), the figure pages and customer pages are not found, and the vendor assistant offers only the lead book, narrowed to the seat’s own leads.

There is no vendors table in the platform. A vendor is a tenant, and the vendor-facing list of their customers is /vendor/figures/top-customers — every customer with a lead in the range. A customer’s own page, /vendor/customers/<id>, opens from the Customer health figure page (its register, the at-risk bridge and the customers carrying no score), on the range the reader is on: the customer’s Revenue at Risk is read from that customer’s own Service delivery risks signals on that range and names it, so it equals the customer’s Project value on the Command Centre on the same range. Tenant administration lives under Roles → Admin.

Surfaces — the Live Service Command Centre

Every one of these is an explicit vendor-only route: the dashboard cards click through to them, and no other role — admin included — is on the list.

The Command Centre opens on three figures: Active Service Revenue, Revenue at Risk and Forecast Service Revenue. Active Service Revenue opens to its active projects — a register titled “Active projects” with Project ID, Project, Customer, Project owner, Status, Date approved, Days since approval and Delivery due date columns, every amount in its footer named — each with its % delivered (delivered over contracted, a whole percent) and, right after the customer, a Risk level chip — its customer’s Service delivery risks level, High, Medium or Low by how many of the four signals the customer trips (three or more, two, one), the signals named on hover or focus, blank when the customer is not flagged — on the same projects Revenue at Risk lists; Revenue at Risk’s own register (“Projects at risk”) shows % delivered too, and its sub-figures read Projects at risk, Customers, Percentage of Active Service Revenue at risk and Overdue invoices. Forecast Service Revenue — the tile’s line reads “Revenue expected to convert” — opens to every project added in the range that is still open, each with a Pricing status: Estimated, valued from the day the project enters at its service’s Price Book list price (a monthly price counted as one month), or Expert priced, valued at the customer price of the selected expert’s quote. When the customer approves the price the project is Approved: it leaves the forecast and counts in Active Service Revenue, which keeps its name. A lost project is not listed either. Its table is “Forecast projects”, with a project’s ID, customer, source, description, service type, BRD status, owner, Pricing status, package price and expert price, and a Pricing status filter beside the others; the headline counts the Estimated and the Expert priced projects, and its money is the sum of each project’s value by its status — the footer foots that forecast value to the headline, a project with no price shown as not yet priced. The customer’s stated budget plays no part in any figure: before an expert quote counts, every project’s value on the board, its workspace and Service Pipeline Value is its service’s list price, and expert quotes are averaged there as before while the forecast keeps such a project Estimated. The Price Book itself sits under the table; a service priced outside the organisation’s currency keeps its price there and is marked “Not in GBP — left out of the forecast” (in the organisation’s own currency code). The button in the page header reads “View Service Pipeline”. The page speaks of projects throughout, never leads or a cohort — the vendor’s word for the record on that page and in its KPI dictionary entry. Its two sibling pages read the same way: Revenue funnel’s table is “Funnel projects” and Revenue lost before go-live’s is “Lost projects”, each listing a project’s ID, description, customer and owner, the day it was added, and how many days since it was added or until it was lost; their dictionary entries say “project” too. Revenue lost before go-live names its previous column as Forecast Service Revenue does. Every figure page returns to the Command Centre.

Revenue at Risk is the money of the Service delivery risks card beneath it: the value still to deliver (contracted less what the customer has acknowledged as delivered) on the active projects of every customer that card flags, read over the same range and as of the same moment. Its dictionary entry, and the Revenue at Risk page’s empty states, bridge and reconciliation, say “active projects” too. When eight or fewer customers are flagged it is exactly the total of the card’s Project value column. Each value is rounded to whole units only for display (the figure once, each row on its own), so where values carry pence the displayed column can add up to a pound or so either side of the figure. The card lists at most eight, and says “8 of N customers” when more are flagged, all of whom the figure counts. Its line reads “Projects at risk: N” and its share of Active Service Revenue. It says why under its number: one line per engagement at risk, naming the customer, that customer’s Why sentence from the card (every signal it trips), and the engagement’s own oldest open delivery blocker (with how many more are open). The three largest are shown, and “and N more” opens the figure page, as does “See why it is at risk”. The lines are the engagements the figure counts, so they never change the number. The figure page follows the range it was opened with, states Projects at risk, Customers, Share of Active Service Revenue and Overdue beside its headline, and reconciles Active Service Revenue down to it: less the projects not at risk, less what is already delivered on the projects at risk.

Below the three figures the cards run in the order the story is told. First comes Service Delivery Risks, one card with no group heading above it: the customers showing an SLA breach, a delivery running past its SLA, CSAT below 4 out of 5 or work open over 30 days — project-level delivery risks, not retention risks. Each row gives the customer (the first column reads Customer), why in one plain sentence (every signal it trips, then its oldest open delivery blocker, with how many more are open), its project value (what is still to deliver on its work in flight, read from Active Service Revenue’s engagements and so in the same currency), a High, Medium or Low risk level (three or more signals, two, or one), and its owner. It lists the eight customers with the most value still to deliver; a customer flagged only on finished work has none and comes last. Revenue at Risk above it is the total of that value over every flagged customer, and the card opens the customers list. Then, under short group headings: Work entering service (the revenue funnel and the revenue lost before go-live), Activation and retention (service activation rate and customer retention), Experience and health (customer satisfaction and customer health), and last, with no heading of its own, Top customers. Revenue at Risk appears once, as its headline figure.

Every card states its name, one number and one line of context — the arithmetic, the caveats and the records behind the number are on the figure page it opens. Every card on the dashboard has exactly one destination and none is a dead end, and every card explains itself. The question mark beside each card’s name — pressed with a click, a tap, or Enter or Space — states in one line what its figure counts, read from the KPI dictionary rather than written on the card, with a Read the definition link through to that metric’s own entry at /vendor/metrics. A card that summarises records rather than a single metric says what it summarises and offers no link — the dictionary has no entry for it — and so does a metric card whose entry the dictionary did not return. Each figure has one name: the card, its popover and the <h1> of the page it opens all state the same words, and every card’s footer link reads See the breakdown — except the cards whose footers name what their page lists: the three headline tiles, View projects in service (Active Service Revenue), View projects at risk (Revenue at Risk) and View forecast projects (Forecast Service Revenue), and Service delivery risks, whose View all customers opens Top customers. The dashboard header states the moment the figures were read once, for the whole screen — “As of today · 15 Oct 2026, 07:13 BST”, or “As of 3 Oct 2026, 18:00 BST” when the page is read as at a past moment — and the range control beside the title states the reporting range. The subtitle never leads with the range: the headline tiles are stocks as at the read, not totals over it. A card whose figure is read over a different window says so on its own face.

Go-live blockers are not on this dashboard. Following them up is the delivery team’s work and a vendor manages no figure about them, so a blocker waiting on the vendor reaches them by the project thread and an in-app notification instead — see Delivery → Project messaging.

Surfaces — shared

/vendor/figures/<figure> is one route covering every drill-down page behind a dashboard card. Twelve exist:

Each reads number, table, chart: the figure and its sub-figures, then a register of the records behind it that adds up to the figure, then — where the figure is a current one — a bridge explaining how it moved since the start of the selected range. Where the figure is a period total or a cohort instead, that last part is the range set against the equivalent previous range, or the cohort’s own progression; the page says which of the three it is showing. On Forecast Service Revenue and Revenue lost before go-live the previous range is named for the span it covers: “Previous 30 days”, “Previous quarter” after Last quarter, “Previous year” after a whole fiscal year, “Previous 19 days” (the window’s own length, rounded up) after a range that runs to date such as This quarter or Year to date — the comparison is the equal span just before, not the calendar period — and “Previous period” for a reader who arrived from the KPI dictionary. That last part keeps its chart and each movement’s total on view, with one line of reconciliation under the chart; each movement’s records open on demand, closed on load, since the register above already lists them. The headline card states numbers only — the figure, one tag naming its kind (Current · as of today, Period total · <range>, Projects added <range> (such as “Projects added in the last 30 days”), Mean · as of today or Rate · <range>; a page read as of a past moment names its day in place of “today”), its change where the page measures one, and the sub-figures. Two pages print a plain line in place of the tag: Active Service Revenue reads “Current active service revenue” and Revenue at Risk reads “Current service revenue at risk”, the same whether the page is read now or as at a past moment, since the header states that moment; their popovers still say each is a current figure, never added to a period total. The definition and the sentence on how to read it open in a popover from the help button beside the figure — on a press of the button (a click, a tap, or Enter or Space), never on hover, focus or the figure itself; it stays open until the reader closes it — with “Read the definition”, reachable by keyboard, leading to the figure’s dictionary entry; what the figure leaves out is stated in the register’s footer, beside the footing it qualifies. The page header states the range once — as its range control, beside the as-at stamp — and nothing else about it: Customer retention’s period dates, day boundaries and timezone notes open in its figure’s popover, and Customer health’s score parts and bands open in its own. The calculation is not printed on the page: a “How this is calculated” link under the headline opens the figure’s own entry in the KPI dictionary (/vendor/metrics?metric=<id>), where those words live once. Revenue at Risk’s page leads with why: directly under the headline, every flagged engagement on one line — the customer, every flag and its oldest open blocker, the tile’s lines in full and worded the same — each opening that engagement’s workspace; its “How this is calculated” link follows that list, then the register and the bridge. The other personas’ figure pages, whose figures have no dictionary entry, keep the same words in a closed “How this is calculated” section at the foot of the page. They are reporting surfaces only: nothing is created, edited or approved from one, and a row hands over to the record’s own page.

The funnel, pipeline drop-off, service-quality, CSAT-by-revenue and renewal-risk pages that used to sit at /vendor/funnel, /vendor/pipeline, /vendor/health, /vendor/csat and /vendor/renewals folded into these and no longer exist: one card, one destination. So did the customer list at /vendor/customers, which restated the Top customers card’s ten rows; the address now redirects to /vendor/figures/top-customers, and the card reads the same records that page itemises, so its figures and the page’s rows cannot disagree. The renewal-risk page mattered most: it ran a second risk read with its own banding beside a figure built from the health metric’s verdicts, so the two could disagree about the same customers on the same day.

Reading as at a past moment. The Command Centre and every figure page accept ?asAt=<ISO instant> and are then read as they stood at that moment: each figure counts a record only from its own timestamps — a status from the lead’s history, an acceptance, a payment or a survey response from its own stamp — and the selected range’s window ends at the moment. A value with no history of its own (a list price, a due date, an owner) reads as it is now, and a state with no timestamp is never assumed. The header’s stamp names the moment, and every link between the Command Centre and its figure pages, and the range selector, keep it. A date control beside the range selector sets it: a picked day reads as at the close of that day in the tenant’s business timezone, only past days can be picked, and Today clears it — the range is kept either way. While a moment is set, a banner above the figures states it (“As at the end of 3 Oct 2026 (CEST)” for a picked day, the header’s to-the-minute stamp for any other instant), links back to today, and adds “Some figures could not be read for this moment” when a figure read on the page failed, so an empty card is not taken for “nothing had happened yet”. The address still works on its own; an absent or malformed value, a time without a zone, or a moment still to come reads as today. A narrowed seat sees neither control nor banner. Where the guided walk runs, the control is hidden and the banner has no way back to today, so the presenter stays on the step’s moment; the walk opens on the Command Centre as at the moment before its hero lead arrived, so its last step can compare the dashboard with today.

A rate page is that same anatomy over two counts: the register lists the whole population, each member marked in or out of the numerator, and the bridge itemises what entered and left the numerator rather than what was added to a total. satisfaction carries the average and its revenue-weighted twin together, and replaced the standalone CSAT-by-revenue page. customer-retention carries the metric dictionary’s period selector rather than the dashboard’s range selector, because it measures one period against the one before it and a bare range has no predecessor.

A money page states which money it is and never adds one figure to another. revenue-delivered is a flow over a window, so its last part is the twelve months of history it already carries, itemised per month and marked against the window being read. revenue-at-risk is a slice of the order book rather than a second amount beside it, so its last part reconciles the part to the whole: active service revenue, less the in-flight engagements carrying no flag, is the money at risk. It carries no movement over time, because nothing records the day an engagement became flagged or was cleared.

Every figure with a page is reached from both its dashboard card and, where the dictionary defines it, its entry there — and both carry the window the reader is already on, so a page never opens on a different figure from the card that opened it. The one exception is the Live Service Pipeline’s four summaries (Active projects, Service Pipeline Value, Delivery complete, Completed projects — the dictionary’s M12–M15, whose M12, M14 and M15 pages say “project” as the tiles do): they are stocks with no window, so their dictionary entries open /service-leads filtered to the leads they count, with no period, no range and none of the reader’s saved list filters.

Metric definitions are read by admins at /admin/metrics and by vendors at /vendor/metrics. Both surfaces are read-only and stay that way: a definition changes by migration and deploy, never in the product, and no role — admin included — can enter, adjust or override a reported figure. The one exception is the name and summary of M12, M14 and M15: they are the Live Service Pipeline’s own tiles, so the dictionary reads those two fields from the same words the board’s tiles and the three figure pages use, and a rewording of the tiles reaches all of them in one deploy, with no migration. Every other field of those entries, and every other definition, still changes by migration.