> For the complete documentation index, see [llms.txt](https://bluurdoc.bluur.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bluurdoc.bluur.ai/rozpoczecie-pracy/pomoc-techniczna.md). # Pomoc techniczna ## **Zgłoszenie błędu** Dla zachowania skuteczności zgłoszeń wymagane jest spełnienie warunków niniejszej procedury. Udostępnia się następujące kanały dokonywania zgłoszeń: 1. adres poczty elektronicznej: **,** 2. numery telefoniczne czynne w dni robocze (opcja),
Zgłoszenie błędu Dla zachowania skuteczności zgłoszeń wymagane jest spełnienie warunków niniejszej procedury. 1. Udostępnia się następujące kanały dokonywania zgłoszeń: 1. adres poczty elektronicznej: **,** 2. numery telefoniczne czynne w dni robocze (opcja), 2. Dokonując zgłoszenia obligatoryjnie należy podać: 1. dane kontaktowe do osoby wyznaczonej po stronie do kontaktów w ramach zgłoszenia, 2. możliwie dokładny opis problemu wraz z podaniem podjętych już czynności zmierzających do rozwiązania problemu, o ile takie poczyniono, 3. nazwę aplikacji, której dotyczy problem, 4. określenia kategorii zgłoszenia i/lub skutków biznesowych, 5. datę i godzinę wystąpienia problemu. 3. Zgłoszenie wysłane na monitorowaną skrzynkę odbiorczą „****” jest zwrotnie potwierdzane przyjęciem tego zgłoszenia. Brak zwrotnego potwierdzenia oznacza, że zgłoszenie nie dotarło do Wykonawcy.
Procesowanie zgłoszenia 1. Weryfikacja zgłoszenia: zgłoszenie jest weryfikowane pod względem typu i jest przydzielone do odpowiedniego konsultanta. 2. Jeśli weryfikacja lub realizacja obsługi zgłoszenia będzie wymagała dostępu zdalnego lub bezpośredniego do Oprogramowania, zgłaszający winien zapewnić taką możliwość. 3. Jeśli do prawidłowej obsługi zgłoszenia będą potrzebne pliki konfiguracyjne, logi lub inne informacje dodatkowe, zgłaszający powinien zapewnić do nich dostęp. 4. Konsultant dedykowany do obsługi zgłoszenia przystępuje do realizacji prac w możliwie najkrótszym czasie, zgodnie z priorytetami zgłoszeń i w ramach godzin świadczenia usługi.
Status zgłoszeń Zgłoszenia mogą przyjmować następujące statusy: * **OTWARTE** – zgłoszenie zarejestrowane w systemie, * **W TRAKCIE REALIZACJI** – zgłoszenie, nad którym toczą się prace, * **OCZEKUJĄCE** – zgłoszenia zakończone, niezweryfikowane przez Zgłaszającego, * **ZAMKNIĘTE/ROZWIĄZANE** – zgłoszenie zrealizowane, zweryfikowane przez Zgłaszającego i potwierdzone, * **OTWARTE PONOWNIE** – zgłoszenie zamknięte, w którym w terminie późniejszym wykryto ten sam błąd (nieujawniony podczas testów).
Odbiór zgłoszeń 1. Zgłaszający jest informowany o wykonanych pracach i statusie zgłoszenia przez konsultanta drogą e-mail. 2. Konsultant oznacza zgłoszenie jako „zamknięte / rozwiązane”. 3. Jeśli Zgłaszający wykryje w czasie późniejszym nieujawnione wcześniej wady dotyczące tego zgłoszenia, zgłasza niezwłocznie ten fakt, a zgłoszenie jest otwierane ponownie i weryfikowane. 4. W przypadku braku odpowiedzi na informację o wykonanym zgłoszeniu odbioru przez 7 dni, zgłoszenie zyskuje status rozwiązanego.
{% tabs %} {% tab title="SLA STANDARD 5 / 8-16" %} | Kategoria błędu / Priorytet | Czas reakcji\* | Czas naprawy lub obejścia błędu\* | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | --------------------------------- | | **błąd krytyczny** / bardzo wysoki – uniemożliwiający korzystanie z oprogramowania lub blokujący realizację kluczowych procesów biznesowych klienta (unieruchomienie lub zawieszenie się systemu, znaczące zakłócenie pracy dla co najmniej 10% użytkowników Oprogramowania) i wymagający jak najszybszej naprawy bądź obejścia | 4 godziny robocze | 12 godzin | | **błąd standardowy** / wysoki – wpływający na funkcjonalność i wygodę korzystania z oprogramowania, jednak nie blokujący podstawowych zadań użytkowników (zmniejszona wydajność pracy, brak dostępności części danych) | 16 godzin roboczych | 7 dni roboczych | | **incydent** / pozostały – nieprawidłowe działanie systemu, jednak w formie zupełnie niewpływającej na pracę użytkowników | 1 dzień roboczy | 14 dni roboczych | | **konsultacje** – czas dostawcy oprogramowania poświęcony na komunikację z Użytkownikiem, wsparcie, porady, instrukcje | 5 dni roboczych | – | | **rozwój** – wszelkie prace niezwiązane z naprawą błędów, a np. modyfikacją oprogramowania | 20 dni roboczych | – | | {% endtab %} | | | {% tab title="SLA STANDARD 5 / 8-23" %} | Kategoria błędu / Priorytet | Czas reakcji\* w dni robocze 8.00-23.00 | Czas naprawy\* w dni robocze 8.00-23.00 | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | --------------------------------------- | | **błąd krytyczny** / bardzo wysoki – uniemożliwiający korzystanie z oprogramowania lub blokujący realizację kluczowych procesów biznesowych klienta (unieruchomienie lub zawieszenie się systemu, znaczące zakłócenie pracy dla co najmniej 10% użytkowników Oprogramowania) i wymagający jak najszybszej naprawy, bądź obejścia | 4 godziny robocze | 8 godzin | | **błąd standardowy** / wysoki – wpływający na funkcjonalność i wygodę korzystania z oprogramowania, jednak nie blokujący podstawowych zadań użytkowników (zmniejszona wydajność pracy, brak dostępności części danych) | 16 godzin roboczych | 7 dni roboczych | | **incydent** / pozostały – nieprawidłowe działanie systemu, jednak w formie zupełnie niewpływającej na pracę użytkowników | 1 dzień roboczy | 14 dni roboczych | | **konsultacje** – czas dostawcy oprogramowania poświęcony na komunikację z Użytkownikiem, wsparcie, porady, instrukcje | 5 dni roboczych | – | | **rozwój** – wszelkie prace niezwiązane z naprawą błędów, a np. modyfikacją oprogramowania | 20 dni roboczych | – | | {% endtab %} | | | {% tab title="SLA STANDARD 7 / 8-23" %} | Kategoria błędu / Priorytet | Czas reakcji\* w dni robocze 8.00-23.00 | Czas naprawy\* w dni robocze 8.00-23.00 | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | --------------------------------------- | | **błąd krytyczny** / bardzo wysoki – uniemożliwiający korzystanie z oprogramowania lub blokujący realizację kluczowych procesów biznesowych klienta (unieruchomienie lub zawieszenie się systemu, znaczące zakłócenie pracy dla co najmniej 10% użytkowników Oprogramowania) i wymagający jak najszybszej naprawy, bądź obejścia | 4 godziny robocze | 8 godzin | | **błąd standardowy** / wysoki – wpływający na funkcjonalność i wygodę korzystania z oprogramowania, jednak nie blokujący podstawowych zadań użytkowników (zmniejszona wydajność pracy, brak dostępności części danych) | 16 godzin roboczych | 7 dni roboczych | | **incydent** / pozostały – nieprawidłowe działanie systemu, jednak w formie zupełnie niewpływającej na pracę użytkowników | 1 dzień roboczy | 14 dni roboczych | | **konsultacje** – czas dostawcy oprogramowania poświęcony na komunikację z Użytkownikiem, wsparcie, porady, instrukcje | 5 dni roboczych | – | | **rozwój** – wszelkie prace niezwiązane z naprawą błędów, a np. modyfikacją oprogramowania | 20 dni roboczych | – | | {% endtab %} | | | | {% endtabs %} | | | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://bluurdoc.bluur.ai/rozpoczecie-pracy/pomoc-techniczna.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.