Design license-aware software requests with procurement routing

Check real seat capacity, route shortages to procurement, and close a request only when the employee can use the paid feature.

Purchased: 40. Assigned: 40. Free: 0.

That’s the admin console for a paid design tool at 9:10 AM. Leena Natarajan’s manager approved a seat request on it before anyone looked at the pool. If the service desk treats that approval as the finish line, Leena gets a green ticket and no seat.

A license-aware software request doesn’t. It treats approval as one decision in a longer chain, not the finish line. The request checks the pool before anyone promises fulfillment, routes the shortage to procurement, and closes only when the paid feature works.

The case below is illustrative. Arcwell Studio, its people, its tool, Canvas Pro, and every count are invented to show the method, not a real deployment or measured result.

The request that arrives before the seat does

Leena, a product designer at Arcwell, requests one seat on the Pro tier of Canvas Pro. The launch work needs the Pro-only shared library export. Leena already has a free-tier Canvas Pro account and can log in.

That login proves less than it seems. An existing account doesn’t prove paid-feature entitlement. That’s the right to use a paid feature, recorded in the vendor’s admin system against a named user. Many tools let a free-tier user sign in.

The catalog doesn’t settle much either. Canvas Pro is listed, which means Leena can ask for it. The app owner still checks the access policy, which approves the Pro tier for product design. Leena’s manager, Daniel Okafor, approves the business need.

Who may approve each of those steps is an authority question, and AI agent authorization covers how to define that approved actor. None of them is a seat yet.

9:10 AM: the pool reads zero

On Day 1, Mei Lin, the license administrator, reads the Canvas Pro console and records a timestamped snapshot. A license pool is the purchased seat capacity for one product tier. Its free count excludes seats that are already assigned. Here, total capacity is 40 and free capacity is zero.

This is the moment most request forms aren’t built for. Leena’s request has a policy match and a manager’s approval behind it, and nowhere to land. You now need a rule for what happens next, set before the shortage, not invented during it.

Illustrative request routing – A current seat and budget check can lead to assignment, procurement, decline, recheck, or pool review; approval alone is not a working license.

Treat the cells as fields your team sets; this is a proposed rule, not an industry standard. Only one branch moves to assignment, and it needs a free seat. Every other branch keeps the request open with a named owner.

The last row is the one teams skip. Marking Leena “assigned” at 9:10 AM would record a seat that didn’t exist. That’s over-allocation, and it would hide the shortage from procurement.

This tree is one piece of the wider IT request journey. Intake, routing, and owner handoff around it belong to AI for IT support.

Days 1 and 2: budget, order, and a request that stays pending

Leena’s request lands on the third row. It routes to Owen Cho in procurement. Aisha Bello, the design director, approves budget for five more seats.

Three different people have now said yes to three different things. Daniel approved the need. Aisha approved the budget, which isn’t spending authority. Owen places the order under procurement’s own process, because placing it is procurement’s call.

On Day 2, the order shows as submitted. The request reads “pending procurement,” not “software delivered.” A submitted order is evidence of an order and nothing more.

Keep this pending state visible to Leena. Set three things locally: what the employee can see, a named procurement owner, and an escalation interval your team chooses. If nothing moves inside that interval, route it to a backup owner instead of letting it sit in a procurement inbox.

Day 6: the count has moved again

The console now shows 45 Pro seats purchased. It would be easy to assume five are free. Mei rechecks instead, because the Day 1 snapshot is stale.

Two queued requests were filled that morning, so 42 seats are assigned and 3 are free. Total capacity grew by five; free capacity grew by three.

Live counts drift while a request waits. Concurrent requests, freed seats, and vendor or directory sync delays all change them. That’s why availability gets read again at fulfillment, not carried forward from approval.

At 2:22 PM, Mei assigns one Pro seat to Leena’s existing account. The console’s user record shows Leena on the Pro tier, and the pool now has 2 seats free.

The export that closes the ticket

An assigned seat in the vendor console still isn’t proof the paid feature works. Some vendors let administrators switch off features inside an assigned license, and an account can sit on the wrong tier.

So the acceptance test is the job Leena asked for. With Leena’s consent, Mei asks for one test export to the shared library. The export succeeds. Leena confirms in the request, and it closes as fulfilled.

Each step above left its own record. If you reconstruct the trail, it looks like this. The state names are illustrative labels, not product fields.

Merge rows if you like, but never merge “requested,” “approved,” and “assignment confirmed.” A submitted order can’t stand in for an assignment. If a seat appears assigned while the pool showed zero, flag it as over-allocated and send it to the software asset owner. If the vendor can’t confirm assignment, the request stays open with a backup owner.

Putting a tool against the same request

Run Leena’s request, or one like it with a short pool, through any tool you’re considering. Ask four things:

• Which system holds the purchased and assigned counts, and is it read live or from a cached copy? A stale export can approve a seat that’s already gone.
• Can it keep the approver, budget holder, and procurement owner separate? Approving need, approving budget, and placing an order are three decisions with three authorities.
• What exact record marks the seat assigned, such as the user entry in the vendor’s admin system? A submitted order, a created account, or a login doesn’t count.
• What happens when two requests compete for the last seat? You want a visible hold or recheck, a named software asset owner, and a correction path, not a silent double assignment.

Computer, by DevRev can be evaluated against that same path. Ask DevRev which steps a supported configuration can read, route, or record, and which stay with your license administrator.

If you track results, compare approved requests with confirmed assignments, and in-pool with over-allocated assignments.

What Leena has, and what the owner checks next

Leena can export to the shared library. That was the ask, and no approval on its own delivered it.

Mei’s job isn’t quite over. The pool reads 45 purchased, 43 assigned, 2 free, and that number is already a snapshot. The next request should trigger a fresh read, not inherit “2.”

Two more checks are worth making now. Nobody should have been marked assigned against the empty Day 1 pool, and the five new seats should match Aisha’s approved budget.

The useful next meeting has real counts in it. Check a short-pool request against your license data with DevRev, and mark which steps stay with your license administrator.