A utilization review is not an audit. An audit implies something went wrong. A utilization review is a routine check-in on whether the tools your company pays for are still earning their keep - the same way you'd review any operational expense. The goal isn't to find someone to blame; it's to make a quarterly decision about each tool.
Done consistently, a quarterly review prevents the compounding waste that builds up when SaaS subscriptions run on autopilot. This guide walks through the process from inventory to action list.
Before You Start: What You Need
To run a meaningful utilization review, you need:
- A current SaaS inventory - every active subscription with vendor, cost, seat count, owner, and renewal date
- Admin access to utilization data - or a single person who can pull it from each tool's admin panel
- A 30-day active user benchmark - the number of users who performed a core action in the past 30 days
- Time: 2-3 hours for a typical 20-30 tool stack
If your inventory doesn't exist yet, building it is the prerequisite. Pull every recurring software charge from corporate cards and invoices for the past 12 months. Categorize and assign owners. That work surfaces everything you need to run the review.
Step 1: Confirm the Inventory Is Current
Before pulling utilization data, verify the inventory reflects reality. Over the past quarter:
- Any new tools added?
- Any tools cancelled or no longer in use?
- Any employees who were assigned as owners and have since left?
Stale inventory produces stale results. Five minutes updating the list before starting saves confusion later.
Step 2: Pull Active User Counts
For each tool, retrieve the number of users who were active in the past 30 days. The definition of active depends on the tool:
- Communication tools (Slack, Teams): messages sent, reactions, or files shared
- Project management (Asana, Linear, Jira): tasks created, commented on, or status updated
- Design tools (Figma, Canva): files opened or edited
- Document tools (Notion, Confluence): pages created or edited
- Development tools (GitHub, Gitlab): commits, pull requests, or code reviews
Use the tool's native admin reporting where available. For tools without built-in usage reporting, last-login date is a reasonable proxy for active user count.
Platforms like Productiv and BetterCloud aggregate utilization data across multiple tools in one dashboard, which reduces the time for this step significantly.
"A utilization review is not an audit. An audit is adversarial. A review is operational - you're asking which tools earned their keep this quarter and which ones are on notice." -- Dennis Traina, founder of 137Foundry
Photo by RDNE Stock project on Pexels
Step 3: Calculate Cost Per Active User
For each tool, calculate the cost per actively engaged user:
Cost per active user = Monthly spend / Active users in the past 30 days
This normalizes costs across tools of different sizes and makes comparison meaningful.
A $500/month tool with 40 active users ($12.50/user) is more efficiently used than a $300/month tool with 8 active users ($37.50/user), even though the first tool costs more in absolute terms.
Run this calculation for every tool. Sort the results from highest to lowest cost per active user. The top of the list is where the review conversation starts.
Step 4: Flag Tools Below the Utilization Threshold
A common threshold: flag any tool where active users are below 70% of purchased seats. At 70%, you have some buffer for variation - not everyone uses every tool in the same 30-day window. Below 70% indicates systematic underuse.
Create a short list of flagged tools. For each one, note:
- Purchased seats vs. active users
- Cost per active user
- Renewal date
- Owner
This list goes to the tool owners for review. The owner's job is to explain whether the utilization reflects a temporary trough (onboarding in progress, project just wrapped) or a structural mismatch (seats that were never fully adopted).
Step 5: Calculate the Waste Reduction Opportunity
For flagged tools, calculate the cost reduction if seat count were reduced to 80% of current active users (leaving a 10% buffer above current active count):
Waste opportunity = (Current seats - Target seats) x Price per seat x 12 months
Target seats = Active users x 1.10 (10% growth buffer)
Sum this across all flagged tools. That number is the annual savings available without canceling any tools - just right-sizing seat counts.
For a 100-person company with a typical SaaS stack, this calculation usually produces a $15,000-40,000 annual savings opportunity from seat waste alone.
Step 6: Review Tool Overlap
While reviewing individual tools, look for functional overlap between tools. The quarterly review is a good time to ask: are we paying for two tools that do substantially the same thing?
Common overlaps:
- Two project management tools (engineering uses Jira, everyone else uses Asana)
- Two document storage platforms (Google Workspace + a department-level Notion)
- Two communication channels that serve overlapping purposes
Overlaps don't always lead to consolidation - sometimes the different tools serve different workflows legitimately. But identifying the overlap makes the question explicit. When the cost-per-active-user is high on one of the overlapping tools, the case for consolidation strengthens.
G2 is useful for comparing tools in the same category. The side-by-side comparison view lets you verify feature overlap before raising consolidation as a recommendation.
Step 7: Build the Action List
The output of the review is a short action list:
- Seat reductions: tools where seats will be reduced at next renewal, with the target count and timeline
- Tools on notice: tools with high cost-per-active-user and a review scheduled before next renewal
- Cancellation candidates: tools where the utilization data suggests the tool is no longer actively used
- Consolidation investigations: tool pairs with significant overlap that warrant a deeper comparison
Each item needs an owner and a timeline. Without these, the action list doesn't produce action.
Step 8: Schedule the Next Review
The last step is setting the date for the next review. Quarterly means doing this four times per year. Calendar entries are the minimum infrastructure.
The software as a service overview on Wikipedia covers the subscription licensing model in detail - understanding how SaaS contracts typically work (seat commitments, renewal terms, cancellation windows) informs how you structure the action list timeline.
For tools with annual renewals, the quarterly review calendar should always be compared to the renewal calendar. Any tool coming up for renewal in the next 90 days should be on the review agenda this quarter, not next.
What a Mature Review Process Looks Like
After two or three quarters, the review gets faster. The inventory is clean. The tool owners know their renewal dates. Utilization pulls take minutes. The conversation shifts from "do we know what we're paying for?" to "how do we optimize what we know?"
This guide to SaaS cost reduction from 137Foundry covers vendor negotiation, SaaS governance, and the procurement changes that prevent sprawl from rebuilding after the initial rationalization. The quarterly review is one component of a complete SaaS management process.
Companies that run this process consistently find that their SaaS spend grows at a rate closer to headcount growth rather than outpacing it - which is where the budget should be in the first place.
Top comments (0)