SaaS administration
Reclaim Dormant SaaS Seats Without Breaking Access
A reversible process for finding unused SaaS licenses, proving dormancy, and removing seats without cutting off a shared workflow or an integration.
Start with repeatable IT work that has a clear owner, clear access limits, and a review cadence. Keep risky technical decisions with the manager or provider who owns the system.
Delegation playbook
On this pageJump to section
License cleanup usually starts with a finance question and ends with a support incident. Someone exports the user list, sorts by last login, removes the quietest accounts, and discovers two weeks later that one of them owned a scheduled report and another was the only admin for an integration.
A safer workflow treats every seat as a small case with evidence, an owner, and a reversible step. The goal is not to remove the most seats this month. It is to remove the right seats and be able to explain each decision.
Define dormant in a way people can defend
Pick a definition before looking at the data. Common options are no sign-in for 90 days, no meaningful activity for 60 days, or no activity since the last billing cycle. Each produces a different list, so the definition has to match the reason for the cleanup.
Write the definition down with its exceptions. A user on parental leave, a contractor between projects, or an account used only at quarter end will look dormant under a naive rule. The definition should name those cases so the review does not relitigate them every month.
Record the data source and the export time. A seat list without a timestamp is not evidence; it is a snapshot someone will misread later.
Build one evidence row per seat
For each candidate, capture the account identifier, display name, manager, license type, assignment date, last sign-in, last meaningful action, and any admin role. Add a column for dependencies: integrations, scheduled exports, shared folders, and API tokens the account owns.
The last column is the one that prevents incidents. Many SaaS products attribute background jobs to the user who created them, so a dormant human account can still be the effective owner of a live automation.
Mark each row as confirmed dormant, likely dormant, active, or unknown. Unknown is a legitimate result. It means the evidence is incomplete, not that the seat is safe to remove.
Confirm the owner, not just the user
The manager confirms whether the person still needs the tool. The system owner confirms whether the account holds anything the organization still depends on. These are different questions and often different people.
Ask both in the same message so the answers arrive together. A template works: "We are reviewing this seat. Does the person still need access, and does this account own any integration, report, or shared item?" Include the evidence row so the answer is grounded in facts.
If the manager does not reply, do not treat silence as approval. Escalate once, then park the seat with a stated review date.
Suspend first and wait
Where the product supports it, suspend the account before deleting it. Suspension preserves the object, its history, and its ownership relationships while blocking sign-in. Wait through at least one full business cycle, including any month-end or payroll run.
During the wait, watch the support queue for reports of missing access, failed exports, or broken integrations. A clean week is evidence. A quiet week during a holiday is not.
Only after the wait, and only with the owner's confirmation, delete or unassign the seat. Record the date and the person who approved the final step.
Handle shared and service accounts separately
Shared mailboxes, generic admin accounts, and service accounts do not have a meaningful last sign-in pattern. They need an owner, a documented purpose, and a credential rotation schedule instead of a dormancy rule.
Exclude them from the human-seat cleanup and review them in a separate cycle. Mixing the two lists is how a cleanup removes the only account that can rotate an API key.
For service accounts, confirm the token or credential owner in the source system, not just in the SaaS admin panel. The two often disagree.
Communicate before and after
Send a short notice to affected users before suspension, naming the date and the way to appeal. Send a second notice after removal, with the export or handoff instructions if they need their data.
Keep the tone factual. The goal is to avoid surprising someone who is about to present a quarterly report, not to punish people for not logging in.
Publish the reclaimed seats and the estimated saving to finance in a simple table. That closes the loop and makes the next review easier to justify.
Operating brief
What this guide should help you decide
Routine intake, status updates, records, screenshots, and documentation upkeep.
Approvals, risky system changes, security decisions, and final technical judgment.
How to use this guide
Use this page to decide what an IT virtual assistant should handle first. If the task is recurring, documented, and easy to review, it is usually a better first delegation candidate than work that requires live technical judgment.
Treat the article as an operating brief, not just a topic overview. The goal is to turn loose IT work into a named workflow with inputs, outputs, permissions, review cadence, and a handoff rule that protects the business while reducing manager load.
Workflow
Recommended operating workflow
Define the request
Write what reclaim dormant saas seats without breaking access means in your company, where requests enter, and what finished work looks like.
Limit the access
Give the assistant only the tool permissions needed for intake, records, status updates, or documentation.
Run a pilot
Use a two-week sample period so the manager can review accuracy before expanding the workflow.
Review patterns
Summarize repeat issues, blocked requests, and escalation volume so the technical owner can improve the process.
Decision rules
| Question | VA fit signal | Escalate when |
|---|---|---|
| Is the work repeatable? | The same request appears weekly and can be described in steps. | The request changes business policy or system design. |
| Can quality be reviewed? | The manager can inspect the output without redoing the work. | Only a senior technical person can judge correctness. |
| Is access contained? | The assistant can work with read-only or role-limited access. | Admin rights, customer data, or security settings are involved. |
Delegation checklist
- Write the intake source, expected output, and manager review cadence.
- Confirm the assistant has only the permissions needed for the workflow.
- List the events that require escalation before work continues.
- Track examples for two weeks before changing the workflow.
- Save examples of good and bad outputs so the assistant has concrete references.
- Review the workflow monthly and remove permissions that are no longer needed.
Example first-week agenda
Day one should cover the workflow owner, tools, allowed actions, forbidden actions, and escalation language. By the end of week one, the assistant should have produced a small sample of completed work, a list of unclear requests, and a manager-reviewed improvement note.
What to review before delegating
Confirm the owner, access level, review cadence, and escalation path before assigning any recurring IT workflow to a remote assistant.
What should an IT virtual assistant handle first?
Start with repeatable, reviewable work such as ticket summaries, account records, documentation updates, and checklist follow up.
Get free IT support review