Seat Allocation for AI Tools: Who Gets Access and Who Waits

A workable allocation rule has two gates and one tie-breaker. Both gates must pass. The tie-breaker resolves the queue.

Gate 1, role fit. Does the person's role require the tool for a named, recurring task? "Requires" means the task is on their job description or their team's charter and the tool changes how fast or how well it gets done. "Might be useful" is not role fit. Write the tasks down, per role, before the rollout. For a support team the tasks might be drafting replies and summarizing tickets. For a data team they might be generating SQL and reviewing diffs.

Gate 2, weekly use. Has the person used the tool at or above a threshold in the trailing measurement window? You cannot measure this before granting a seat, so this gate applies to renewal and to reassignment, not to first grant. For first grants, run a two-week trial on a shared or low-cost tier, then measure.

Thresholds that hold up. Set the bar where the tool stops being an experiment and starts being part of the workflow: at least three distinct active days in a week, or at least ten substantive sessions per month. Microsoft's own definition of an active Copilot user requires at least one intentional interaction, a submitted prompt or deliberate engagement with a feature in a supported app, as noted in this guide to Microsoft license reclamation. That is the floor for counting as active at all, not the bar for justifying a premium seat. A user who opens the pane and never submits a prompt registers zero.

The tie-breaker: frequency of a task the tool accelerates. When two people pass both gates and one seat is available, count how often each performs the task. A person who writes thirty customer replies a week beats a person who writes four, even if both are in suitable roles.

Here is a scoring rule you can run in a spreadsheet. Score each candidate weekly, keep the top scores seated, and hold the rest.

# Weekly seat scoring. Scores above 0 pass both gates.
def seat_score(role_required, active_days, task_frequency, data_tier_ok):
    if not role_required or not data_tier_ok:
        return 0  # fails gate 1, no seat, waitlist with reason
    if active_days < 3:
        return 0  # fails gate 2, retest next cycle
    # Rank seated candidates by task frequency, 1-5 scale
    return task_frequency

people = [
    {"name": "support_lead", "role_required": True,  "active_days": 5, "task_frequency": 5, "data_tier_ok": True},
    {"name": "analyst",      "role_required": True,  "active_days": 4, "task_frequency": 3, "data_tier_ok": True},
    {"name": "designer",     "role_required": False, "active_days": 2, "task_frequency": 2, "data_tier_ok": True},
    {"name": "researcher",   "role_required": True,  "active_days": 3, "task_frequency": 4, "data_tier_ok": False},
]
ranked = sorted(people, key=lambda p: -seat_score(
    p["role_required"], p["active_days"], p["task_frequency"], p["data_tier_ok"]))

Run it, and read the output as a decision, not a ranking. In the sample above the support lead and analyst are seated, the designer is waitlisted on role fit and usage, and the researcher is waitlisted on data tier even though the role requires the tool. The last case is the one teams get wrong: a strong candidate with a data restriction is a governance problem, not a budget problem, and no number of active days fixes it.

Add a third gate you keep separate from the score: data tier. Whatever the tool's approved data classes are, the candidate must handle only data at or below that level. This is the point at which the acceptable use policy and the seat list have to agree. The ICOM generative AI policy, for example, forbids sharing restricted or confidential data with any generative AI system and tells users to limit AI input to public and, in some cases, internal data, as set out in that policy. If a candidate's daily work is confidential by default, the seat does not help them.

For agents and skills, the rule needs an extra column. An agent Skill is often just a markdown file on an employee's machine, and it executes with that employee's own permissions, able to read files, call APIs or run shell commands, as Backslash Security's vetting guide explains. That means an agentic capability is a seat in a different sense: the permission scope it inherits is the allocation, and it has to be reviewed at the same cadence as a license.

Before you write the rule, check that the tool bills the way you assume. Seat pricing is not one thing, and agentic products break the analogy with a desk license.

The CoreView figure cited in the reclamation guide is that up to 44% of Microsoft 365 licenses in enterprise organizations are underutilized, oversized or inactive at any given time. That is a general software figure, not an AI-specific one, but it frames the baseline: assume a meaningful share of what you assign will not be used, and design the review to find it.

The three-number habit from Zluri's license management guidance is the cleanest way to see the problem. Track purchased, assigned and used separately. Purchased minus assigned is shelfware, fixed at renewal. Assigned minus used is the harder gap, because it looks legitimate on every report and is fixed only by an operational reclaim process. For AI tools, add a fourth number: assigned minus used within a data class the tool is approved for.

Consumption-based models need their own guardrail. A seat-based mental model will not catch an agent that fires tool calls all night. Cap the budget per team, alert at 80% of the cap, and require approval to raise it.

A waitlist is not a parking lot. It is a demand signal, and it should be designed to produce decisions. Three properties make the difference.

Every entry has a reason code. Store why the person is waiting: role fit not met, usage below threshold, data tier not approved, or capacity exhausted. Reasons drive different actions. Role fit and usage get retested. Data tier goes to security for a tool or configuration change. Capacity goes to the budget holder as evidence for the next true-up.

Every entry has a review date. Put a date on it and honor it. A waitlist without dates becomes a silent denial, which pushes people back to personal accounts. Cadence suggestion: weekly for capacity decisions, monthly for role fit and usage retests, quarterly for data tier reviews.

The list is visible to the people on it and to the managers who own the queue. The reason codes prevent disputes because the criteria are public. Position tracking is a familiar mechanic from consumer waitlists, where every signup sees their queue position in real time, described as the strongest referral mechanic in LaunchList's waitlist product. For internal tooling the equivalent is a shared dashboard, not a public page.

A worked example. A 400-person company buys 120 seats. Requests arrive for 190. Role fit eliminates 30 immediately (people whose tasks do not need the tool). Data tier eliminates 15 more (their work is confidential by default). That leaves 145 eligible for 120 seats. Rank the 145 by task frequency. The top 120 are seated for one quarter. The remaining 25 receive a reason code and a review date, and their managers see a single number on the dashboard: 25 eligible, unseated, waiting.

That number is the input to the next renewal conversation. It is also the answer to the question "why did we buy 120 seats?" which is much easier to defend than "we bought what last quarter's requests suggested."

Reclamation is the discipline that keeps the waitlist moving. It needs an inactivity rule, a review step and a reversal path.

Step 1. Define inactivity precisely. Choose a threshold and state what counts as activity. Thirty days without a login is the common starting point in access tooling: Serval's automated reclamation describes a policy such as 30 days since someone last logged in, with the seat either removed automatically or sent to a reviewer first. For AI tools, logins are a weak proxy. Use submitted prompts or completed sessions, the same signals that define an active user.

Step 2. Exclude absence and ambiguity. People on parental leave, medical leave or long projects should not lose a seat for a reason unrelated to use. The same Serval page notes a background agent that skips people on leave, asking for approval before removal by default. Whatever tool you use, maintain a suppression list and keep it current.

Step 3. Review, then revoke. A reviewer sees the usage evidence, the suppression status and the reason. Approval or rejection is logged. Removal happens through the same channel that granted access, so there is no second integration to maintain.

Step 4. Notify before and after. Send the notice before removal with the evidence attached, and a confirmation after with the path to request the seat again. The notice is what makes the process feel fair rather than arbitrary.

Step 5. Handle missing data as missing, not as zero. If your telemetry has no record for a user, skip them. Treating silence as inactivity is the classic automation failure, and Serval's own design notes make this explicit: missing data never triggers a reclaim, because a sweep with no last-login record for an application is skipped rather than treated as inactivity.

A simple monthly workflow looks like this:

Every 1st of the month:
  pull active_days and last_session per seat
  drop seats with no telemetry from the sweep
  drop seats with an active suppression flag
  flag seats with active_days == 0 for 30 days
  send each flagged user a notice with their evidence
  hold 5 business days
  reviewer approves or rejects each flag
  revoke approved seats, log decision, add user to waitlist with reason
  publish counts: seats freed, waitlist cleared, waitlist added

The numbers to report each cycle: seats freed, seats reassigned, waitlist entries cleared, waitlist entries added, and seats revoked then re-requested within 30 days. That last metric is your false-positive rate. If it climbs, your threshold is too aggressive or your suppression list is incomplete.

Agentic products break two assumptions in the seat model. First, one person can consume the output of many runs. Second, the permission scope matters more than the count of humans.

The first is a budgeting problem. If your contract is consumption-based, a single agent workflow can generate more billable activity than a dozen chat users. The allocation question stops being "who gets a seat" and becomes "which workflows get a budget and who owns the cap." Assign each agent workflow an owner, a monthly cap and a review point, and treat the cap as the seat.

The second is a permission problem. Because Skills and MCP connections execute with the requesting user's access, an approved agent can reach data the user is not cleared for if the connection is misconfigured. That is why approval has to be continuous rather than a one-time intake: allowlist approved components, denylist risky ones, block violating actions inline before execution, and retain audit records of agent runs, as the same vetting guide recommends. Map MCP servers into the same review as the Skill, since the agent reaches external tools and data through them.

There is a measurement trap here too. Session counts and active days were designed for interactive use. For agents, measure successful task completions and steps per completion. A workflow with high step counts and low completion rates is a candidate for rework, not more budget.

Three placements work, in descending order of effort.

In your identity provider. Groups become the granting mechanism, and reclamation removes group membership. This is the lowest-friction option and it keeps access and billing aligned. Its weakness is that AI-specific usage telemetry often lives in the vendor's console, not the IdP, so the inactivity signal is thin.

In a SaaS management or access platform. Usage data from multiple tools lands in one place, and reclamation policies apply per app. CloudFuze's optimization guide frames the loop as discover, measure, act, repeat, with utilization analysis across 30, 60 and 90 day windows. That is the right cadence for a monthly review, and the window choice is a real decision: 30 days is fast and noisy, 90 days is stable and slow.

In a spreadsheet. Acceptable for the first quarter while you establish thresholds, and unacceptable once the seat count and the tool count both grow. The failure is not accuracy, it is latency: manual data goes stale before the decision is made.

Whichever you choose, publish the rule alongside the seats. The rule is what makes the waitlist defensible and the reclaim process uncontroversial. If a person can read the criteria and predict their own outcome, you have solved most of the political problem. If you are still choosing which tools and vendors to standardize on before setting the rule, a short consulting call can sort the shortlist, and once the approved list is fixed, routing all of those models through a single prepaid API key with one bill simplifies the per-team cost attribution that the seat rule depends on.