Consent requests: when a name or private figure can appear

What a consent request is

Verinode Benchmarks and leaderboards are built to run anonymous by default. HQ sees network-wide aggregates, percentiles, and rankings, but never a single franchisee's raw numbers tied to their name. That boundary is what makes the benchmarks trustworthy: a franchisee who contributes data knows their own figures are never disclosed without their say-so.

A consent request is the control that lets HQ ask for an exception to that default, one franchisee at a time, for one clearly scoped reason. It is the only path by which a name or a private figure can ever appear outside the anonymous aggregate. Nothing named surfaces automatically. HQ authors a request, the franchisee sees exactly what is being asked and why, and the franchisee approves, declines, or lets it lapse. Verinode never makes this decision on the franchisee's behalf.

Where to find it

Consent requests live under the Broadcast area of the HQ workspace, at hq.verinode.ai/franchise/broadcast?tab=consent. Broadcast is HQ's outbound dispatch surface, and Consent is one of five tabs across the top: Announcements, Initiatives, Surveys, Polls, Consent. Click Consent to open this page.

Franchisees see their side of the same request in their own IQ deck (iq.verinode.ai), where a consent request arrives as something to approve, decline, or (once approved) later revoke.

What you see at the top: the hero panel

The page opens with a hero panel labeled Consent requests, showing:

• A pending count, the number of requests still waiting on a franchisee response. If it is zero, the pill reads "Nothing pending." Otherwise the pill reads "N pending" and takes on a Maintain (yellow) tone as a nudge to follow up.
• A summary line. Before your group has ever sent a request, this reads: "Consent requests let HQ ask operators to share specific named data for rankings, case studies, or deep dives. Operators see each request in their IQ deck and approve, decline, or customize scope." Once you have sent at least one, it switches to a running total: "N total requests authored across the lifetime of this group."
• Approved 30d, how many requests a franchisee has approved (opted in) in the last 30 days, subtitled "Operator opt-ins."
• Declined 30d, how many a franchisee has turned down in the last 30 days, subtitled "Operator refusals."
• All-time, the lifetime count of requests your group has authored, subtitled "Requests authored."

These three secondary numbers are read-only counters over your group's own request history. They tell you how often franchisees say yes versus no, not anything about the network at large.

Sending a new request

Click + New consent request in the page header (visible to group admins only) to open the composer. It asks for six things, in order:

1. Franchisee. A dropdown of your network's roster. Pick the one franchisee this request is for. Consent requests are always one-to-one: you cannot batch-request the whole network in a single ask.
2. Request kind. Four options, each with a plain-language hint shown beneath the dropdown:

- Named on a leaderboard, hint: "show as #3 by margin on the network leaderboard with the operator's name visible." This is the option that governs named leaderboard placement in Benchmarks: without an approved request of this kind, that franchisee's leaderboard row stays anonymous. - Named in a specific view, hint: "let HQ see this metric named for this time window." Use this for a one-off named look at a metric outside the leaderboard context, scoped to a date range. - Case study / publication, hint: "feature operator data in a research publication." Use this when you want to name a franchisee's numbers in a written piece, not a live in-app view. - Deep data access, hint: "job-level detail for a Q3 margin-lift initiative." The narrowest-audience, highest-trust ask: this is for drilling into underlying job-level data, not just a metric rollup.

1. Metrics. A search-and-select picker (not a free-text field) drawing from Verinode's benchmark metric catalog, grouped by category (Carrier Speed, Financial Health, Operational, Vendor Pricing, Safety, Team Performance, Wages & Compensation, Recruiting & Hiring, Sales & Marketing, Exterior & Roofing). Type to filter by name or description, click a row to add it, and it appears as a removable chip above the search box. You never type or see a raw database key here, only the same human-readable metric names franchisees see elsewhere in Benchmarks. At least one metric is required before you can send.
2. From / To (optional). Two date fields bounding the time window this consent covers. Leave both blank for an open-ended ask.
3. Rationale. A free-text field the franchisee will read verbatim: "Why are you asking? What does the operator get in return?" This is your one chance to explain the ask in your own words before the franchisee decides. A vague or missing rationale is the single biggest reason a franchisee declines.
4. Auto-expire in (days). Defaults to 14. If the franchisee hasn't responded by then, the request automatically flips to expired and stops waiting on them. Set to 0 for no expiry (the request stays pending indefinitely until answered or you withdraw it).

Click Send request. If you haven't picked a franchisee, the form blocks with "Pick a franchisee." If no metrics are selected, it blocks with "Pick at least one metric." Once sent, the request appears in Pending operator response immediately and the franchisee sees it the next time they open their IQ deck.

Pending operator response

This row lists every request your group has sent that a franchisee has not yet acted on, newest first, up to 12 at a time. Each tile shows:

• Label: the request kind (Named leaderboard, Named view, Case study, or Deep data).
• Headline: the franchisee's name.
• Sub-line: the metrics covered, e.g. "Metrics: Gross Margin, A/R Over 90 Days" (up to three names, with an ellipsis if there are more). If somehow no metrics are attached, it reads "No metrics specified."
• Meta line: how long ago you asked ("Asked 3 days ago") and, if an expiry is set, when it lapses ("expires 11 days ago" once past, or the forward-looking equivalent while still live).

If nothing is waiting, the row reads: "No requests waiting on an operator response. Use the affordance in the header to ask an operator to share named data for a specific metric, time window, or case study."

Recently resolved

This row shows requests that reached a final state (approved, declined, or withdrawn) in the last 30 days, newest first, up to 12 at a time. Each tile shows:

• Label: request kind followed by its status, e.g. "Named leaderboard · Approved."
• Headline: the franchisee's name.
• Sub-line: the same metrics summary as the pending row.
• Meta line: the resolution and when it happened, e.g. "Approved 6 days ago," "Declined 2 days ago," or "Withdrawn 1 month ago."

If nothing resolved in the window, the row reads: "No responses landed in the last 30 days."

The five states a request can be in

Every consent request moves through one of these statuses, and each one governs exactly what disclosure is (or isn't) allowed:

• Pending. Sent, awaiting the franchisee's response. No name or private figure is visible anywhere yet.
• Approved. The franchisee said yes. Only now does the requested disclosure, a named leaderboard row, a named view, a case-study feature, or deep-data access, become live, and only for the exact metrics, kind, and time window that were requested. HQ never gets a broader grant than what was asked and approved.
• Declined. The franchisee said no, optionally with a reason. Nothing is disclosed. HQ can send a new, differently-scoped request later, but this one is closed.
• Withdrawn. Either side pulled back. HQ can withdraw a pending or an approved request (with an optional reason recorded); a franchisee can also revoke their own prior approval at any time. The moment a request is withdrawn, whatever was disclosed under it stops being disclosed immediately.
• Expired. The auto-expire window passed with no response. Treated the same as declined: no disclosure.

Every state transition, created, approved, declined, withdrawn, expired, is appended to that request's own audit trail with who acted (HQ or the operator), when, and why. This is what makes the boundary auditable, not just a promise: there is a permanent record of every ask and every answer.

Withdrawing a request

Group admins can withdraw a request they sent while it is still pending or already approved. Withdrawing a pending request simply cancels the ask. Withdrawing an approved request immediately revokes whatever was being shown, the franchisee's name comes off the leaderboard, the named view stops rendering, and so on, the moment the withdrawal is recorded. A franchisee can do the same thing from their own side on an approved request: they see a note that reads "You can revoke at any time; HQ stops seeing your name immediately after," with an optional reason field, and revoking flips the same request to withdrawn.

What the franchisee sees

When a franchisee opens a pending request in their IQ deck, they see the group's name and the request's status, a plain description of what is being asked (per request kind: named leaderboard visibility, a named specific view, a case study feature, or deep job-level data access), the exact metrics by name, the time window if one was set, when it was asked, when it expires if applicable, and your rationale verbatim. They then choose Approve or Decline, with an optional decline reason. Once approved, they can Revoke approval at any time, also with an optional reason. A closed request (declined, withdrawn, or expired) shows read-only, with a note: "This request is closed. No further action needed," plus their decline reason if one was given.

Why this exists: the aggregates-only boundary

Verinode HQ's entire trust model rests on one line never being crossed: HQ sees network aggregates, rankings, and compliance, never a single franchisee's private business data, unless that franchisee has explicitly agreed to a specific, scoped disclosure. Consent requests are how that agreement is captured, offered, and revoked. Every named row on a leaderboard, every named metric in a specific view, every case-study feature, and every drill into job-level detail traces back to exactly one of these records in an approved state, for exactly the metrics and window it covers. Franchisees own their data; this is the mechanism that keeps that ownership real at the moment disclosure is about to happen, not just a policy statement.

Best-practice example

Say your network's Q3 margin leaderboard is ready to publish and you want the top three franchisees named instead of anonymous. Open Broadcast → Consent, click + New consent request, and for each of the three franchisees send a Named on a leaderboard request scoped to the Gross Margin metric and the Q3 date range, with a rationale like "Recognizing your Q3 performance publicly on the network leaderboard, so peers can see who to learn from." Each franchisee sees the ask in their IQ deck and can approve or decline independently. Only the ones who approve show up named; the rest stay anonymous on that same leaderboard, exactly as before.

Related articles

• Broadcasting to your network
• HQ overview
• HQ benchmarks
• Item 19 disclosure
• HQ compliance

Data sources