Your service desk commits company money every day, and almost none of it shows up as a decision anybody made.
An employee asks for access to an AI tool, their manager clicks approve, the account gets provisioned, sign-in works and the ticket closes. By every measure you track that’s a clean result: fast, verified, one happy employee.
Nobody answered the expensive questions, though. Was there a paid seat sitting free, or did this one trigger a new purchase? Does the tool bill AI usage on top of the seat? Which budget owns that usage, and who looks at the account when the project wraps up?
This used to be a rounding error, because a seat was a seat and the price was fixed for the year. That stopped being true once vendors started stacking metered AI usage on top of the seat. Zylo’s 2026 SaaS Management Index, built on more than 40 million licenses, found that organizations leave 36% of their licenses unused on average while spend on AI-native apps more than doubled. In the survey that ran alongside it, 78% of 218 IT leaders said they’d been hit with unexpected consumption-based or AI pricing charges. Zylo sells SaaS management, so treat the precision loosely, but you’ve probably seen both halves of that in your own renewal spreadsheet: seats nobody uses, and bills nobody expected.
I believe the access request is where this gets fixed, and that a fulfilled request should carry its spending decision with it. Routine, funded access should move fast. A new commitment, an unclear owner or open-ended consumption needs someone to actually decide, and the employee should be able to see which of those two lanes they’re in.
Why did Freshworks buy Torii?
On 12 October, Freshworks announced a definitive agreement to acquire Torii, a SaaS management platform, to extend Freshservice into software management and AI spend governance. It didn’t hang around either, because on the 3 November earnings call leadership said the acquisition was already done in October.
Read that as a bet about location. A service desk vendor has decided the valuable spot is the point where an employee asks for a capability, joined to the data you need to govern what that capability costs, and it’s the right bet. What it doesn’t prove is that the combined product delivers any of this yet, because the integration is weeks old and nobody outside Freshworks can judge it.
It also isn’t a new idea, whatever the launch decks say over the next year. Microsoft’s Entra entitlement management tutorial has long modeled access packages with manager approval, expiration after a year and annual access reviews. Lifecycle governance exists; what’s rare is an access process that knows the commercial terms behind a grant and notices when usage changes them.
“Approved” is doing far too much work
A manager’s “approved” can mean three different things:
This person needs the application.
This team will fund a new seat.
This project can consume a metered service up to an agreed limit.
Those can belong to three different owners, and in most queues the request record can’t tell them apart. So the manager answers the first question, which is the easy one, and the ticket quietly treats the other two as answered.
The fix is to route by what the request actually commits you to. If the app is already approved, the role fits and a paid seat is sitting free, an automated grant is the right answer and no human needs to touch it. If the request needs a new purchase, it goes to the person who can commit the money. If access opens a metered service, provisioning should carry the agreed usage scope into whatever enforcement the provider supports.
Watch for the things that look like decisions and aren’t. A cost-center field attributes spend; it doesn’t mean anyone approved it. An approval email doesn’t prove the provisioned role matches the approved one. A budget alert tells someone usage is high, and it does nothing to stop the next call.
The FinOps Foundation’s Licensing & SaaS capability frames licensing as work shared across engineering, finance, procurement and legal, shaped by vendor licensing terms, use rights and pricing. The service desk is the only place in that chain that sees the request at the moment of need, which makes it the right place to collect that context and keep it attached to the grant.
Is a reclaimed seat really money saved?
Usually not, at least not yet.
Take two requests for the same app. One lands on a seat you already pay for, and the other pushes you past your purchased quantity. Both employees need the identical permission and the provisioning API returns the same success for both, but the economics have nothing in common: the first uses capacity someone else could have had, and the second may create a new commitment or an overage, depending on the contract.
The same logic runs in reverse at offboarding. Reclaiming a seat frees capacity, can avoid the next purchase and can support a lower renewal quantity. It only becomes cash when the contractual payment actually falls. If your contract is fixed until renewal, reporting the reclaimed seat’s list price as savings this quarter overstates the result, and once finance catches one inflated number it stops believing the rest.
Metered AI adds a second layer on top of all this. The FinOps Foundation’s guidance on AI token costs from direct model providers, updated 28 October, recommends mapping every API key to one team, application and cost center with a named owner, tying unit costs to an outcome someone owns, keeping a tested process for immediate revocation, and setting budget controls per key or application. It’s written for API-based services, so don’t assume every SaaS vendor exposes the same controls. The principle still carries: every consumption point needs an owner before it needs a dashboard.
Put the cost context in the request
A workable access record needs a short list of facts: the employee and role, the business purpose, the app owner, the funded capacity or budget owner, and the date the decision gets reviewed. If usage is variable there’s one more, which is what can actually limit it.
Take a six-week AI pilot. A good record says who can use it, which work it supports, what data may go into it, who owns the spend and when it ends. Any spending threshold should say what it does: alert, require review, throttle or stop. Those are four different controls with four different consequences for the person doing the work, and you’d be surprised how often a “limit” turns out to be the first one.
When a provider can’t enforce the limit you asked for, the workflow should say so out loud. Depending on the risk you might put a gateway in front of it, narrow the access, watch it more closely or shrink the pilot. What you shouldn’t do is call a notification setting a hard cap.
This is how we think about access workflows at Ravenna. The request is the one moment you know exactly why someone needs a tool, so that’s where the context gets captured, the right approver gets gated in and the reason gets logged next to the grant.
That logged reason earns its keep at review time, because a login count on its own tells you very little. A rarely opened compliance tool can be essential; a heavily used AI workflow can still need a redesign if its cost grows faster than its value. Link the original reason to the review and renewal becomes an informed decision instead of an argument over a list of active accounts.
Won’t this slow down every request?
It will if you do it badly, and that’s the fair objection. Slow access has a real cost, and employees will find a workaround the moment the approved path gets painful (a personal card and an expense report is the worst version of this whole problem).
The fix is to decide routine policy in advance. An approved app, the right role and a free funded seat should take the fast lane, ideally without a human touching it. A new supplier, a privileged role, unusual data use or a new spending commitment goes to review, and the employee can see exactly what’s waiting and who has to act. The FinOps Foundation’s SaaS guidance makes the same case for tiering: high-touch management for core, high-spend apps, and lighter governance for the long tail. A cheap utility and a high-consumption automation service shouldn’t share an approval path.
You also don’t need to buy all of this from one vendor, whatever the acquisition headlines suggest. Consolidation might make the context easier to join, and so can specialist tools with solid integrations. Either way, test whether data and decisions actually travel between systems, especially through failed provisioning and offboarding, because that’s where they break. An acquisition announcement is a reason to ask those questions, and it doesn’t answer any of them.
Stop grading access on speed alone
Time to verified access is a fine metric and a terrible only metric, because it rewards closing tickets whose spending question nobody answered. For a pilot, pair it with a few measures of decision quality:
How often did the grant match the approved role and duration?
How much paid-for capacity got reused instead of repurchased?
Which accounts hit their review date with no owner?
How long did exceptions wait for the right decision-maker?
Report the financial side in three separate buckets: capacity recovered, future purchases avoided and cash actually saved. Keep the assumptions visible, and pair any usage number with a verdict from whoever owns the business outcome.
Start with one application where your access queue and your renewal spreadsheet tell different stories. Connect each request to its owner, entitlement, cost model and review date, and see how much of the gap closes.
A closed ticket should mean the employee can work. It should also mean you know what you agreed to provide, who’s paying for it and when you’ll decide again. Your service desk is already making these spending decisions, so make them on purpose.
Frequently Asked Questions
What Is Software License Optimization?
Software license optimization means matching what you pay for to what people actually use: right-sizing seat counts, moving users to cheaper tiers and reclaiming licenses nobody touches. Recovered seats only turn into cash at renewal, or when your contract lets you reduce the quantity, so track capacity recovered separately from money saved. The most useful input is the reason each person got access in the first place, which usually lives in the original access request.
Why Is User Access Review Important?
A user access review confirms that everyone still needs the access they were granted, and auditors for frameworks like SOC 2 and ISO 27001 expect to see evidence that you run them. It also catches seats you’re still paying for after a project ends or someone changes teams. Reviews go much faster when every grant carries an owner, a business purpose and a review date from day one, instead of a reviewer guessing from a list of active accounts.
How Can I Identify Unused SaaS Licenses?
Compare assigned licenses against sign-in or activity data from your identity provider or each app’s admin console, and flag accounts with no activity over a window you set, such as 90 days. Accounts that belong to people who’ve left are the quickest wins, so check those against your offboarding records first. Confirm with the app owner before you reclaim anything, because a rarely opened tool can still be essential.
How Do You Automate Software License Management?
Automate the routine path and route the exceptions. A request for an approved app with the right role and a free, funded seat can be approved and provisioned without anyone touching it, while a new purchase, a privileged role or unusual data use goes to the person who can actually sign off. Attach the owner, cost center and review date to every grant, so reclamation and renewal decisions run off that record instead of a spreadsheet.
