Commercial client detail page

The commercial client detail page is the drill-in behind a single named commercial client on the Commercial page (the third pill in the Accounts cluster, alongside Carriers and TPAs). Where Commerc…

11 min read·Updated July 14, 2026
On this page

What this page is

The commercial client detail page is the drill-in behind a single named commercial client on the Commercial page (the third pill in the Accounts cluster, alongside Carriers and TPAs). Where Commercial itself shows rows of clients side by side, this page is the one-client view: everything the network knows about that single client's billing, collection, and reach across every membership that serves it.

It is not a client record or a CRM entry. There is no contact info, no contract, no invoice list, and no way to edit anything here. The page reads one row from the network's nightly commercial-client rollup and lays it out as a set of figures: how much the network has billed that client, how much it has collected, how many memberships serve it, how fast it pays, and how its job volume has moved recently. Verinode surfaces the pattern; leadership decides what, if anything, to do with it.

Because a private commercial client has no canonical identity of its own (unlike an insurance carrier, which is the same legal entity everywhere), this page's whole existence depends on name matching: the network only knows two memberships serve "the same" client because their billing records share a normalized client name. See the Matching note section below for exactly what that does and does not catch.

Note

This page is one layer down from Commercial: your network's direct-B2B book, which covers the full page it drills out of, and What HQ sees on Commercial, and what it never does, which covers the privacy mechanics in full. This article is the deep reference for the single-client page itself.

Where to find it

There is no sidebar entry for this page on its own; it only exists as a drill-in. Reach it by clicking a client tile on Commercial's Top Commercial Clients by Spend row or Most Shared Commercial Clients row (hq.verinode.ai/commercial). Clicking either tile is a full page navigation, not an overlay, and lands you at hq.verinode.ai/commercial/[normalized-client-name], where the URL segment is the client's normalized (lowercased, whitespace-collapsed) name.

Because the URL encodes the client's own identity, it is shareable and bookmarkable: sending a colleague a direct link to a client's detail page opens the same view they would get by clicking through from Commercial. If the normalized name in the URL does not match any client row your network can see (a typo, a client that has since dropped out of the rollup, or a client belonging to a different network entirely), the page returns Verinode's standard not-found page rather than a blank or broken screen.

A ← Commercial clients link sits above the client's name at the top of the page. Clicking it returns you to the Commercial page, not back through your browser history, so it always lands you on the section home regardless of how you arrived.

The header

Every visit to this page, aggregate-only or not, shows the same header:

  • The client's display name as the page's large headline title, exactly as it was recorded (not the lowercased normalized form used in the URL).
  • A meta line underneath, separated by middle dots: the client's humanized type, how many memberships serve it, and, when known, the date of its last completed job.

The type label is never a raw database value. A client_type of property_manager renders as Property Manager; a type of bank renders as Bank. Every word is capitalized and underscores become spaces. If no client type was ever recorded, the label falls back to the generic Commercial client.

The franchisee-count phrase reads "1 franchisee serving" when the client has exactly one membership, or "N franchisees serving" for any other count. The last-job date, when present, reads "Last job [Month Day, Year]" (for example, "Last job Jul 11, 2026"); it is omitted from the meta line entirely when no completed job date is on file.

Two states: full metrics, or aggregate-only

Below the header, the page renders in exactly one of two states, decided before anything else loads:

  1. Full metrics. Two rows of figures plus a matching note (covered below).
  2. Aggregate-only. A single paragraph, no figures at all.

Which state you get depends on your network's data posture and how many memberships serve this specific client, covered fully in Cohort gating below. There is no partial state and no way to override it from this page: either the client clears the network's cohort floor and you see every figure, or it does not and you see the disclosure paragraph only.

Row 1: headline revenue and collection posture

The first row (no row title, sitting directly under the header) holds three tiles:

  • Billed (36mo). The client's total billed dollars across the network over the trailing 36 months, shown as the headline figure on a double-wide tile. Underneath, either the dollars collected over the same window (for example, "$210k collected"), or, if no collection figure exists yet, "Collection data pending."
  • Franchisees serving. The membership count as the headline number, with "Cross-network client" underneath when more than one membership serves the client, or "Single-franchisee client" when only one does.
  • Avg days to pay. The client's average days from billing to payment across the network, shown as, for example, "38d." The sub-line reads "Above 60d, collections risk" past 60 days, "Above 45d, watch" between 46 and 60 days, or "Within network norms" at 45 days or under. When no days-to-pay figure exists yet, the tile shows a dash instead of a number, but still renders with the same tone as "within network norms," since the underlying logic only escalates the tone when an actual figure crosses a threshold.

The days-to-pay tile's accent color follows the same tone: it reads in a warmer, redder tone once average days-to-pay passes 60, an amber-toned tone between 46 and 60, and a calmer green tone at 45 days or under (or when no figure exists yet).

Dollar figures throughout the page are abbreviated for readability: amounts of a million dollars or more show as, for example, "$2.1M"; amounts of a thousand or more show as, for example, "$84k"; anything smaller shows as a plain rounded dollar figure. A dash appears wherever the underlying figure is not yet known.

Row 2: job volume and collection ("Job volume & collection")

The second row carries the title Job volume & collection and holds three more tiles:

  • Jobs (36mo). Total billable jobs for this client across the network over the trailing 36 months, labeled "Total billable jobs" underneath.
  • Jobs (last 30d). Job count in the most recent 30 days, labeled "Active inflow" underneath when the count is above zero, or "No jobs in last 30 days" when it is zero. This is the freshness read: a client with strong 36-month volume but zero jobs in the last 30 days is a client that has gone quiet recently, worth noticing even while the longer-run numbers still look healthy.
  • Collection rate. Collected dollars divided by billed dollars over the 36-month window, shown as a percentage to one decimal place (for example, "94.2%"), labeled "Collected / billed (36mo)" underneath. This is a network-wide collection efficiency read for this one client specifically, distinct from the network's overall average days-to-pay shown on the Commercial hero. A client can pay slowly on average and still collect close to 100% of what is billed eventually; the two figures answer different questions (speed versus completeness).

If billed dollars are zero, unknown, or collected dollars have not been recorded, the collection rate shows a dash rather than a percentage: it is never estimated from a partial figure.

Matching note

Underneath both rows, a Matching note section explains, in plain language, exactly how the network decided that jobs recorded by different memberships belong to the same client row on this page: by matching a case-insensitive, normalized version of the client's name across every membership's own billing records.

This is a text match, not an entity match. Two memberships recording the true same commercial account under two different spellings, the page's own worked example is "Bank of America" versus "BoA", do not currently merge into a single row. Each spelling gets its own client row, its own separate figures, and its own separate detail page. A fuzzy-matching upgrade that would catch spelling and abbreviation variants is on the roadmap but not yet built.

The practical consequence: read every figure on this page as a floor on the client's true reach across your network, not a ceiling. If a client's real footprint is larger than what this page shows, the gap is most likely sitting under a differently spelled row elsewhere on Commercial, not evidence that the client's business with the network shrank.

Cohort gating: when this page shows aggregate-only instead

A commercial client served by too few memberships does not get its figures shown here, even with no client name attached to any of them. Showing per-client numbers for a client held by only a small handful of memberships would let someone work backward to which specific membership holds that account, defeating the anonymity the rest of the network's aggregate views depend on. This gate applies only to networks running the Independent operators data posture (the default for franchise and association networks); networks running Same entity posture never trip it, since there is no separate business identity to protect across a single enterprise's own regional offices.

When a client falls under that floor, the entire figures section is replaced by one paragraph:

Aggregate-only view. This client is currently served by fewer than [the network's minimum cohort size] franchisees in your network. Per-client metrics are suppressed to protect operator privacy (single-franchisee identification risk). The client will surface here in full once cohort size reaches that minimum.

This is not an error and nothing is broken. It is the same suppression logic that keeps a single-membership client off the Top Commercial Clients by Spend and Most Shared Commercial Clients rows on the parent Commercial page in the first place: if a client would not have qualified for a named row on the list page, landing directly on its detail page (by URL, bookmark, or shared link) shows the identical disclosure rather than a loophole around the same protection. As more memberships pick up the same client and the network's own aggregation catches the overlap, the client crosses the floor on its own and the full figures appear on the next nightly refresh, with no action needed from HQ.

Heads up

Do not read the aggregate-only state as a data problem or a missing feature. It is the privacy boundary working exactly as designed. Verinode never shows a per-client detail view narrow enough to identify which single membership holds an account.

Not found

If the URL's client segment does not resolve to any commercial client row your network can see, whether from a typo, an old bookmark to a client that has since aged out of the rollup, or an attempt to open a link meant for a different network, the page returns Verinode's standard not-found page. There is no partial header or empty-figures fallback in this case; either the client resolves and you get the header plus one of the two states above, or it does not resolve at all.

How to use this page

  1. 1Start from Commercial's Top Commercial Clients by Spend or Most Shared Commercial Clients row, and click through on the client worth a closer look, the largest account by spend, or the one showing up under the most memberships.
  2. 2Read the header meta line first: how many memberships serve this client, and how recently it last completed a job for the network.
  3. 3If the page shows the aggregate-only disclosure, stop there. There is nothing more to see for that client until the network's cohort grows.
  4. 4Otherwise, scan Row 1 for the headline size (billed and collected dollars) and the collection-speed read (avg days to pay), then Row 2 for whether the client's job flow is fresh (jobs in the last 30 days) or has gone quiet despite a strong 36-month history.
  5. 5Read the Matching note before treating the figures as a hard ceiling on the client's total footprint, a differently spelled version of the same account may sit on its own row elsewhere on Commercial.

Tip

A client with strong 36-month billed dollars, a high franchisee count, but zero jobs in the last 30 days is worth a second look before featuring it in a recruitment or renewal conversation. The historical relationship may be exactly as strong as the numbers say, or the account may simply be between projects, this page cannot tell you which; that is a conversation for the memberships who actually hold the relationship.

Best-practice example

Say you click through from Most Shared Commercial Clients on a facility-management account showing three memberships serving it. The header confirms "3 franchisees serving" with a last job completed a few weeks back. Row 1 shows $210k billed over 36 months with $198k collected, and an average of 34 days to pay (green tone, within network norms). Row 2 shows 21 jobs over 36 months, 2 in the last 30 days (active inflow), and a 94.3% collection rate. That combination, a large, actively used, cleanly collecting account served by multiple memberships, is exactly the kind of proof point worth naming directly in a franchisee recruitment pitch or a network broadcast (see Broadcasting to your network): the network already has a shared commercial relationship worth stepping into.

Now say a different tile takes you to a client showing the aggregate-only paragraph instead. That is not a dead end, it is information on its own: the network has at least one membership doing business with that client, but not yet enough to show the shape of it without risking exposing who holds it. Nothing to act on here beyond noting that the account exists and may be worth a broader look once more memberships pick it up.

Data sources

Data sources

  1. 1.Nightly cross-franchisee commercial-client rollup, matched by normalized client name. Your network's memberships.
  2. 2.Franchisee job, billing, and collections data underlying the rollup. Your network's memberships.
Was this helpful?