The SaaS Management Maturity Model: Where Does Your Organisation Sit?

SaaS management maturity doesn't happen overnight. Organisations move through recognisable stages, each building on the foundations of the last. Understanding which stage you're in is the prerequisite to knowing what to do next.

Executing on it depends on having the underlying data, which is where a platform like Liceo fits in.

Stage 1: Reactive

At Stage 1, SaaS is purchased ad hoc, often on personal cards or through informal approvals. There is no central inventory. Shadow IT is extensive and unknown. Renewal decisions are made when invoices arrive. Most organisations discover they're at Stage 1 during a finance audit or a security incident.

Stage 2: Aware

Stage 2 organisations have a partial inventory — they know about the big tools but have limited visibility into department-level purchasing. There's an informal approval process but it's inconsistently followed. Renewals are tracked in a spreadsheet. This is the most common stage for companies between 50 and 200 employees.

Stage 3: Managed

Stage 3 organisations have a complete inventory maintained in a dedicated system, a formal approval workflow with defined SLAs, a renewal calendar with 90-day lead times, and periodic access reviews. Cost per active user is tracked. This stage requires dedicated tooling and a named programme owner.

Stage 4: Optimised

Stage 4 organisations have automated provisioning and offboarding, real-time utilisation monitoring, chargeback to business units, and AI-assisted renewal optimisation. SaaS management is embedded in HR, Finance, and IT workflows rather than running as a separate programme.

The Value at Each Stage

Each maturity stage delivers distinct financial and operational value. Stage 1 to Stage 2 is primarily about visibility — the value is knowing what exists. Stage 2 to Stage 3 is about governance and optimisation — the value is controlling costs and reducing risk through active management. Stage 3 to Stage 4 is about automation and integration — the value is reducing the overhead of running the programme while increasing its effectiveness and coverage.

The financial return from moving between stages is compounding: a Stage 3 organisation typically achieves 15–25% of their SaaS spend in annual savings, while a Stage 4 organisation achieves that level of savings with 60–70% less IT and Finance overhead. The incremental investment in automation pays for itself within 12–18 months through reduced programme overhead alone, separate from any additional savings it surfaces.

Assessing Your Current Stage

To accurately assess your current maturity stage, evaluate four domains: inventory (how complete and current is your software inventory?), governance (how consistently is the approval process followed?), optimisation (are you actively managing utilisation and renewals with data?), and automation (how much of the lifecycle management is automated versus manual?). Score each domain on a 1–4 scale aligned to the stage definitions. Your lowest-scoring domain typically defines your overall maturity stage — you can only be as mature as your weakest area.

Share the maturity assessment with IT and Finance leadership as the basis for a programme roadmap conversation. A roadmap that identifies the specific gaps to close to move from Stage 2 to Stage 3 — and the expected financial impact of doing so — is more compelling than a general request to invest in SaaS governance. Concrete gaps, concrete investments, concrete returns is the language that moves budget decisions.

Avoiding Maturity Plateau

Many organisations get stuck between Stage 2 and Stage 3 — they have visibility into their SaaS estate but haven't built the governance processes that translate visibility into consistent action. The most common causes of plateau are: lack of a dedicated programme owner, insufficient IT-Finance collaboration, and approval processes that are still too slow to prevent shadow IT. Address these organisational factors before investing in more sophisticated tooling; the tooling amplifies what's already working, but it can't substitute for a well-designed operating model.