Software & SaaS · AI-driven maintenance management

Spotting maintenance risks in SaaS platforms early

A software company with 2,400 employees runs more than 190 SaaS platforms; 260 maintenance tasks arise every day and risks remain hidden.

  • Technology
  • IT-Service-Management

Key metric

Time per maintenance case

2011min

Average assessment effort per maintenance case

At a glance

Initial problem

Maintenance risks in SaaS platforms remain hidden

Solution type

Agentic workflow in IT operations

Complexity

Transformation

Key metric

Time saved on maintenance assessment

User group

IT operations and platform teams

Implementation time

3-6 months

Operating model

Integrated into existing IT systems

Starting point

The company develops and operates its own SaaS products as well as customer-specific platforms. In total, more than 190 platforms are running with different technology stacks, tenants and service levels. In IT operations, 28 employees are responsible for maintenance and stability. On average, 260 maintenance tasks arise every day, spread across the ticketing system, monitoring alerts and change requests. For each maintenance case, the teams spend an average of 20 minutes clarifying dependencies, risks and time windows. That adds up to around 85 hours a day, mostly tying up senior specialists. Information on tenants, contractual obligations and technical dependencies is scattered across several systems and documents.

190
SaaS platforms
260
maintenance cases per day

The challenge

Maintenance tasks range from security updates and configuration changes to infrastructure migrations. Each platform has its own tenants, SLAs and integrations with third-party systems. Whether maintenance can take place during the day, which tenants are affected and whether regulatory obligations are involved currently has to be checked manually. The IT teams jump between the ticketing system, monitoring, the contract repository and configuration documents. As a result, decisions are delayed, critical risks are recognized too late and maintenance is moved to night windows as a precaution. This increases costs and puts a strain on on-call duty. At the same time, the number of platforms keeps growing without additional senior capacity becoming available.

Typical symptoms in the organization

“We spend more time searching than on the actual maintenance.”

“I often only find out shortly before the change which tenants are really affected.”

“Every platform has different rules – nobody can keep track anymore.”

“We push maintenance into the night because risks are hard to assess during the day.”

Why this remained unsolved

The problem had long been known but was accepted as an unavoidable complexity of running platforms. A classic rule set would have had to cover thousands of combinations of tenants, SLAs and integrations and would quickly have become outdated. Monitoring and the ticketing system had already been expanded but remained separate silos. A central tool for automatically assessing maintenance risks seemed too big an intervention in ongoing operations and was therefore postponed again and again, even though the effort for manual checks kept rising.

SLA Excel overview

A manually maintained Excel list was meant to bring together tenants and SLAs per platform, but it quickly became outdated and was hardly used day to day.

Ticket templates

Standardized ticket templates were meant to structure risks but only led to more mandatory fields without real automation.

Our solution

An agentic workflow was introduced that bundles maintenance tasks from the ticketing system and monitoring, enriches them with platform data and contract information, and creates a structured risk assessment for each task. The workflow identifies affected tenants, relevant SLAs, technical dependencies and possible conflicts with other changes. The IT teams receive prioritized maintenance cases with suggestions for time windows, communication needs and escalation paths. Generative components condense scattered free text from tickets, runbooks and contract documents into clear assessments that can be reused in the change process. This turns many individual signals into a consistent decision framework for maintenance.

Where generative AI comes in

Generative AI analyzes free text in tickets, runbooks and contracts, recognizes patterns relating to risks, tenants and SLAs, and writes structured assessments for each maintenance task. It suggests time windows, communication templates and escalation paths and makes complex context usable faster, which reduces queries in the change process.

Building blocks
  • Integration of the ticketing system, monitoring and platform inventory with consistent identification of the affected SaaS platforms and tenants.
  • Automatic enrichment of maintenance cases with SLAs, contract information and known technical dependencies from configuration documents.
  • Generative analysis of free-text descriptions in tickets and runbooks to produce structured risk assessments and recommendations.
  • Prioritization and bundling of maintenance tasks by urgency, affected tenants and possible conflicts with other changes.
  • Assessments delivered directly in the ticketing system, including suggested communication templates for customers and internal approvals.
How it works

How the maintenance workflow runs today

  1. Collect signals

    Tickets, monitoring alerts and planned changes are collected continuously, and platforms and tenants are assigned automatically.

  2. Enrich context

    The workflow adds SLAs, contract data, known dependencies and past incidents from the connected systems to each maintenance case.

  3. Assess risks

    Generative analysis summarizes free text, assesses risks and suggests suitable time windows and communication needs.

  4. Prioritize cases

    Maintenance tasks are prioritized and bundled by urgency, affected tenants and conflicts with other changes.

  5. Document the decision

    The chosen approach is documented traceably in the ticketing system, including the rationale and escalation path.

Impact

Measured: after six months in operation

Period: after six months in operation.

MetricValueBasis
Time per maintenance caseKey metricfrom 20 to 11 minutes per caseTime tracking before/aftermeasured
Senior time in the maintenance processReduced by around 70 hours per weekTime tracking before/afterestimated
Corrections needed to assessmentsQuality metricManual corrections needed in around 15 percent of casesSampleestimated

Cost-effectiveness

Effort class

Standard (60-150 person-days)

Payback period

6-12 months

Main lever

Time savings

Ongoing costs

Running the workflow, model usage and maintaining the interfaces in IT operations.

Limitation

The solution assesses risks and suggests time windows, but it does not replace technical approval by the people responsible. For new platform types, the workflow has to learn first, and the quality of results depends on well-maintained platform inventories and SLAs.

Integration and operation

Connected systems

Integration with the central ticketing system, the monitoring platform, the CMDB or platform inventory, and the repository for contracts and SLAs.

Operation

Operated in an isolated company environment, with access to internal systems via defined interfaces and strict separation of customer data.

Compliance

Access to contract and tenant data is role-based, and logs of assessments and decisions are stored in an audit-proof way and remain traceable for audits.

Labeling

The ticketing system clearly shows which assessments were generated automatically and which parts were added or overridden by people.

Accountability

Automatic assessments count as recommendations; binding approvals for maintenance and time windows remain with the responsible roles in the change process.

Escalation path

In case of conflicting signals or high uncertainty, the workflow flags cases for escalation to designated senior roles in IT operations.

Traceability

For every assessment, the data sources used, the risks identified and the recommended actions are logged so that decisions can be reviewed later.

Operational roles

IT operations, platform owners and change managers use the workflow, while a small central team is responsible for configuration, training and ongoing maintenance.

Transferability

The pattern suits any situation where many maintenance or change tasks have to be coordinated across different tenants, SLAs and technical dependencies. Today, relevant information is often scattered across several systems and documents, and experienced specialists spend a lot of time on assessment. An agentic workflow bundles these signals, analyzes them generatively and delivers structured recommendations without replacing existing approval processes.

Maintenance planning in production plants with many lines, tenants and service levels.

Change coordination in core banking systems with differing regulatory obligations.

Maintenance planning in energy grids with distributed assets and complex dependencies.

A similar case in your organization? Let's talk.

Briefly describe your process. We'll get back to you with an initial assessment of whether the pattern can be transferred and what it would realistically take.

Apply to izz.ai

PDF, DOC or DOCX · up to 3 files, max. 10 MB each

I accept the privacy policy

Get in touch

A friendly pink robot opens a door behind which lies a futuristic world