EXAMPLES

How this works in practice — twelve examples.

Consulting descriptions tend to stay abstract. These examples are specific: the situation work starts from, what is actually done, and what it is judged by.

Discuss your case

AI & AUTOMATION

AI agents in real processes

The examples below illustrate what typical work looks like in each area: the situation, how it is approached, and what actually gets measured. They are generalised scenarios based on commonly occurring cases rather than descriptions of specific clients — client names, data and figures are not published. The numbers in your situation will depend on scope, systems and team maturity.

01 · IT SERVICES

Incident triage by an AI agent

Situation

The service desk receives several hundred requests a week. Each one costs a few minutes of triage first: who owns it, what priority, is it already known.

What is done

The agent reads the request, gathers context from monitoring and similar past incidents, and proposes a category, priority and first resolution steps. A human confirms the assignment — the agent sends nothing to the customer on its own.

What is measured

First response time, share of correctly assigned requests, time to resolution, and how many are resolved at first line.

02 · MANUFACTURING

Extracting data from supplier documents

Situation

Invoices and contracts from dozens of suppliers are handled by hand: figures are retyped into accounting, and mismatches surface only at month end.

What is done

The agent extracts the fields, compares them against the order and the contract, and flags mismatches. Below an agreed threshold the record proceeds automatically; above it, human approval is required.

What is measured

Processing time per document, how often manual correction is needed, and how many mismatches are caught before payment rather than after.

03 · ENTERPRISE IT

A knowledge assistant over internal documentation

Situation

Runbooks, configurations and decision history are spread across several systems. A new engineer spends their first months asking colleagues, which costs both of them time.

What is done

The agent answers only from internal documentation and cites its source every time. Where the documentation has no answer it says so rather than guessing — a wrong answer about a production system costs more than no answer.

What is measured

Repeat questions to the team, time for a new joiner to become productive, and how many cases are resolved without escalation.

04 · IT SERVICES

Correlating monitoring signals

Situation

Monitoring sends hundreds of alerts a day. Most are echoes of the same failure, so the team learns to ignore them.

What is done

The agent groups related signals by timing and dependency, proposes a likely root cause, and raises one incident instead of twenty separate ones.

What is measured

Alert volume reaching the on-call engineer, false positive rate, and time from first signal to identified cause.

SERVICE MANAGEMENT

When daily service becomes predictable

05 · RETAIL

Repeat incidents with a vague cause

Situation

The same failure returns every few weeks. Each time it is cleared quickly, so it looks under control — but nobody investigates why it comes back.

What is done

We separate incident management from problem management: the incident restores service, the problem finds the cause. Root cause analysis is introduced for recurring cases, each with a named owner and a deadline.

What is measured

Share of incidents that are repeats, time to identify a cause, and how many problems close with the cause actually removed.

06 · PUBLIC SECTOR

SLAs disconnected from business consequence

Situation

The contract contains a set of SLAs, metrics are calculated and reports are sent. But when a threshold is breached nothing changes, because it is unclear who does what.

What is done

We tie each metric to how critical the service is to the business, document the escalation procedure and assign owners. Metrics nobody uses for decisions are removed — they are noise in a report.

What is measured

SLA attainment weighted by service criticality, how quickly escalation triggers, and how many decisions were genuinely made on the metrics.

07 · TELECOMMUNICATIONS

Escalation that depends on specific people

Situation

Critical incidents are in practice handled by two engineers. When they are away, out-of-hours response becomes a matter of luck.

What is done

We document escalation paths by incident class, build an on-call rota with explicit responsibilities, and write runbooks for the most common scenarios so someone other than the author can follow them.

What is measured

Out-of-hours response time, share of incidents resolved without third-line escalation, and dependency on any single person.

INFRASTRUCTURE

Decisions you can defend

08 · BANKING

Migrating critical infrastructure to a new data centre

Situation

Critical systems run in an ageing data centre. The migration keeps being postponed because nobody will take on the downtime risk.

What is done

We build an inventory and dependency map, split the migration into stages by criticality, prepare a rollback path for each stage, and verify recovery in a test environment beforehand.

What is measured

Actual downtime per stage, incidents in the first weeks after migration, and whether the rollback path was ever needed.

09 · IT SERVICES

Cloud costs above plan

Situation

After migration the monthly bill is noticeably higher than forecast. The systems work, but costs are unpredictable.

What is done

We review what genuinely runs around the clock, which storage tiers are in use, where data crosses zone boundaries, and which resources were left behind after testing. The architecture is adapted to the cloud model rather than moved across unchanged.

What is measured

Monthly cost per service, cost per user or transaction, and how much is saved without affecting performance.

10 · REGULATED ENVIRONMENT

Backups with untested recovery

Situation

Backup reports show success every night. But nobody has attempted a real restore, so recovery time is an assumption rather than a number.

What is done

We run restore tests for critical systems, measure real recovery time and data loss boundary, and check dependencies on other systems — because a system rarely comes back alone.

What is measured

Real RTO and RPO figures instead of assumptions, the gap against business expectation, and how many systems failed to restore first time.

IT MANAGEMENT & BUSINESS

When IT grows with the company

11 · MANUFACTURING

Suppliers nobody manages

Situation

The company works with several IT suppliers. Contracts renew automatically, some services overlap, and total IT spend is not consolidated anywhere.

What is done

We build an inventory of contracts and services, find duplication and unused licences, review where responsibility ends between suppliers, and prepare for negotiation with specific arguments.

What is measured

Annual IT spend, number of suppliers and contracts, and how many services have a clear internal owner.

12 · GROWING COMPANY

IT maturity lagging behind growth

Situation

What worked at twenty people creaks at a hundred: access is granted by email, devices are uncounted, and leavers keep active accounts.

What is done

We fix the joiner and leaver process, document a device policy, audit licences, and automate the onboarding and offboarding flow.

What is measured

Time to prepare a new joiner, number of accounts still active after departure, and licence utilisation.

FAQ

Questions about these examples

Are these real client projects?

No. They are generalised scenarios illustrating a typical flow of work and what gets measured. Client names, data and figures are not published — confidentiality is part of the job. When discussing your situation we talk about specific numbers, not generalisations.

How long does this kind of work take?

A fixed-scope assessment usually takes a few weeks. A pilot automating one workflow runs from a few weeks to a couple of months. An infrastructure migration depends on the number of dependencies and is normally split into stages.

Can we start with just one of these?

Yes, and usually you should. One finished process produces both a result and the basis for deciding about expansion — far cheaper than a broad programme started from assumptions.

How do you choose where to start?

By impact and risk: whatever costs the most time or carries the most risk today. A first conversation usually settles it, even when the problem initially looked like it was somewhere else.

START HERE

Which example is closest to your situation?

If one of them looks familiar, the first conversation will be concrete — about your numbers rather than general principles.

Send an email

info@norv.lt