Software Asset Management for Sports Organisations

Sports organisations accumulate software quickly, and rarely through one door. Ticketing buys a platform, marketing buys another, performance staff add analysis tools, finance runs specialist systems and venue operations adopt maintenance software. Some of it is bought centrally, much of it on a department card, and ownership quietly lapses whenever someone leaves.

What follows is an inability to answer basic questions: what do we pay for, how many licences do we own, how many seats are actually assigned, which tools look underused, what renews next quarter, who owns each subscription and which department is paying.

This proposed software asset management platform puts licences, subscriptions, usage, spend, ownership and renewal decisions into one operational model.

The register

One record per product: vendor, product, business owner, technical owner, licence model, seats purchased, seats assigned, renewal date, notice period, auto-renewal status, cost, paying department and the procurement reference.

Ownership carries two names rather than one. The business owner decides whether the organisation still needs the tool; the technical owner knows what breaks if it goes. When either leaves, the record shows as orphaned rather than staying attached to a mailbox nobody reads.

Seats bought, seats assigned, seats used

These are three different numbers and the gap between them is where the money is.

Purchased seats come from the contract, assigned seats from the platform's own administration, and active usage from whatever activity data the vendor exposes. They are reported separately and never inferred from one another. Fifty purchased, forty-three assigned and eleven active in ninety days is a renewal conversation. Fifty, forty-three and unknown is a question for the vendor.

Renewals, before the notice window closes

A renewal date on its own is too late. Subtract the notice period and the renewal decision has to happen well before the date anyone has in their calendar.

Items approaching that point group on a dashboard by days remaining, escalate by email to the named owner and then to a fallback if nothing happens. Each carries the evidence the decision needs, the last invoice, current seat and usage figures, the notice terms, and closes with a stated outcome: renew, reduce seats, renegotiate, cancel or review again on a set date.

Spend, tickets and licences in one model

Software spend from finance, licence data from the register and ticket volume from the service desk share a dated model, which is what makes the monthly board paper a query instead of a day of pivot tables.

That model answers the ordinary questions, spend by vendor, department or category, annual software cost, what renews in the next ninety days, cost per assigned seat. It also answers the ones nobody currently attempts: which applications generated the most support tickets last quarter, which departments combine high spend with high support demand, which products have few active users and frequent tickets.

Those are operational signals rather than causal claims. A high ticket count can mean a poor product or a heavily used one, and the register's job is to put the question in front of a person with the rows behind it visible.

Domains and certificates

Certificates and domains for club sites, ticketing portals and fan apps get bought by whichever team stood up the service, often years apart through different suppliers, and the expiry date ends up in one engineer's calendar or nowhere at all.

They sit in an adjacent renewal register with issuer or registrar, owner, expiry date and uploaded evidence, and they escalate the same way. Marking one renewed requires the confirmation or invoice, so the register doubles as the record an auditor can be shown.

What it is not is certificate monitoring. A manual register tracks what somebody entered into it, and a certificate nobody recorded still expires on a matchday. Discovery and automated monitoring are a separate capability, worth being explicit about rather than implying.

Data freshness

Every source shows when it last refreshed, and manual imports are never presented as live. The distinction matters most in the renewal view, where a decision is being made from a seat count that could be a quarter old.

Where it sits next to the other two

Procurement handles the purchase request and the order. Identity governance handles who should have access and who does. Software asset management sits between them with the IT context: what is licensed, to whom, how much of it is used, what it costs and when the next decision is due.

Sharing application identifiers with identity governance is what turns a utilisation figure into an action, since the accounts to review are the ones the access model already lists.