Augmented application maintenance: from tickets closed to application health

An application-maintenance contract can become far more productive thanks to AI while staying trapped in a model that rewards ticket volume, days consumed, or FTEs deployed. That's where the real issue lies.

The thesis argued here is this: an AI-augmented maintenance contract shouldn't be judged first on its ability to handle more tickets with fewer people, but on its ability to keep the application in a better state — more available, restored faster, less prone to repeat incidents, and gradually rid of what makes it fragile.

That doesn't mean the ticket disappears, or the SLA, or the arrival of self-running maintenance. The available data doesn't support that claim. It does show, though, that AI is starting to shift maintenance's centre of gravity: from processing requests toward observation, diagnosis, prevention, oversight, and continuous improvement.

In brief

• •The ticket stays useful for tracing work, but becomes insufficient as the main unit of value.
• •AI makes a more proactive maintenance contract possible: assisted diagnosis, correlating incidents, generating fixes and tests, log analysis, documentation, observability, and handling certain repetitive cases.
• •Performance then needs to be measured by a coherent set: availability, MTTR, repeat incidents, change quality, reduced debt, total cost, and the exception rate.
• •Shifting toward outcomes still doesn't justify a 100% outcome-based contract: availability and incidents also depend on the architecture, the business, vendors, and other providers.
• •The genuine organisational change is building an observe → diagnose → fix → verify → learn → prevent loop, with explicit action rights for both agents and humans.

The paradox: a high-performing maintenance contract should end up with fewer tickets

The traditional model for many maintenance engagements is built around easy-to-count units: tickets opened and closed, days consumed, FTE headcount, response times, backlog compliance.

These metrics aren't absurd. They give visibility into load, capacity, and whether commitments are met.

The problem shows up when they become the very definition of value.

Imagine a provider identifies a recurring incident that accounts for 15% of its tickets. It fixes the root cause, improves observability, and automates a check that stops it from recurring.

From the client's point of view, that's an excellent result.

In an engagement billed by the ticket or largely indexed on human volumes, though, the provider has just erased part of its own revenue.

The more a maintenance contract becomes able to prevent incidents, the more billing based solely on work consumed risks creating a conflict between operational performance and the provider's economic performance.

This tension goes beyond application maintenance. In France, 49% of the IT services firms surveyed in the first half of 2026 by Numeum-Xerfi cited pricing pressure among their top headwinds, while 58% said they're repositioning, notably through automation and AI. Numeum also estimates AI-linked productivity gains at IT services firms could rise from 15% in 2025 to 22.3% in 2027, while stressing they remain hard to convert into margin. This is self-reported or forward-looking sector data, not a causal measure of any specific maintenance contract's productivity.

The question, then, becomes: what do you sell when the right outcome is precisely reducing the work needed?

What the data actually shows about AI-augmented maintenance

The most directly relevant signal comes from the ADM market — Application Development and Maintenance services.

In 2025, ISG observed, across Europe, the gradual integration of GenAI agents into the application development and management cycle, beyond mere code-generation pilots. Its Application Managed Services evaluation framework includes automation tools covering the application landscape beyond just alert and incident management, along with AI use for maintenance, bug fixing, and troubleshooting. It also treats fixed-fee or outcome-based contracts as maturity options, while keeping staff augmentation among the possible models.

What this proves: AI-augmented application maintenance is no longer just a theoretical extrapolation. Market offerings now build AI into support, quality, defect analysis, and operations.

What this doesn't prove: that applications maintain themselves, that tickets are disappearing, or that outcome-based pay has become the dominant model.

The same caution applies to productivity. DORA concludes, in 2025, that AI acts above all as an amplifier: it amplifies a high-performing delivery system's strengths, but also its weaknesses. The gains, then, come less from the isolated tool than from the organisational system it's embedded in.

This matters especially for application maintenance. Generating a fix faster is useless if the team lacks tests, the documentation is out of date, the dependencies are poorly understood, or the deployment creates more regressions.

The ticket isn't the application's health

A ticket is a work event. Application health is the system's state over time.

Confusing the two produces several misleading effects. An application can generate few tickets because it works well, or because its users have given up reporting them. A team can post an excellent closure time while applying temporary fixes that cause repeat incidents. Conversely, a temporary rise in ticket count can be healthy if a reliability push finally surfaces latent problems.

The SRE (Site Reliability Engineering) movement has already shifted part of the management focus toward availability, service-level objectives, and health indicators. Google Cloud, in particular, presents SLOs as mechanisms for tracking service availability and health, and MTTR as an indicator of service restoration.

AI-augmented maintenance can extend this logic.

The right evolution, then, isn't replacing one single indicator, the ticket, with another single indicator, say MTTR. It's moving from a volume logic to a portfolio of health metrics.

What AI lets you shift in the maintenance chain

An AI-augmented maintenance architecture can be thought of as a loop rather than a queue of tickets:

operational signals → diagnosis → decision → action → verification → learning → prevention

Observe before waiting for the ticket

Classic maintenance often starts when someone reports a problem.

AI-augmented maintenance can start earlier: logs, traces, metrics, recent changes, similar incidents, resource consumption, and dependency behaviour supply the context needed to detect degradation before it becomes a user-facing incident.

Recent observability platforms already let agents use metrics, logs and traces for troubleshooting and root-cause analysis. AWS, for instance, documents tools linking observability, code repositories, runbooks and deployment pipelines to speed up investigation. These are vendor features, though, sometimes still in preview: they show a technological direction, not universal production performance.

Diagnose instead of merely routing

An agent's first useful job isn't necessarily fixing things.

It can first enrich: matching the incident against comparable events, checking recent changes, suggesting a likely cause, looking up an existing runbook, and preparing what's needed for the human decision.

This step carries significant organisational value: it cuts the amount of work spent hunting for context.

Automate the known and the reversible

Repetitive, well-documented incidents offer the most natural ground for automation: deterministic operations, known tests, a possible rollback, a limited scope of rights.

But the level of autonomy needs to depend on the risk.

ANSSI, France's cybersecurity agency, reiterated in 2026 that agents able to execute commands or actions with side effects significantly widen the risk surface; it recommends limiting their rights to the strict minimum, working in isolated environments, and requiring human validation whenever a system command or an action with side effects is contemplated.

AI-augmented maintenance, then, isn't maintenance where "AI fixes everything on its own". It's maintenance where the right to act is designed around reversibility and impact.

Make verification a front-rank discipline

The more automatic output rises, the more control quality matters: functional tests, regression tests, security, performance, checking the business context.

Cigref specifically recommends, for AI systems, defining test protocols, documenting their results, setting tolerance thresholds, and contractually clarifying the provider's and the client's respective accountability.

The principle holds beyond the models themselves: a change produced by an agent isn't worth more than a human one if nobody can show it matches the expected behaviour.

The real break: moving from "resolving" to "learning"

This is probably where maintenance changes most profoundly.

In a ticket-centred logic, the cycle can end when the incident is closed.

In an application-health logic, closing it opens a second question:

Why did this ticket exist, and what do we need to change so it's less likely to come back?

This changes the work. The fix becomes a source of learning to:

• •enrich a runbook;
• •add a test;
• •improve an alert;
• •fill out the documentation;
• •fix an agent rule;
• •remove a fragile dependency;
• •address a source of debt;
• •change an escalation threshold.

This loop echoes one of the most solid lessons from field observation: at several organisations studied, human work shifts from mass processing toward review, supervision and exceptions — a "human on exceptions" model tied to nine cases from a panel of thirty companies selected for their organisational signals, not representative of the market.

Applied to maintenance, this shift means the human organisation should gradually devote less capacity to repetitive processing and more to four activities: diagnosing atypical cases, authorising risky actions, removing recurring causes, and improving the automation system itself.

Three useful cases, provided they aren't made to say what they don't

The body of cases observed doesn't offer a directly comparable benchmark across several maintenance contracts. It does offer three organisational mechanisms that can be transposed with care.

Qonto: evaluating before the defect arrives

The Qonto case documents integrating evals tied to AI products into CI, and a doctrine that distinguishes a product that "works" from one that's genuinely reliable.

What this brings to maintenance: quality shouldn't be evaluated only after the incident. Tests and evals need to become a barrier before deployment.

What this doesn't prove: that the same architecture works across every legacy estate.

Doctolib: distinguishing the reversible from the irreversible

Doctolib documents a framework where certain reversible decisions can be made closer to execution, while irreversible decisions stay explicitly arbitrated.

Reading for operations: a controlled restart, a retry, or a known rollback shouldn't get the same level of authority as a data migration or an irreversible change to a critical system.

This is an organisational transposition, not a description of Doctolib's own maintenance setup.

Roundtable: surfacing the exception rather than the whole volume

Roundtable reports that, on a flow of 1,000 SPVs, automation surfaces only fifteen to twenty problem cases to a human. This is an account from a regulated operational domain, not application maintenance.

The case's interest, then, lies elsewhere: it shows what it means to design work around the exception.

The question to ask a maintenance provider is no longer just "how much can we automate?", but: "what exception rate are we creating, how hard are those exceptions, and do we still have the humans able to resolve them?"

The exception rate matters as much as the automation rate

A team announces 80% automation. Is that necessarily good news?

Not necessarily.

If the remaining 20% accounts for 80% of the difficulty, the human workload doesn't shrink proportionally. It can even become more intense, because employees now only inherit the rare, ambiguous and critical incidents.

This is exactly why the "human on exceptions" model requires looking at volume, the exception rate, the error rate, rework, lead time, quality and cost all together.

Another trap would be trying to artificially cut the exception rate. An agent that rarely escalates can be excellent, or overconfident.

The right goal, then, isn't "as little human as possible". It's getting the right level of autonomy for each risk class.

An organisational architecture for AI-augmented maintenance

Technology alone isn't enough. DORA shows precisely that AI amplifies the system it's embedded in.

A target organisation can be built around six functions. These aren't six mandatory positions: in a small team, one person can hold several of them.

The service owner

They own the expected availability, the SLOs, the improvement priorities, and the trade-off between speed, risk and debt.

The augmented run team

It uses agents and automations for triage, diagnosis, standard fixes, tests, documentation, and preparing changes. Its work gradually shifts toward review and non-standard incidents.

Application and business experts

They hold the context telemetry alone can't reveal: expected behaviours, seasonality, historical exceptions, organisational dependencies, and business impact. They become essential precisely because AI can very quickly produce an answer that's technically plausible but contextually wrong.

The quality / evals function

It maintains the test sets, the acceptance criteria, the incident scenarios, and the regression checks. It also measures the quality of the agentic system itself.

The human escalation authority

It needs real rights: stopping an automation, blocking a deployment, reverting to a manual procedure, or requiring an in-depth analysis. A human present only to rubber-stamp what the machine has already decided isn't a genuine human-in-the-loop.

The continuous-improvement owner

Their job is to look beyond the current ticket: which causes keep recurring? which tasks can be removed? which debt is growing? which runbook should become an automation? which automation, conversely, should be pulled?

The difference between an automated maintenance contract and a transformed one largely lies in this sixth function.

Metrics: don't replace the "ticket factory" with a "KPI factory"

Shifting to application health doesn't mean stacking up twenty indicators. An effective framework can be structured around six dimensions.

The term MTTR itself needs defining in the contract: depending on the organisation, the "R" stands for repair, recovery, or resolution. This isn't a lexical issue: starting and stopping the clock at different moments is enough to make two performances incomparable.

As for prevention, one methodological limit needs accepting: an incident that never happened is hard to measure.

It's better, then, to use more robust proxies: a drop in repeat incidents, known root causes disappearing, detection before user impact, better test coverage, or lower error-budget consumption.

Technical debt needs to become a run metric, without pretending it boils down to one number

A maintenance contract can meet every one of its SLAs while gradually degrading the estate.

That's the problem with quick fixes, dependencies that never get updated, missing tests, and components nobody dares touch the architecture of anymore.

AI can speed up resolving certain maintenance tasks, but it can just as well speed up the production of changes and so amplify the flaws of a poorly governed system. This is exactly the kind of amplification effect DORA highlights.

Debt, then, needs to enter the application-health contract. Not as some mysterious universal "debt score", but as a portfolio agreed between the parties:

• •obsolete components carrying an identified risk;
• •recurring incidents with no root cause addressed;
• •missing tests on critical areas;
• •vulnerabilities or dependencies needing an update;
• •observability problems;
• •repetitive manual procedures;
• •missing critical documentation.

Part of the maintenance capacity should be explicitly ring-fenced to remove these causes — otherwise AI's efficiency risks simply helping the team run faster behind an application that's degrading.

Should maintenance, then, be billed by outcome?

Not entirely. This is one of the most important limits of the thesis.

An application's availability can depend on the maintenance provider, but also on the infrastructure, a SaaS vendor, the client's own development teams, interfaces with other applications, the data, changes made outside the scope, business decisions, or cybersecurity events.

Putting 100% of the outcome on the provider would sometimes mean transferring it a risk it doesn't control.

Knowledge services are seeing a broader shift from time consumed toward proof, assets, recurring services, and impact. For an IT services firm, though, this logic needs a specific transposition: a running system carries more dependencies, operational accountability, and risk than a consulting deliverable.

Application maintenance is one of the models where the ticket or FTE unit becomes insufficient, but that doesn't mean fully outcome-based pricing is the universal target.

A hybrid contract model looks more robust

Four blocks can be distinguished.

A fixed service base, which pays for coverage, expertise, the team's availability, and keeping the system running.

SLOs and quality levels, which make the genuinely expected service explicit.

An improvement capacity, dedicated to prevention, reliability work, and paying down debt.

A limited variable component, covering only a few outcomes the provider can genuinely influence: repeat incidents, restoration time, change quality, or hitting a reliability trajectory.

This model remains a proposed way of reading things, not a practice proven as a market standard. It does have one advantage, though: it avoids both paying the provider for accumulating tickets and making it carry all of the client's operational risk.

The account manager's job changes too

When the engagement is sold by FTE or by the day, commercial management largely rests on staffing: how many people, at what rate, what usage, what renewal?

A health-oriented maintenance contract forces the account manager to master a different language. They need to be able to explain the application's state, the reliability trajectory, the dominant incident causes, the total cost of running it, the share of automated work, the exceptions needing human expertise, the debt genuinely removed, the accepted risk level, and their team's limits of accountability.

The account manager no longer just sells processing capacity. They become partly responsible for the service's economic architecture: where is value created, how is it proven, and how are the gains shared without creating bad incentives?

The main counter-example to the thesis: some maintenance contracts still need the ticket, the day, and the FTE

It would be too simple to conclude every maintenance contract should abandon the traditional metrics. They remain rational in several situations.

A very unstable application, or one in constant flux, can make setting a reliable baseline hard. Rare expertise deployed occasionally can stay perfectly suited to the day rate. A scope heavily dependent on third-party teams makes attributing outcomes fragile. A small maintenance contract with insufficient instrumentation can't reasonably promise a sophisticated application-health trajectory.

And the ticket remains irreplaceable as a traceability object: it documents a need, an incident, an action, an accountability.

The transformation proposed here, then, is downgrading the ticket from a unit of value to an operational signal.

How to test AI-augmented maintenance without rewriting the whole contract

The best starting point is probably neither the most critical scope, nor the entire service centre.

Choose an application that's properly instrumented, with a usable ticket history and enough repetitive problems to observe a difference.

First establish the baseline: availability, MTTR, repeat incidents, volume, rework, human time, failed changes, and cost.

Then pick a few incident families. For each one, determine what the agent can observe, what it can diagnose, what it can propose, what it can execute alone because the action is reversible and low-risk, and what absolutely needs human approval.

Start in shadow mode if needed: the agent works, but the human team keeps executing. Compare the diagnoses, errors and decisions before extending its autonomy.

Finally, don't measure only productivity. Measure what happens after the ticket closes: repeat incidents, defects, rework, and incidents caused by the fixes themselves.

Self-diagnostic: is your maintenance contract steering tickets, or application health?

• •Can you describe the scope's health without citing the number of tickets closed?
• •Do you have a shared baseline on availability, MTTR, repeat incidents, rework, and change quality?
• •Do you know which ticket families should disappear rather than just be processed faster?
• •Is an explicit share of capacity devoted to removing root causes and debt?
• •Do the agents or automations have different autonomy levels based on reversibility and risk?
• •Does every significant automatic action have an approval mechanism, logging, and a rollback?
• •Do you measure the exception rate, but also their severity and the human time genuinely needed to handle them?
• •Are automated fixes held to the same test and regression requirements as human ones?
• •Do closed incidents automatically feed into runbooks, tests, monitoring rules, or platform improvements?
• •Does your contract genuinely reward prevention, or only work consumed?
• •Does the provider carry only the outcomes whose drivers it sufficiently controls?
• •Can your account manager explain the application's reliability trajectory as well as its staffing?

The more the "no" answers cluster in the second half of this grid, the more the problem is probably less technological than contractual and organisational.

The conviction

AI-augmented maintenance isn't about replacing technicians with agents to close the same tickets faster.

That would keep the same economic and organisational system while simply squeezing its production cost.

The deeper change is redefining the engagement's very object.

The client no longer just buys the capacity to absorb the consequences of an imperfect application. It increasingly buys the capacity to keep that application in a known, observable, improvable working state.

This shifts, all at once, the metrics, from volume toward reliability; human work, from processing toward exceptions and improvement; the manager's role, from distributing tickets toward managing autonomy and risk; the contract, from pure effort toward a combination of capacity, service and outcome; and the provider's margin, from work volume toward the ability to durably remove unnecessary work.

But this conviction has one condition. Maintenance doesn't get better because it automates more. It gets better when automation genuinely improves the application's state, without hiding errors, shifting risk onto the client, or burning out the humans who inherit the exceptions.