Software asset research
Why SaaS Seat Utilization Numbers Disagree
The denominator problem in license reporting: licensed, assigned, and active seats measure different things, and shared accounts break all three.
Use this benchmark to size repeatable IT work, set the review cadence, and decide what stays with the technical owner before assigning the workflow to an IT virtual assistant.
Research playbook
On this pageJump to section
Key stats
Key takeaways
Two teams can open the same SaaS admin console and report utilization figures that differ by thirty points. Neither is necessarily lying. They are dividing different things by different populations.
This paper sets out the definitions that make a utilization number reproducible, and the cases where the honest answer is a range rather than a single percentage.
The denominator is the whole argument
Utilization is active seats divided by some base. The base might be purchased licenses, assigned licenses, eligible employees, or accounts with a login in the period. Each produces a different number and answers a different question.
Finance usually wants purchased licenses, because that is what it pays for. IT usually wants assigned licenses, because that is what it manages. Security wants active accounts, because that is the attack surface.
Name the base in the report title. "Assigned-seat utilization" and "purchased-license utilization" should never share a dashboard tile without labels.
Licensed, assigned, and active are different states
A license can exist in the contract without being assigned to anyone. An assignment can exist without any recent activity. Activity can exist on a shared account that belongs to no individual.
Record all three counts for the same date. The gaps between them are the findings: unassigned licenses are a purchasing issue, dormant assignments are a management issue, and unexplained activity is a security question.
Do not let the admin console's default report decide the definition. Export the raw lists and compute the figures yourself.
Activity windows change the story
A thirty-day activity window flatters seasonal tools and penalizes quarterly ones. A ninety-day window does the reverse. Neither is wrong; the window has to match the work pattern.
For tools used at month end, compare activity in the last complete month rather than the last thirty days. For tools used during onboarding, measure against new hires rather than the whole population.
Report the window and the extraction date. A utilization figure without both is not reproducible.
Shared and service accounts break the model
A shared mailbox, a scheduling account, or an integration account may show constant activity with no human owner. Counting it as an active seat overstates human utilization; excluding it understates the real cost.
List shared and service accounts separately with their owner and purpose. Do not fold them into the human utilization percentage.
For integrations, confirm the credential owner in the source system. The SaaS admin panel often shows the person who created the token, who may have left.
Sampling and instrumentation limits
Some products report only the last sign-in, some report feature-level events, and some report nothing beyond an audit log. The measurement method has to fit the product.
If the only available signal is sign-in, say so. Sign-in is a weak proxy for value, because a user can sign in to check a notification and do nothing else.
Where activity data is missing, mark the seat as unknown and review it through the owner rather than inventing a number.
A defensible reporting method
Publish a one-page definition: product, base population, activity window, extraction date, and exclusions. Then publish the counts for licensed, assigned, active, and unknown.
Use a range where the data supports one. "Between 62 and 71 percent of assigned seats showed activity in the quarter" is more honest than a single decimal.
Attach the export and the query. The next analyst should be able to reproduce the figure without asking which report was used.
Limitations
Utilization is not value. A seat used daily for a trivial task may be less valuable than one used monthly for a critical process.
The method does not account for contract minimums, true-ups, or multi-year pricing. Those belong in the commercial review.
Local definitions should be stable across quarters, but they are not industry benchmarks.
Benchmark brief
What this research page must produce
A practical estimate for volume, review time, escalation rate, and assistant capacity.
A clear split between routine support, preparation work, and technical ownership.
What the why saas seat utilization numbers disagree data shows
Treat this as a planning benchmark, not a universal number. Compare the benchmark against your ticket volume, SaaS stack, documentation backlog, and support risk before assigning recurring work.
The useful output is a decision about capacity, not a static statistic. If the workflow is high volume and low judgment, an IT virtual assistant can absorb coordination and upkeep. If the workflow is low volume but high risk, keep it with the technical owner and use the assistant only for preparation, reminders, and documentation.
Workflow
Recommended operating workflow
Collect a baseline
Pull the last 30 to 90 days of examples related to why saas seat utilization numbers disagree, including completed work and unresolved exceptions.
Classify the work
Tag each item by routine admin, manager approval, technical decision, security risk, or vendor dependency.
Set the operating number
Use the median weekly volume and review time to decide how many assistant hours the workflow deserves.
Refresh the benchmark
Recheck the numbers quarterly so tool growth, new systems, and security requirements do not silently change the scope.
Decision rules
| Metric | Use it to decide | Manager action |
|---|---|---|
| Weekly volume | Whether the workflow is worth assigning as recurring assistant work. | Approve a weekly capacity target and backlog threshold. |
| Access sensitivity | Whether the assistant can work directly or only prepare review notes. | Set least-privilege permissions and removal dates. |
| Escalation rate | Whether the workflow is stable enough to delegate. | Rewrite the SOP when exceptions exceed the agreed threshold. |
Consolidated statistics
| Statistic | Figure | Source |
|---|---|---|
| Authoritative sources | 5 | Declared source register |
| Seat states tracked | 4 | Proposed schema |
| Provider performance claims | 0 | Scope boundary |
Sources
- Cybersecurity Framework 2.0Used for the governance and continuous-improvement framing of the measurement routines described here.
- Cross-Sector Cybersecurity Performance GoalsUsed as a public reference for baseline security practices that small teams can measure without a bespoke framework.
- Security and Privacy Controls for Information Systems, SP 800-53 Rev. 5Used for control-language on access, audit, and configuration management. It does not prescribe the local metrics in this paper.
- Standards for Internal Control in the Federal Government (Green Book)Used for the separation of design, operation, and evidence in the review protocols.
- Security-Focused Guide for Configuration Management, SP 800-128Used for configuration inventory and ownership concepts applied to license assignment records.
Measurement checklist
| Field | What to capture | Owner |
|---|---|---|
| Volume | Weekly request count, backlog age, and repeat issue patterns | Assistant prepares, manager reviews |
| Risk | Access level, customer impact, security sensitivity, and approval needs | Technical owner |
| Cadence | Daily, weekly, monthly, or quarterly review rhythm | Manager |
| Evidence | Sample tickets, logs, screenshots, and before-after examples | Assistant collects, owner validates |
| Escalation | Triggers, approval path, response time, and stop-work rules | Technical owner |
How to read the result
A good research page should leave the manager with a working number and a clear boundary: what the assistant can do every week, what the assistant can prepare for review, and what must never move without the accountable technical owner.
Source and refresh note
This planning page is dated for 2026 and should be refreshed quarterly as tool stacks, ticket patterns, and security expectations change.
How should teams use this benchmark?
Use it to define task volume, access limits, review cadence, and escalation rules before assigning work.
Get free benchmark review