Value surfaces, dashboards and Vera

Products — utilization & adoption

The normalized Products grid is the home of the estate — one row per product (not per executable) — and it answers a single question: which tools are actually used, how much, and how is that changing? Every column is measured over a window you choose: last 7 days, 30 days, 90 days, 6 months, or 12 months.

Column	What it tells you
Hours used	Total time the tool was actively used across the fleet in the window.
Utilization %	How much it is used, normalized to a standard workday — a "share of a workday" you can compare across tools and people (see below).
Days active	How many distinct days it saw any real use.
Sessions	How many times it was launched; from this come average time per session and per day.
Active / Installed devices	How many devices actually used it versus how many merely have it installed.
Last used	The most recent time anyone touched it.
Trend	Whether usage is rising, declining, or steady across the window.

An "Installed, unused" filter narrows the grid to tools that are installed but saw no use in the selected window — your clearest list of candidates to remove or reassign. Click any row for the product detail — pick a window and see an hours-used per day and a sessions per day chart, network bandwidth over time, the executables and versions behind the product, and a per-device table ranking every machine by hours used, sessions, days active, and when it was last used.

How utilization is measured

The numbers above all rest on runtime — and runtime means active use, not merely that a window was left open. A tool counts as in use when it holds the foreground, is working the CPU, or is moving data on the network. Idle-but-open time does not inflate the figures.

Term	Plain meaning
Runtime	Time a tool was actively used (foreground / CPU / network) — not just open.
Hours used	Total runtime accumulated across the window.
Days active	The count of days on which it saw any use.
Sessions	How many times it was launched; average per session and average per day follow from it.
Utilization %	Runtime divided by a standard workday, so it reads as a share of a working day.
Trend	The recent half of the window compared against the earlier half.

For utilization, a workday is taken to be 8 business hours. So a tool used for 4 active hours in a day shows around 50% utilization — a normalized figure you can compare fairly across tools and people regardless of how long anyone left an app open. Secondary views express the same usage as a percentage of days active and a percentage of monitored time when you want a different denominator.

Weighted usage: not all active time is equal

Two hours with a tool in the foreground is worth more, as evidence a seat is earning its cost, than two hours where the tool only held a background network connection. Alongside raw hours, Scout computes a weighted usage figure that grades each hour by how the tool was used:

How it was used	Weight
Focused — foreground, active in front of the user	1.0 (full)
CPU-active — working in the background	0.5 (half)
Network-active — only holding a connection	0.25 (quarter)

Weighted hours give a truer picture of real engagement than a raw open-time total: a chat client left connected all day but rarely looked at scores far lower than a design tool actively used for the same wall-clock time.

Usage tiers: power, regular, light, inactive

From weighted hours over the window, every machine-and-tool pairing falls into a usage tier — a plain-language replacement for a binary "used / not used":

Tier	Weighted hours in the window	Read it as
Power	More than 20	Heavily used — clearly worth the seat
Regular	1 to 20	Genuinely used
Light	Under 1 (but more than none)	Barely touched — a downgrade candidate
Inactive	None	Installed but unused — a reclamation candidate

A product's detail shows the tier breakdown across its devices — e.g. "3 power / 5 regular / 12 light / 80 inactive" — so a 40-seat license with mostly light and inactive users is visible at a glance, not buried in an average.

Comparing windows and reading the long trend

The product detail lets you put the 30-, 90-, and 180-day windows side by side, so you can see at once whether a tool's usage is holding up or fading as the horizon widens — a tool that looks healthy over 30 days but thins out over 180 is a different story from one steady across all three. A trend selector switches the history between a recent, detailed view and progressively longer horizons (7 days, 13 weeks, and 24 months), so you can zoom from this week's shape out to multi-year adoption without the chart becoming unreadable.

To make those long horizons fast, VerOps keeps recent days in full detail and summarizes older history into weekly, monthly, and yearly rollups behind the scenes. You always get the full window you asked for; the far end of a long trend is drawn from the summaries rather than from every raw day, so a two-year view loads as quickly as a one-week one. This is automatic and needs no configuration.

Licenses: reconcile seats against real usage

The Licenses tab records what you actually pay for — owned seats, cost per seat, renewal date — and reconciles each license live against measured usage, so you can see which contracts are earning their money and which are over-bought.

Column	What it tells you
Seats	How many you own.
Installed	Hosts that actually have the product (in the license's scope).
Active	Hosts with real, weighted usage — not merely installed.
Utilization %	Active hosts as a share of owned seats.
Usage mix	A breakdown bar of power / regular / light / inactive users on the license — so you see at a glance whether the seats are heavily used or mostly idle.
Potential annual savings	Unused seats × cost per seat, as a yearly figure — your reclaimable spend.
Confidence	How safe it is to act on the savings figure (see below).

Scope a license to a group

A license usually covers a specific team, not the whole company. Give a license a scope group (e.g. Marketing) and its reconciliation counts only hosts in that group instead of every host running the product. This is the difference between a meaningful number and a misleading average: a 100-seat Marketing license and a 25-seat Workstations license for the same product no longer show identical utilization — each is measured against the hosts it actually covers. Leave the scope blank and the license reconciles product-wide, across all hosts, as before.

Confidence-qualified savings

A savings number is only as good as the history behind it, so every license carries a confidence level that qualifies the recommendation:

Confidence	Meaning
High	Consistently under-used across 30, 90, and 180 days with no upward trend — reclaiming is low-risk.
Medium	Low recently but moderate over the longer windows — reclaim cautiously and re-check next cycle.
Low	A recent dip against high longer-term usage — likely seasonal; verify before acting.
Insufficient	Under ~60 days of history (or no seat count yet) — keep monitoring before reclaiming.

Redundancy: overlapping and dangerous tools

The Redundancy tab answers a question the Products grid can't: which hosts run several tools that do the same job, and is that wasteful or actually dangerous? It groups each host's software by category and flags any host running more products in a category than a configurable threshold allows.

Column	What it shows
Host / Category	The machine and the over-subscribed category (e.g. four design tools).
Products	The overlapping tools, each badged active or idle so you can see which one is really used.
Threshold / Excess	The allowed count for the category and how many over it this host is.
Redundancy cost	The annual cost of the excess (least-used) seats, drawn from the matching license — summed into a Total redundancy cost at the top.

Dangerous overlaps — multiple security, VPN, or remote-access tools on one host — are elevated in red and counted separately. These aren't just wasteful: two antivirus products or two VPN clients running at once cause conflicts, performance drag, and real operational risk. A Dangerous only toggle narrows the view to exactly those.

Each category has a max-per-host threshold you can tune — the defaults are sensible (browsers 3, communication 2, design 2, and 1 each for security, VPN, and remote-access). Catch-all and uncategorized software is never flagged, so the report stays signal, not noise.

Policy enforcement and violations

Every product carries a policy — approved, tolerated, prohibited, or needs review. The Violations tab turns those policies into enforcement: it continuously detects where reality breaks policy and tracks each finding to resolution.

Violation	Raised when
Prohibited detected	A host is actually running a product whose policy is prohibited. (Critical.)
Dangerous overlap	A host runs more than the allowed number of a risk-sensitive category — multiple security, VPN, or remote-access tools. (Critical.)
Toleration expired	A tolerated product's expiry date has passed — the product is automatically escalated to prohibited.
Threshold exceeded	A tolerated product is installed on more hosts than its allowed limit.

Violations are re-evaluated on every agent report and swept nightly, so the list reflects the live estate. Detection is idempotent — the same condition never stacks up duplicate findings, and a finding you've closed is not reopened while it stays closed.

Real-time alerts

A newly-detected violation raises a real alert through the same alerting pipeline as the rest of the platform, delivered to whatever notification channels you've configured (email, Slack, Teams, webhook, PagerDuty). Prohibited software and dangerous overlaps fire as critical security alerts. Alerts are de-duplicated — a persistent violation notifies once, not on every sweep — and when the violation is resolved the alert is cleared automatically.

The remediation workflow

Each violation moves through a status lifecycle so a team can work the queue: Open → Acknowledged → In progress → Resolved, or Waived (which always requires a reason, for the audit trail). Filter the tab by status, and use Re-evaluate now to refresh on demand. When the underlying condition clears — a product is re-approved, a host stops running it, or an overlap is cleaned up — the violation auto-resolves; a waived violation is left exactly as you set it.

Time-boxed toleration

Sometimes a product is acceptable for now — during a migration, say. Marking it tolerated lets you attach an expiry date, a maximum host count, and a migration plan link. Before expiry it's allowed; once the date passes it auto-escalates to prohibited and starts raising violations, so a temporary exception can't quietly become permanent. Exceed the host cap in the meantime and a threshold violation is raised.

Hosts and their lifecycle

Inventory → Hosts lists every machine an agent reports for, each with a lifecycle state so you can tell a live machine from one that has quietly gone away from one you have deliberately retired:

State	Meaning	Counts as installed?
Active	Reporting recently.	Yes
Stale (N days)	No agent report for more than 14 days — the machine may be off, offline, or gone. The chip shows how many days it has been quiet.	Yes — still counted, just flagged
Retired	Deliberately taken out of service by an admin. Excluded from installed/active counts and from license reconciliation, but its history is preserved.	No

Filter the list by All / Active / Stale / Retired (each chip shows a live count), search across host names, OS, and tags, and toggle Show retired to bring retired machines back into view. Every host carries these actions:

Action	What it does
Retire	Marks the host retired with a reason (Decommissioned, Re-imaged, Employee left, or Other). It drops out of counts and license reconciliation immediately; history stays. Reversible.
Un-retire	Returns a retired host to active — the one-click undo.
Edit tags	Attach labels to the host (see Tags below).
Clear data (admin)	Removes the host's software links and usage history — and any software then left on no host at all — but keeps the host record. It re-populates on the next agent report. Use it to reset a machine that reported the wrong thing.
Delete host (admin)	Removes the host entirely, along with all of its data. Use it for a machine that is gone for good.

Retire vs. Delete: retiring keeps the record and the history and is reversible — the right choice for a machine that has been decommissioned or handed on. Deleting throws everything away and can't be undone.

Tags: label your estate

Any host can carry tags — simple key:value labels — so you can slice the estate by whatever matters to you: department:marketing, building:london-hq, owner:jsmith, cost-center:4021. Open a host's Edit tags action to add, change, or remove them; they appear as chips on the host row and are searchable from the Hosts filter box. There are two kinds:

Kind	What it is
Custom tags	Free-form key:value labels you invent — department, site, owner, cost center, anything. Used for grouping, filtering, and reporting.
System tags (sys:)	A reserved set the platform understands and acts on — for example the host's lifecycle. These are validated, so a typo or an unknown value is rejected rather than silently stored.

A tag you set in the UI always wins over the same tag pushed by an agent, so an admin decision is never overwritten by an automated report.

Note: Retired devices keep their history. When a laptop is retired or replaced, its past usage stays in the record. Current views show only active devices, but historical usage reports still include the retired ones — so a trend does not lurch just because a machine was swapped out.

Policy and shadow IT

• Policy — every product carries a state: approved, tolerated, prohibited, or needs_review. New titles default to needs_review and surface in the Review queue.
• Shadow IT — products that are unmanaged and/or need review: software that entered the estate without a decision.
• Installed, unused — tools installed on devices that saw no use in the window — the sharpest, most defensible list of candidates to remove or reassign.
• Trends — usage is tracked over time so you can chart adoption of tools, products, and devices across the window.

The Review queue

The Review queue is where unclassified titles wait for a decision. It has a search box for finding a specific title, and two features that make working a large queue fast.

Detect with Vera

Rather than hand-searching every unknown executable, Detect with Vera asks your organization's configured AI model to identify each unclassified title. For every one it returns:

Field	Meaning
Vendor	Who makes it
Category	What kind of software it is
Description	A one-line summary
Typically paid	Whether it is usually a paid product
Suggested policy	A conservative recommended policy
Confidence	How sure Vera is of the identification

A Review & apply dialog then pre-selects the high-confidence rows — each with an editable policy — and applying them commits through the same audited classification path as a manual decision. Vera is deliberately conservative: it suggests approved only for clearly-legitimate OS or business software, prohibited for risky or unwanted software, and needs_review whenever it is unsure.

Note: Detect with Vera requires an AI provider configured under Settings → AI providers. Without one, the action is disabled with a hint explaining why. Confidence scores how sure Vera is that it identified the title correctly — not how safe the software is.

Blocked products and Unblock

Setting a product's policy to Prohibited hides it from the Review queue, so junk you never want to classify stops reappearing every sweep. A dedicated Blocked view lists all prohibited products, and Unblock returns one to the Review queue — the one-click undo for a mistaken block.

Dashboards: the inventory data source

Inventory is a first-class dashboard data source — no SQL. When you add a widget to a dashboard you pick Inventory as the source and choose what to chart; the dashboard renders it as the same timeseries, single-value, and table widgets you already use. The available views include:

Widget	Shows
Estate trends	Hours used, active products, and active devices over time
Headline stat	A single number (hours used, fleet utilization, active products, unused tools)
Top products by installs	Most-installed products
Top products by usage	Most-used products (by hours used)
Installed, unused	Tools installed but not used in the window — removal candidates
Category breakdown	Usage grouped by category
Category overlap	Top hosts running redundant tools in the same category — with excess count and cost
Dangerous overlaps	Hosts running multiple security / VPN / remote-access tools — the risky subset

Compose these into a shared Software Estate dashboard — headline stats, usage trends, a most-used panel, and an installed-but-unused table — so stakeholders see adoption and waste without asking IT.

The pre-built "Software Estate" dashboard

You do not have to assemble those widgets by hand. VerOps ships a ready-made Software Estate dashboard you can create in one click from Inventory → Overview → Create starter dashboard.

It lands in the Inventory folder and is idempotent by name — creating it again opens the existing board instead of duplicating it. It is built entirely from the inventory data source (no SQL): single-value tiles (hours used, fleet utilization, products, devices, unused tools), a 30-day usage trend, a category breakdown, top products by real usage, and an installed-but-unused table.

Best practice: create the starter dashboard first for an instant executive view, then clone and tailor it per audience — a leadership board that leads with hours used and fleet utilization, an IT board that leads with policy and shadow IT.

Chart your usage in your own custom dashboards

Beyond the inventory data source, your organization's inventory usage is also available as metrics you can plot on any of your own custom dashboards, right alongside your other metrics. They all live in the inventory_ family; add a timeseries or single-value widget and reference one:

Metric	What it charts
inventory_tool_runtime_hours	Hours used, per tool
inventory_tool_active_devices	Devices actively using each tool
inventory_category_runtime_hours	Hours used, grouped by category
inventory_agenttype_runtime_hours	Hours used, grouped by agent type

Companion metrics in the same family cover sessions (launches) per tool and the counts of products in active use and devices in active use — the per-tool session and active-device series named just like the ones above, and the product/device active counts as single-value series.

These metrics are scoped to your organization — you only ever see your own fleet's usage — and they are deliberately bounded: the per-tool metrics cover your top tools plus an "other" bucket, and the rest are grouped by category and agent type, so a dashboard stays fast and readable no matter how large the estate.

Vera: advisory intelligence over the estate

Vera, the platform AI, reads the same estate, so you can ask usage and adoption questions in natural language. Vera can:

• list your normalized products with usage and metadata;
• tell you how much a given tool is used — hours, days active, sessions, utilization;
• say whether a tool's usage is increasing, declining, or steady over a window;
• find tools that are installed but never opened, and tools that have stopped being used;
• report software redundancy — which hosts run several tools in the same category, whether they're active, dangerous security/VPN/remote-access overlaps, and the cost of the redundant seats;
• report policy violations — prohibited software detected on hosts, expired or over-threshold tolerations, and dangerous overlaps, with their current status;
• break usage down by device, by team/department, or by agent type, and name who spends the most time in a tool;
• surface the review queue of new, unclassified software;
• chart usage, active products, and active devices over time;
• write a full tool-sprawl report: executive summary, estate, adoption and unused tools, shadow IT and policy, then ranked recommendations;
• propose a software classification for you to confirm — Vera never silently changes the estate.

Prompts can be direct:

"How much is Visual Studio used across the fleet this quarter, and is that
 increasing or declining?"

"Which tools are installed but never opened in the last 90 days?"

"Who spends the most time in Postman, and break Docker usage down by team."

Note: Vera's read tools are freely callable. The one write-shaped action — proposing a classification — is deliberately a proposal an admin confirms. Advice is cheap; changing the record of truth is deliberate.