---
title: "Co naprawdę obiecuje Wasza umowa na wsparcie IT"
url: "https://sovereos.com/pl/blog/co-naprawde-obiecuje-umowa-na-wsparcie-it"
description: "Większość umów serwisowych mierzy, jak szybko dostawca odpisze, a nie jak szybko wszystko znów działa. Gdzie rozjeżdża się obietnica z oczekiwaniem i o co prosić."
---

# Co naprawdę obiecuje Wasza umowa na wsparcie IT

8 października 2026·3 min czytania·Redakcja

Dwoje młodych współpracowników czyta razem wydrukowaną kartkę przy okrągłym drewnianym stole, jedno wskazuje ją ołówkiem, a w tle stoją przeszklona szafa serwerowa i inni pracownicy.

Poniedziałek, za dwadzieścia dziewiąta. Wspólna skrzynka, na którą przychodzą zamówienia od klientów, przestaje cokolwiek odbierać. Idzie zgłoszenie. Kilka minut później automatyczna odpowiedź potwierdza, że zarejestrowano je jako incydent o zwykłym priorytecie. Umowa obiecuje dla tego priorytetu reakcję w tym samym dniu roboczym i dostawca dotrzymuje słowa: przed obiadem odpisuje inżynier i prosi o zrzut ekranu.

Skrzynka znów działa w środę po południu. Przez dwa dni zamówienia szły telefonicznie i na prywatne adresy. Każdy zapis umowy został dotrzymany.

Przyczyną nie jest zły dostawca. Większość umów serwisowych mierzy to, co dostawca kontroluje — jak szybko potwierdzi zgłoszenie — i pozwala mu decydować, jak poważny jest Wasz problem. To, na czym naprawdę zależy firmie, czyli kiedy wszystko znów zadziała, często w ogóle nie trafia do umowy.

## Gdzie obietnica rozjeżdża się z oczekiwaniem

**Reakcja, a nie rozwiązanie.** Czas reakcji spełnia odpowiedź na zgłoszenie. Sprawdźcie, czy gdziekolwiek w umowie jest cel dla przywrócenia działania, a jeśli jest — czy to zobowiązanie, czy tylko dążenie.

**Priorytet ustala dostawca.** Waga zgłoszenia zależy od kryteriów technicznych, na przykład liczby osób, których dotyczy problem, a nie od tego, co stanęło. Skrzynka zamówień to jedna skrzynka, więc nigdy nie jest krytyczna — nawet w dniu, w którym jest najważniejszym systemem w budynku.

**Zegar się zatrzymuje.** Tylko godziny pracy, pauza na czas oczekiwania na klienta, zawieszenie, gdy w sprawę zamieszana jest strona trzecia. Każda z tych pauz osobno jest rozsądna, a razem pozwalają dopasować dowolny przebieg.

**Wyłączenia robią całą robotę.** Oprogramowanie branżowe, dostawcy dostawcy, wszystko, czego nie ma na liście zasobów — której nikt nie aktualizował od podpisania umowy.

**Wiedza zostaje u dostawcy.** Naprawy dzieją się w jego systemie zgłoszeń i w głowach jego inżynierów. Dokumentacja nie jest produktem umowy, więc po trzech latach firma wie o własnym środowisku mniej niż na początku. Pojedynczy punkt awarii opisany w tekście [Waszym planem ciągłości jest jedna osoba](https://sovereos.com/pl/blog/planem-ciaglosci-jest-jedna-osoba) nie zniknął. Przeniósł się do innej firmy.

**Wyjście jest nieokreślone.** Co zostaje przekazane na koniec, w jakiej postaci, w jakim terminie i czy konta administracyjne są w ogóle zarejestrowane na Was.

## O co prosić zamiast tego

**Priorytet zdefiniowany Waszymi kategoriami.** Wypiszcie kilka rzeczy, bez których firma staje — przyjmowanie zamówień, fakturowanie, płace, system magazynowy, poczta — i uzgodnijcie, że awaria którejkolwiek z nich ma najwyższy priorytet, niezależnie od liczby osób, których dotyczy.

**Cele przywrócenia działania dla tych systemów.** Czas do chwili, w której firma może znów pracować, choćby przez obejście — a nie czas do pierwszej odpowiedzi. Dostawca, który nie zobowiąże się do liczby, powinien przynajmniej zobowiązać się do procesu: kto jest wzywany, jak często dostajecie informację o postępie i kiedy sprawa idzie wyżej.

**Wskazany z imienia inżynier.** Ktoś, kto zna Wasze środowisko, z wyznaczonym zastępcą — zamiast tego, kto akurat weźmie zgłoszenie ze wspólnej kolejki.

**Dokumentacja jako produkt umowy.** Każda zmiana i każda istotna naprawa zapisana w bazie wiedzy, która należy do firmy i którą firma może czytać, przeglądana wspólnie raz na kwartał.

**Poświadczenia w Waszych rękach.** Konta administracyjne zarejestrowane na firmę, a dostęp dostawcy przyznawany per osoba i do odebrania w dniu zakończenia współpracy.

**Klauzula wyjścia uzgodniona na starcie.** Co zostaje przekazane, w jakim formacie, w jakim terminie i za jaką cenę. Uzasadnienie jest w tekście [Nikt nie potrafi wycenić wyjścia](https://sovereos.com/pl/blog/nikt-nie-potrafi-wycenic-wyjscia): koszt, którego nikt nie nazwał, to koszt, który druga strona ustali później.

Tą samą listą kierujemy się, projektując własne umowy — warunki wsparcia mają w nich stać [obok warunków wyjścia](https://sovereos.com/pl), a nie w osobnym załączniku. Jesteśmy przed startem i nie mamy jeszcze umów z klientami, a szczegóły ustalamy w każdej umowie osobno, więc traktujcie to jako listę kontrolną, a nie referencję.

## Test

Weźcie obecną umowę na wsparcie i znajdźcie stronę, która odpowiada na każde z tych pytań:

1.  Jaki jest cel dla przywrócenia działania, a nie dla reakcji?
2.  Kto decyduje o priorytecie zgłoszenia?
3.  Kiedy zegar się zatrzymuje?
4.  Co jest wyłączone?
5.  Do kogo należy dokumentacja powstająca przy obsłudze Waszej firmy?
6.  Czy konta administracyjne są zarejestrowane na Waszą firmę?
7.  Co dzieje się z Waszymi danymi, konfiguracją i poświadczeniami, gdy umowa się kończy?

Przy każdej odpowiedzi zapiszcie numer strony. Jeśli przy więcej niż dwóch pytaniach wychodzi „nie ma tego w umowie”, nie kupujecie tego, co myślicie, że kupujecie. Warto to wiedzieć przed terminem odnowienia, a nie w poniedziałek, w którym skrzynka zamówień nagle milknie.

-   SLA
-   usługi zarządzane
-   wsparcie IT
-   umowy

## Czytaj dalej

-   [Jak zbudować fabrykę agentów w IT firmy: pętla etap po etapie](https://sovereos.com/pl/blog/jak-zbudowac-fabryke-agentow-w-it-firmy)
-   [Fabryka agentów działa u dostawcy. Czyja jest wiedza, którą w niej zostawiacie?](https://sovereos.com/pl/blog/czyja-jest-fabryka-agentow)