AI Seat Reviews: Who Had Access, Who Used It and Who Benefited?

You buy 20 AI seats for a small agency. At renewal, the dashboard shows eight active users. One manager sees twelve seats to cut. Another sees twelve people to train. Both may be working from the same number, and neither has enough information to make the decision.

The question is what those people had a fair chance to do. Some may have received access yesterday. Some may only need the tool during a monthly reporting cycle. Others may have tried it on a real job and found that checking the output took longer than doing the work themselves. Those are different reasons for a quiet dashboard, and each suggests a different response.

Start with three different questions

An access report tells you who was assigned a seat. An activity report tells you who met a defined condition during a particular period. A work review tells you whether the tool helped with something the business needed. Write those three questions separately at the top of your renewal notes. Otherwise, a single percentage can end up standing in for all three.

GitHub Copilot offers a concrete example. GitHub documents a seat assignment endpoint for organisations and separately describes usage measures such as weekly active IDE users, counted as distinct people over a rolling seven-day window. Assignment and observed interaction are separate records. Even within activity, the window and the surface matter: an IDE measure answers a question about activity in a coding editor.

GitHub also announced in June 2026 that certain enterprise reports would incorporate additional server signals. That change could bring users into the top-level count even when detailed information about their activity was missing. For a manager, the lesson is to ask whether the measurement changed before treating a change in the chart as a change in behaviour. The same caution applies when your team switches tools or changes which events it tracks.

Give the numerator a denominator it belongs to

Return to the hypothetical agency. Suppose eight distinct people recorded a qualifying action this week. The month-end roster lists 20 seats, but eight were assigned on Friday afternoon. All eight active users came from the 12 people who had access for the full week. Eight out of 20 describes observed use relative to the closing seat count. Eight out of 12 describes activity among people with access throughout the week. Both can sit in the same review, provided each is labelled and the new assignments are visible.

That distinction also protects you from a subtler mistake: dividing everyone who used the tool during the month by the number of seats assigned today. If people left the pilot and their seats were reassigned, some users in the numerator may be missing from the denominator. A workable small-team report uses a named cohort for each comparison. Define who was eligible, which dates count and which actions qualify, then count people from that group once each.

Choose an activity window that fits the job. A seven-day window is plausible for a daily coding assistant. It may tell you very little about a tool bought to assemble quarterly proposals. If you change the window, show the old and new views side by side for one review. That gives colleagues a chance to understand why the figures differ.

Check what happened after someone opened the tool

Even a well-defined activity count leaves the renewal question open. Imagine that six people generated drafts for client proposals, but four spent extra time checking unsupported claims. Meanwhile, two colleagues used the same tool once each to restructure a long brief and kept most of the result. A ranking by requests would give the busiest users the most attention. Looking at the work might send you in the opposite direction.

Ask a few people to bring one completed task to a review. Compare what they delivered with their usual method. Include preparation, checking, corrections and any handover a colleague had to do. Keep the sample modest and say what it can establish: a handful of examples can explain why a use case is worth testing further, but they cannot tell you how much time the whole team saves.

Keep the cost decision separate, too. Our guide to splitting a shared AI bill explains why the amount attributed to a team can differ from the cost a business can actually avoid. Before removing access, ask what the contract or plan lets you change and when. A seat that can be reassigned calls for a different decision from a charge that can be removed at renewal.

Run a review that leads to a decision

• Set the scope. Name the job, the people expected to do it and the dates when access was available.
• Separate the signals. Report assigned seats, distinct users with qualifying activity and a small sample of completed work. Note gaps in visibility.
• Ask before acting. Find out whether quiet seats reflect missing access, an occasional task, a poor fit or a better method already in place.
• Choose a next step and a review date. Keep, reassign or trial fewer seats. Record what evidence would make you reverse the decision.

For an independent creator reviewing a single subscription, the exercise is even smaller. Write down the last two jobs where you expected to use it. If you used it, record what survived into the final work and what you still had to check. If you skipped it, write down why. A renewal conversation is most useful when it ends with a clear account of what the licence lets you do and whether you still need it.

Sources

• GitHub Docs: REST API endpoints for Copilot user management.
• GitHub Docs: Interpreting usage and adoption metrics for GitHub Copilot.
• GitHub Changelog, 15 June 2026: Copilot usage metrics now include more of your active users.