Software asset management without a SAM team
Most writing about software asset management assumes a reader who has been given the job full time, a discovery agent on every laptop, and a licence position to reconcile. If you are a finance lead, an IT manager or an operations person who has been handed the software estate on top of everything else, almost none of that applies to you and the advice quietly stops being useful.
The underlying discipline still does apply. It just reduces to four jobs, and the order you do them in decides whether the whole thing takes an afternoon a month or defeats you. Here is the short version of the practice for an organisation that will never have a SAM team.
What a SAM programme has to do
Strip out the tooling and the vocabulary and every software asset management framework is trying to answer four questions. They are worth writing down plainly, because each one has a cheap answer and an expensive answer, and the enterprise literature tends to describe only the expensive one.
- What do we have? A single list of every tool the organisation pays for, with an owner against each one.
- What does it cost? The annual cost of each tool, on the same basis, so the numbers can be added up and compared.
- When does it commit us again? The renewal date and the notice period, which together decide the last day a decision can still be made.
- Are we still entitled to use it the way we are using it? Seats bought against seats in use, and any term that limits how the software may be deployed.
Everything else in the discipline is machinery for answering those four at a scale where you cannot simply look. Below a few hundred tools you can simply look, which is the whole opportunity: you get most of the value of a SAM programme from a maintained list and a calendar, and none of the cost.
Start from the bank statement, not the network
The instinct is to start by discovering what is installed. For a small organisation that is the wrong end. Installed software is a long tail of free tools, browser extensions and things one person tried once, and the list it produces is large, mostly irrelevant, and says nothing about what anything costs.
Money is the better index. Every tool that matters is being paid for, so it appears in the card statements, the purchase ledger and the supplier list. Pull twelve months of those, filter to anything that looks like software, and you have a candidate list that is already sorted by how much it matters. It will also surface the subscriptions bought on a personal card and reclaimed on expenses, which no discovery agent will ever find.
Twelve months is the right window because it catches the annual payments. A quarter of statements shows you the monthly tools and hides every contract that bills once a year, which is where the larger commitments tend to sit. Our guide on finding software nobody owns covers the reconciliation in more detail, including the payment lines that look like software and are not.
One named owner per tool, no exceptions
An owner is the single person who decides whether the organisation keeps paying for a tool. Not the person who administers it, not the team that uses it, and not a department name. A department cannot answer an email in November about whether to renew in January.
This is the field that fails first and matters most. If nobody owns a tool, nobody cancels it, and it renews on its own for years. It is also the field that makes the other three cheap: once a tool has an owner, you stop being the person who has to work out what it costs and whether it is still needed, and become the person who asks the owner in time for the answer to be useful.
Where a tool genuinely has no obvious owner, the honest entry is the budget holder who pays for it. That is an uncomfortable assignment, which is rather the point: it gets resolved properly within one renewal cycle.
Put every cost on one basis
A list where one tool reads 45 pounds, another 540 pounds and a third 1,350 dollars cannot be added up or sorted, so nobody uses it for a decision. Convert everything to an annualised cost in one currency and keep the billing cycle in its own field. Then the largest line is genuinely the largest line, and the top ten rows are where a review is worth doing.
Two things belong in the cost that are usually left out. Per-seat tools cost the number of seats you are billed for, not the number in use, and the gap between those two is the most common form of shelfware in a growing organisation. And a perpetual licence costs its annual maintenance rather than nothing, which the perpetual licence and subscription comparison works through.
Record the date a decision is still possible
The renewal date is not the deadline. The deadline is the renewal date minus the notice period, and it is the only date in the record that a diary can act on. A 30 day notice period on a renewal three weeks away means the decision has already been made for you, whatever the register says.
So record both, keep the notice period in its own field, and drive every reminder off the difference. Notice periods explained sets out where to find the term in an agreement and the wording that changes what it means, and the renewal countdown covers what a review at 90, 60, 30 and 7 days out should actually do.
For contracts with no end date, an evergreen or rolling agreement has a notice window rather than a deadline, and the record needs to say which kind it is. A rolling monthly contract with 90 days notice is a three-month commitment at any moment, and it looks like one of the cheapest lines on the list.
Entitlement, without building a licence model
The fourth question is the one enterprise SAM spends most of its effort on: whether your deployment is within what you bought. Full entitlement modelling is out of reach without a dedicated function, and for most small organisations it is also unnecessary, because the risk is concentrated in a handful of tools.
The proportionate version is to record seats purchased against seats in use for every per-seat tool, and to read the terms properly for the three or four tools where the vendor audits: the database, the design suite, the finance or ERP platform, anything sold per processor or per device. Those are where a true-up arrives with a number attached. A ten-seat project tool over by two seats is a billing conversation, not a compliance one.
Where a security framework is in play the requirement is narrower and better defined than general SAM, and it is worth reading directly rather than inferring: see the software asset register auditors ask for for what ISO 27001 and Cyber Essentials require of the list itself.
The loop that keeps it true
A register decays from the day it is built, and a stale register is worse than none, because people act on it. Three habits keep it honest without a monthly project.
- Add on purchase. Anything new gets a row when it is bought, not at the next review. This is the only habit that has to hold, and it belongs to whoever approves the spend.
- Remove on exit. When a tool is cancelled, close the row rather than deleting it, so next year's review can see what was dropped and why. The offboarding checklist covers the data and access steps that go with it.
- Confirm at renewal. The reminder that asks the owner whether to renew is the natural moment to confirm the cost, the seat count and the notice period are still right, because all three are in front of them anyway.
That third habit is what makes the whole thing self-maintaining. You are not scheduling an audit; every record gets reviewed once a year on a date the contract itself chose, spread across the calendar. An annual sweep is still worth doing once, to establish the baseline, and how to run a software audit is the version of that written for a team of one.
What to skip, deliberately
Being clear about what you are not doing is what keeps a small programme alive. Four things are commonly presented as essential and are not, below a few hundred tools.
- Automated discovery agents. They answer a question you can answer from the ledger, and they add an estate of their own to manage.
- Usage telemetry on everything. Worth having on the two or three largest per-seat tools, where a seat reduction pays for the effort. Not worth wiring up across the estate.
- A formal licence-position model. Do the reading on the few tools that are genuinely audited and leave the rest at seats bought against seats used.
- A category taxonomy designed up front. Group tools when you have a reason to group them. A classification scheme invented before the list exists is work that produces nothing.
What is left is a list, an owner per row, one cost basis, two dates and a seat count. That is a real software asset management programme, and it is roughly a dozen fields. The fields that matter in a software register goes through them one at a time, including which ones can be left empty.
Where to keep it
A spreadsheet does all of this and is a reasonable place to start, because it costs nothing and proves whether the habit holds. It has one structural weakness: it cannot tell you that a deadline is approaching. Somebody has to open it and look, and the whole point of recording the notice period is that the reminder arrives without anyone remembering to check.
If the spreadsheet version is working and the missed dates are the part that is not, that is the specific thing StackTrackr replaces: the same fields, with the deadline arithmetic and the reminders done for you. See what it tracks, compare the plans or start free. If the habit is not holding yet, fix the list first. The tool is not the part that was missing.