SaaS License Utilization Dashboard: Recover Budget from Unused Seats

According to Zylo's 2024 SaaS Management Index, 47% of provisioned SaaS licenses go unused at any given time. For a mid-size company spending $1.2M annually on software, that's nearly $560,000 in seats nobody is logging into. Companies in the $50M–$200M revenue band typically overspend $200,000–$500,000 per year on SaaS they cannot account for, and the number climbs with headcount. The problem isn't that finance doesn't care — it's that nobody has a clean, current view of utilization until a renewal invoice lands and it's too late to renegotiate the seat count.

A SaaS license utilization dashboard fixes that by turning fragmented provisioning data, IdP login events, and vendor-provided usage APIs into a single, actionable view your IT and ops teams can check weekly. Done well, the first renewal cycle after deployment typically recovers enough budget to pay for the tool several times over.

The Anatomy of SaaS Waste

SaaS sprawl accumulates in predictable ways. A team lead purchases a productivity tool on a company card and expenses it. An engineer spins up a cloud API account using the company GitHub org. A vendor converts a pilot from 10 seats to an enterprise-wide deal during a period of rapid headcount growth, and nobody revisits the seat count when growth slows. Over a 24-month period, a 300-person company can easily accumulate 80–120 distinct SaaS applications, a significant portion of which are overlapping in function or underused.

The waste compounds because renewals auto-renew. Most enterprise SaaS contracts have a 60- or 90-day notice window before auto-renewal, and if nobody is tracking that window in a place that gets reviewed, the invoice arrives after the cancellation deadline has passed. The vendor's account executive has no incentive to remind you.

Three categories of waste are worth distinguishing, because each requires a different tracking approach.

Fully idle seats belong to users who were provisioned and never logged in, or who left the company and weren't deprovisioned promptly. Industry data suggests 10–20% of licensed seats in any large SaaS application fall into this category. These are the easiest to recover — the seat has no active user and can be released immediately.

Stale seats belong to users who logged in occasionally but haven't been active in 60 days or more. These often belong to users whose role has changed, who switched to a different tool for the same function, or who are using a personal account instead of the corporate one. Recovering stale seats requires a light-touch outreach workflow rather than immediate deprovisioning.

Over-provisioned tiers occur when the company is paying for a feature tier (e.g., Enterprise) that most users don't access. If 200 out of 250 Salesforce seats are in Sales Cloud Essentials-level usage patterns but the contract is for Enterprise, that's a meaningful delta. Identifying this requires usage-depth data, not just login frequency.

What Utilization Means Per Tool Type

Not every SaaS application exposes the same signals, and "utilization" means something different depending on the pricing model.

Seat-based tools — most B2B SaaS — are the simplest to analyze. The primary signals are last-login date and feature-usage depth. Last-login date is available from SSO events or the vendor's /users API and tells you whether the user is touching the product at all. Feature-usage depth — which modules or features the user has actually interacted with — tells you whether the license tier is appropriate. A Notion user who only reads pages shared with them doesn't need a paid member seat if your plan allows guests.

Usage-based tools — cloud infrastructure, API services, analytics platforms — are priced on consumption rather than seats. For these, utilization means API calls made, storage consumed, queries executed, or data processed. The question isn't "who has an account" but "are we actually using what we're paying for in each billing tier." A company paying for 10TB of Snowflake storage that is only using 3.5TB should be on a different tier. Tracking these requires pulling billing and usage data from the vendor's billing API or console export, not from an IdP.

Outcome-based tools — reporting platforms, BI tools, document automation — are best evaluated by whether users are completing the actions the tool is meant to enable: reports run, dashboards viewed, documents generated, exports triggered. A Looker seat held by a user who has never published a report in six months is a recoverable seat regardless of their login frequency.

Understanding which category a tool falls into determines where you pull data from and what threshold you use to flag a seat as idle.

Data Sources: Where the Numbers Come From

A utilization dashboard without live, automated data is just a more complicated spreadsheet. The value comes from the integrations that keep the numbers current without manual effort.

SSO and Identity Provider logs are the foundation. Okta, Azure AD, and Google Workspace all maintain application access logs — every time a user authenticates into a connected application, a login event is recorded. These logs give you the provisioned-seat universe (your denominator) and a last-login timestamp for every user-application pair. The limitation is that SSO login events don't distinguish between a user who opened the app for two seconds and one who spent six hours in it. They're a utilization floor, not a ceiling.

Pulling this data typically involves Okta's System Log API (/api/v1/logs) or the Azure AD sign-in logs endpoint, filtered by application and time window. A nightly ETL job that ingests the prior day's events and updates a per-user, per-application last-active timestamp is sufficient for most use cases.

Vendor-provided usage APIs are more precise than SSO logs and should be used wherever available. Slack's Admin API exposes admin.users.list with last_active timestamps. GitHub's REST API returns per-user updated_at and activity data. Notion's API, Figma's API, Atlassian's REST API, and Salesforce's user management endpoints all provide equivalent data. When a vendor API is available, it produces usage signals that reflect in-product activity rather than authentication events — meaningfully more accurate.

The tradeoff is implementation cost: each vendor has a different authentication model, rate limit, and response shape. A connector library approach — one normalized data model with per-vendor adapters — scales better than one-off integrations built case by case.

Browser extension telemetry can fill gaps for applications that don't have robust APIs and aren't connected to SSO. Extensions like those used by Torii or Zluri capture active tab time across web applications by tracking domain-level activity. This approach works for any web-based tool regardless of vendor API availability, but it requires installing an extension on every managed device — a non-trivial IT policy decision.

Expense and procurement records serve a different purpose: discovery. Before you can track utilization, you need to know what you own. Finance exports (Expensify, Concur, corporate card transactions) and procurement records surface subscriptions that IT doesn't know about — the shadow IT layer. A recurring charge to a SaaS vendor's billing domain that isn't registered in your application inventory is a signal worth investigating.

Key Dashboard Views

A well-designed utilization dashboard has five core views, each serving a different stakeholder.

Utilization heatmap by tool and department is the at-a-glance view for IT and ops leadership. Each row is a SaaS application; columns are departments or business units. Each cell shows the utilization rate — percent of provisioned seats with at least one login in the last 30 days — color-coded from red (below 40%) to green (above 80%). This view makes cross-department patterns visible immediately. If Marketing is at 90% utilization on a design tool while Engineering is at 35%, that's a reallocation opportunity, not just a waste problem.

Idle seat list with last-active date is the operational view for whoever handles deprovisioning. It shows every user-application pair where the last active date exceeds a configurable threshold (30, 60, or 90 days), with columns for department, manager, license cost per seat, and a "reclaim" action. Sorting by cost per seat surfaces the highest-value reclamation opportunities first. This list should update daily and be filterable by department, manager, or application.

Renewal countdown with utilization score is the procurement and vendor-management view. Each row is a contract, showing the renewal date, notice-period deadline (which is often 60 or 90 days before renewal, not the renewal date itself), contract value, current utilization score, and a trend arrow showing whether utilization is improving or declining. The notice-period deadline column is the one that prevents missed windows — it should be the primary sort.

Reclamation queue is where the idle seat list becomes a workflow rather than a report. Seats flagged as idle are added to a queue with a proposed action (deprovision, downgrade tier, reassign). A team member reviews the queue, triggers the automated outreach workflow, and marks items resolved. The queue tracks items through their lifecycle — proposed, user contacted, manager approved, license released — so nothing falls through the cracks.

Shadow IT detection panel surfaces SaaS spend that isn't registered in the application inventory. It cross-references finance exports against the known application list and flags unrecognized recurring charges. This view is typically reviewed monthly by IT and finance together and is the primary mechanism for bringing ungoverned SaaS spend under management.

The Reclamation Workflow

The reclamation workflow is what converts dashboard data into recovered budget. The mechanics are straightforward but the sequencing matters for user experience.

When a seat crosses the idle threshold (configurable, typically 30 or 60 days of no activity), the system adds it to the reclamation queue and triggers an automated email to the user. The email is deliberately non-accusatory: "We noticed you haven't logged into [Application] in the last 30 days. Do you still need access? If yes, no action is needed — your license will be kept. If you'd like us to release the seat, click here." This framing drives meaningful response rates because it gives users agency rather than threatening them.

Users who don't respond within 5 business days move to the next stage: the system sends a notification to their manager asking for confirmation that the seat is still needed. Manager approval is a one-click action from the notification email. If the manager confirms the need, the seat is retained and flagged for re-review in 60 days. If the manager approves the reclamation (or doesn't respond within another 5 days), the system queues the deprovisioning action.

Actual deprovisioning — removing the user from the application in the IdP and notifying the vendor to release the seat — happens through the IdP API (Okta's Users API or the SCIM provisioning layer that most enterprise SaaS apps support). The system logs the action, the date, and the approver for audit purposes.

The recovered cost is credited back to the department's SaaS budget in the dashboard's cost allocation view. This visibility — "Engineering recovered $4,200 in Q1 by releasing 14 idle seats" — creates incentives at the department level to keep utilization healthy, because the savings are attributable.

Vendor Negotiation Prep

The renewal brief view does the work that traditionally falls to IT or procurement to compile manually: an automated report generated 60–90 days before each renewal that summarizes utilization data in vendor-negotiation-ready format.

A well-built renewal brief includes current seat count and monthly cost per seat, utilization rate at 30/60/90 day intervals over the trailing 12 months (so you can show a trend, not just a snapshot), the number of idle seats and the annualized cost of those seats, and a recommended seat count for the renewal based on the 30-day active user number with a 10–15% buffer for growth. For tools with tier-based pricing, it includes the distribution of feature usage across tiers to support a downgrade argument.

The brief also pulls publicly available benchmark data where relevant. Typical utilization targets for enterprise SaaS range from 70–85% — if you're at 52%, that's not just a negotiation talking point but an operational signal that the tool isn't delivering value.

When the vendor account executive argues that usage is up and seats should be added, the renewal brief is the rebuttal. When they argue that utilization data is unreliable or proprietary, the fact that it comes from both their own API and your IdP simultaneously removes that objection.

Build vs. Buy: When Each Makes Sense

Several purpose-built SaaS management platforms exist: Zylo, Zluri, Torii, Productiv, and BetterCloud are the most established. Their pricing typically runs $25,000–$80,000 per year depending on stack size and feature tier, and they come with pre-built integrations for 200+ applications, automated discovery, and workflow tooling.

For companies with a SaaS spend under $500,000 annually, these platforms usually deliver positive ROI through reduced manual effort and occasional savings recovery. The integration library and the ongoing maintenance of those integrations are genuine value — keeping 200+ vendor connectors current is not a trivial engineering investment.

For companies with SaaS spend above $750,000 annually, strong IdP instrumentation (Okta or Azure AD with comprehensive application coverage), and specific workflow requirements, a custom dashboard often wins on both economics and fit. The economics: a one-time build cost of $40,000–$80,000 for a custom dashboard, with no ongoing SaaS license fee, delivers net savings within 12–18 months relative to a platform at $60,000/year. The fit: custom dashboards can be built around your specific application portfolio, your department structure, your procurement approval workflows, and your cost allocation model — things that platform tools approximate but rarely nail.

The decisive factor is usually the integration question: if your most critical SaaS applications have robust APIs and your IdP is well-instrumented, the connectors are not the hard part. If you're running legacy on-premise tools or applications with no APIs, a platform's pre-built discovery methods (browser extension, bank-feed integrations) may be worth more than the cost.

ROI Calculation

The ROI case for a utilization dashboard is unusually straightforward because the savings are visible and attributable.

A company spending $1.2M on SaaS with 47% idle license rate has approximately $560,000 in potentially recoverable spend — but realistically, not all of it is recoverable immediately. Some idle seats have legitimate justification (seasonal roles, on-leave employees, tools used infrequently but legitimately). A conservative recovery rate of 20–30% of identified waste is achievable in the first year: $112,000–$168,000 on that $1.2M base.

For a company spending $500,000 on SaaS, the recoverable range in year one is typically $40,000–$80,000 — often exceeding the build cost of a custom dashboard in a single renewal cycle. For a company at $2M in SaaS spend, the range climbs to $200,000–$400,000 annually once the program is mature.

The softer ROI elements compound this: vendor negotiations backed by utilization data consistently produce better pricing than negotiations without it. Renewal brief prep time drops from 8–12 hours per vendor to under 30 minutes. IT deprovisioning requests — which often sit in a queue for weeks — drop significantly because the process is automated rather than ticket-driven.

Payback period for a custom build is typically 6–12 months. Payback period for a SaaS management platform is 3–6 months given the faster deployment, but the ongoing license cost means total cost of ownership over 3 years often favors the custom build for companies above the $750,000 SaaS spend threshold.

The first round of negotiations using real utilization data is where the clearest ROI materializes. When you walk into a Salesforce renewal conversation knowing that 38 of your 210 seats have had zero logins in 90 days, the negotiation starts from a fundamentally different position than "we think we're paying too much."