Software License Reclamation: Idle Seats Recovered, Exceptions Respected

Seats nobody uses, and a few that only look idle

Every software contract carries seats assigned to people who left, changed teams or stopped logging in. Reclaiming them is straightforward on paper: departed users lose their seat, inactive users lose theirs after a set window, and anyone on the exception list keeps theirs. The exceptions are where it goes wrong. A seat that looks idle may belong to someone on leave, an engineer who only logs in during incidents, or a sales manager in the middle of renewal season.

The seat inventory is an Airtable base. Activity comes from Salesforce login history and GitHub organization activity, the exception list is a sheet in Google Drive, and managers answer notices by email. When engineering changes the GitHub window or a group of people come back from leave, the reclamation list gets patched for the seats someone happens to mention, and the closeout adds up savings per tool instead of per owner.

Who works in the room

Any question about a seat goes to Myco, the default agent here and the only one that can act on Salesforce users and the GitHub organization, through lasting grants the IT asset manager and the engineering manager approved for it. Fin leads the notice and objection threads once Myco opens each one with the seat IDs and outcomes as the brief. Ada reviews the report and the closeout, which the guidelines require before the IT asset manager signs.

One reclamation cycle

A cycle runs over a few weeks, and every seat change waits for a person.

A shorter window, returning users and two objections

A change to the GitHub inactivity window reaches every GitHub seat, not only the ones near the old line. Myco re-runs all of them under the full rule order. Some newly inactive seats are kept because their users are on the exception list, some are held because their users are on leave, and the rest are proposed for reclaim with the new window named as the reason.

Leave returns work the same way. A return lifts the hold, and the seat goes back through every rule, which can keep it or still reclaim it. Objections are answered one at a time: each manager gets a reply on their own thread naming the seat ID and the outcome, never a combined message that leaves someone to work out which line is theirs.

What the checks catch

• A seat inactive past the window whose user is on the exception list in Google Drive, so it is kept
• A revised GitHub window applied only to seats someone named, when every GitHub seat needs the full rule order again
• Two objections answered in one message instead of each on its own thread with the seat ID and outcome
• A closeout row that adds up one owner's savings across two tools, when each owner and tool pair gets its own row

What stays with people

• Setting the inactivity window for each tool
• Approving each reclamation before a seat is removed in Salesforce or GitHub
• Deciding each manager objection
• Sending every notice and objection reply Fin drafts

Integrations in this workflow

Kylon is not a SaaS management or IT asset tool, and it does not replace one. It sits across the inventory, the activity sources and the mail the team already uses, and keeps the coordination between them in one place.

• Airtable
• GitHub
• Gmail
• Google Drive
• Salesforce
• Slack

• Airtable holds the seat inventory, with owner, tool, monthly cost and decision on each seat, plus the closeout rows
• Salesforce supplies login history for Salesforce seats, and is where approved seats are deactivated
• GitHub supplies organization activity for GitHub seats, and is where approved members are removed
• Google Drive keeps the reclamation rules, the exception list and the report
• Gmail carries batch notices and objection replies to managers, as drafts the IT asset manager sends
• Slack is where managers raise quick questions and engineering announces window changes

Where to start

Pick one tool and one quarter. Connect the Airtable inventory and the activity source for that tool, put the exception list in the room's folder, and make one rule explicit in the room guidelines: no seat is removed until the IT asset manager approves it in the thread, and every rerun checks every rule in order.

“The seat looked idle because its owner was on leave. The exception list said so, and the check read it.”

Set it up with your agent

Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.