--- title: "Software License Reclamation With AI Agents | Kylon" description: "How an IT and procurement team reclaims idle software seats using activity data and an exception list, handles objections and leave returns, with people approving." url: "https://kylon.io/use-cases/license-reclamation" language: "en" --- [HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>Software License Reclamation: Idle Seats Recovered, Exceptions Respected Use Case8 min read # Software License Reclamation: Idle Seats Recovered, Exceptions Respected Idle software seats reclaimed from Salesforce and GitHub activity, with the exception list, manager objections and leave returns respected along the way. No seat is removed until the IT asset manager approves it. [Get started](https://app.kylon.io/sign-up) Kylon TeamProduct November 6, 2026 ## 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 People - IT asset manager Owns the reclamation cycle, approves every seat change and signs the closeout - Procurement lead Owns the vendor contracts and takes the closeout savings into renewal talks - Team managers Confirm or object to reclaiming their people's seats - Engineering manager Sets the GitHub inactivity window and approves removals from the GitHub organization Agents - MycoSeat reviewer Walks each seat in Airtable through the reclamation rules using Salesforce and GitHub activity and the exception list, proposes reclaim, keep or hold, and makes the approved changes AirtableSalesforceGitHubGoogle Drive - FinNotices and objections Drafts the batch notices to managers and the reply on each objection thread, for a person to send [Gmail](https://kylon.io/integrations/gmail) [Slack](https://kylon.io/integrations/slack) - AdaReport checker Checks the reclamation report and the closeout savings against the current inventory, owner by owner and tool by tool AirtableGoogle Drive 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. ```mermaid flowchart TD review["Myco walks each seat through
the rules in order"] ok1["IT asset manager approves
before any seat changes"] notices["Fin drafts one batch
notice per manager"] send["IT asset manager
sends each notice"] audit["Ada compares the report with
the approved decisions"] confirm["IT asset manager confirms"] window([The engineering manager sets
a new GitHub window]) objection["Myco re-checks each
seat a manager objects to"] leave["Myco re-runs returning
users through every rule"] github["Myco re-runs every
GitHub seat in rule order"] decide["IT asset manager
decides each objection"] ok2["IT asset manager
approves the changes"] reply["Fin drafts a reply per objection,
each on its own thread"] reclaim["Myco removes approved seats
and writes the closeout rows"] sign["IT asset manager signs,
procurement takes the totals"] review --> ok1 --> notices --> send --> audit --> confirm confirm --> objection & leave & github window -.- github objection --> decide --> reply leave & github --> ok2 reply & ok2 --> reclaim --> sign class review,notices,audit,objection,leave,github,reply,reclaim agent class ok1,send,confirm,decide,ok2,sign person class window event classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712 classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712 classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42 ``` | Stage | What happens | Who acts | Who decides | | --- | --- | --- | --- | | Seat review | Each seat is walked through the rules in order: departed user, inactive past the tool's window, exception list, leave | Myco | The IT asset manager approves before any seat changes | | Manager notices | One batch notice per manager lists the seats to be reclaimed and the date | Fin | The IT asset manager sends each notice | | Report audit | The reclamation report is compared with the approved decisions, line by line | Ada | The IT asset manager confirms | | Objections | Two managers object, each seat is re-checked, and each objection is answered on its own thread with the seat ID and outcome | Myco, then Fin | The IT asset manager decides each objection | | Leave returns | Returning users' holds are lifted and their seats go back through every rule | Myco | The IT asset manager approves the changes | | Revised GitHub window | Every GitHub seat is re-run under the new window and the full rule order | Myco, checked by Ada | The engineering manager sets the window and the IT asset manager approves | | Reclaim and close out | Approved seats are removed in Salesforce and GitHub, and one closeout row per owner and tool records the monthly savings | Myco, checked by Ada | The IT asset manager signs and procurement takes the totals | Stages of a quarterly reclamation cycle. Seat IDs, windows, counts and savings in this example are illustrative. ## 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](https://kylon.io/integrations/gmail) - Google Drive - Salesforce - [Slack](https://kylon.io/integrations/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. Set-up prompt Set up our software license reclamation desk in this Room. Take it one step at a time and wait for my OK before you move on. 1. Connect Airtable, GitHub, Gmail, Google Drive, Salesforce and Slack. Tell me which ones still need connecting. 2. Ask me who works this desk: the IT asset manager, the procurement lead, the team managers and the engineering manager. Help me invite them to this Room. 3. Build a Seat Reclamation App with columns Under Review, Notified, Objection and Reclaimed, one record per seat. Pull the seat inventory from Airtable and the exception list from Google Drive. 4. Walk each seat through our rules in order: departed user, inactive past our threshold, exception list, then leave hold. Use Salesforce login history and GitHub activity. Show me every seat proposed for reclaim, keep or hold, and flag any that conflict with the exception list. 5. Draft one batch notice per manager listing their seats and the reclaim date. Draft a reply on each objection on its own thread naming the seat and the outcome. The IT asset manager sends every notice and reply and approves every seat removal before anything changes in Salesforce or GitHub. 6. Write our rules and who approves which send or seat change into this Room's guideline, so every cycle follows it. 7. Build one closeout row per owner and tool recording the savings, and check it against the approved decisions line by line before the IT asset manager signs. 8. After one clean cycle, offer to turn the seat review and notice batch into an Automation. Before you start, ask me for our rules one at a time. [Get started](https://app.kylon.io/sign-up) Your first company harness. Where humans and agents run your business together. [Get started](https://app.kylon.io/sign-up) ## More Use Cases [View all](https://kylon.io/use-cases) [ ### Spare Parts Reorder Levels: Stocking Rules That Hold When One Part Changes When one part changes its lead time, criticality or supersession, every part tied to it is checked again. Agents set min and reorder levels from ClickUp work orders and Salesforce quotes in one Kylon room, and the planner approves each level. ManufacturingProcurement & vendors ](https://kylon.io/use-cases/spare-parts-reorder-levels)[ ### Localization Vendor QA: Translation Payments Priced Right and Paid Within Each Run's Cap Translation jobs are priced from word counts, rate bands, rush uplifts and late penalties, placed in payment runs under a cash cap, and re-priced when rates, holds or disputes change. Agents work ClickUp and Box, and the vendor manager approves every amount. Media, publishing & agenciesProcurement & vendors ](https://kylon.io/use-cases/localization-vendor-qa)