FI Finnish
SE Swedish
FR French
PL Polish
DE German
US English (US)

Contact Us

If you still have questions or prefer to get help directly from an agent, please submit a request.
We’ll get back to you as soon as possible.

Please fill out the contact form below and we will reply as soon as possible.

Polish
FI Finnish
SE Swedish
FR French
PL Polish
DE German
US English (US)
  • Log in
  • Home
  • Zarządzanie usługami
  • Rozwiązanie Matrix42 Core
  • Biblioteka rozwiązań Matrix42 Core
  • Procesy i przypadki użycia Matrix42 Core
  • Pro : Zarządzanie prośbami o usługę

Przegląd procesu: Zarządzanie wnioskami Pro

Contact Us

If you still have questions or prefer to get help directly from an agent, please submit a request.
We’ll get back to you as soon as possible.

Please fill out the contact form below and we will reply as soon as possible.

  • Zarządzanie usługami
    Rozwiązanie Matrix42 Professional Rozwiązanie Matrix42 Core Zarządzanie usługami przedsiębiorstwa Inteligencja Matrix42
  • Zarządzanie tożsamością i administracja ( IGA )
    Przegląd IGA Biblioteka rozwiązań IGA
  • Platforma
    ESM ESS2 ES Efecte Chat do zarządzania usługami Efektywne integracje Dodatki
  • Informacje o wydaniu dla M42 Core & Pro , IGA , Conversational AI
    2025.3 2025.2 2025.1 2024.2 2024.1 2023.4 2023.3 2023.2 2023.1 2022.4 2022.3 Informacje i zasady dotyczące wydania
  • Inny materiał
    Wytyczne uid terminów i dokumentacji Oświadczenia dotyczące dostępności
  • Usługi
+ More
    • Zarządzanie usługami

    • Zarządzanie tożsamością i administracja ( IGA )

    • Platforma

    • Informacje o wydaniu dla M42 Core & Pro , IGA , Conversational AI

    • Inny materiał

    • Usługi

Przegląd procesu: Zarządzanie wnioskami Pro

Przegląd procesu: Zarządzanie wnioskami Pro

Streszczenie

Zarządzanie zgłoszeniami serwisowymi (SRP) to proces zarządzania usługami informatycznymi (ITSM), który koncentruje się na efektywnym zarządzaniu i realizacji zgłoszeń użytkowników dotyczących różnych usług i zasobów IT. W przeciwieństwie do incydentów, które zazwyczaj wiążą się z zakłóceniami lub problemami, zgłoszenia serwisowe są zazwyczaj rutynowe i dotyczą z góry określonych potrzeb lub wymagań użytkowników.

Zarządzanie zgłoszeniami serwisowymi ma na celu usprawnienie i przyspieszenie procesu realizacji zgłoszeń użytkowników, zapewniając ich terminową obsługę i wysoki poziom satysfakcji klienta. Obejmuje to ustrukturyzowany przepływ pracy, przy jednoczesnym przestrzeganiu predefiniowanych umów o poziomie usług (SLA) .

Przypadki użycia

Proces obejmuje przypadki użycia wysokiego poziomu wymienione poniżej. Opisy tych przypadków użycia można znaleźć na odpowiednich stronach, dostępnych za pośrednictwem linków podanych na liście. Te dedykowane strony szczegółowo omawiają przypadki użycia, przykładowe scenariusze, przepływy pracy, wyniki i korzyści związane z każdym przypadkiem użycia, oferując szczegółowy wgląd w ich role w procesie.

  1. Tworzenie żądań serwisowych
  2. Zatwierdzanie wniosków o usługi
  3. Realizacja żądań serwisowych
  4. Zamykanie zgłoszeń serwisowych

Diagram przypadku użycia

Kanały wejściowe

Samoobsługa jest głównym i jedynym zalecanym kanałem wprowadzania zgłoszeń serwisowych. Wymagając od użytkowników przesyłania zgłoszeń za pośrednictwem samoobsługi, umożliwia zespołom wsparcia świadczenie standaryzowanej obsługi. Ponadto, przesyłanie zgłoszeń za pośrednictwem samoobsługi gwarantuje, że w razie potrzeby przejdą one przez proces zatwierdzania. Wymaganie od użytkowników przesyłania zgłoszeń za pośrednictwem samoobsługi niesie ze sobą szereg korzyści:

  • Wydajność i wygoda
    • Samoobsługa zapewnia użytkownikom wygodny sposób zgłaszania zgłoszeń serwisowych o dowolnej porze i z dowolnego miejsca, bez konieczności oczekiwania na dostępność personelu wsparcia. Użytkownicy mogą uzyskać dostęp do samoobsługi i zgłaszać zgłoszenia w dogodnym dla siebie czasie, co przekłada się na krótszy czas reakcji i szybsze rozwiązywanie ich potrzeb.
  • Standaryzacja i spójność
    • Samoobsługa umożliwia zespołom wsparcia definiowanie standardowych formularzy zgłoszeń, które mogą inicjować przepływy pracy w narzędziu Service Management Tool. Gwarantuje to, że wszystkie niezbędne informacje są gromadzone z góry i eliminuje potrzebę ciągłej komunikacji w celu zebrania dodatkowych szczegółów. Dzięki egzekwowaniu spójnych formatów zgłoszeń, zespołom wsparcia łatwiej jest je zrozumieć i sprawnie przetwarzać.
  • Zmniejszone obciążenie komunikacyjne
    • Zgłaszanie zgłoszeń serwisowych telefonicznie lub e-mailem często wymaga dodatkowej komunikacji między użytkownikami a personelem wsparcia w celu wyjaśnienia szczegółów lub zebrania brakujących informacji. Portale samoobsługowe pozwalają użytkownikom na wcześniejsze podanie wszystkich niezbędnych informacji, zmniejszając potrzebę dalszej komunikacji i minimalizując opóźnienia w realizacji zgłoszeń.
  • Szybsze przetwarzanie i rozwiązywanie Pro
    • Zgłoszenia serwisowe złożone w ramach samoobsługi mogą być kierowane do grup wsparcia w narzędziu do zarządzania usługami na podstawie predefiniowanych reguł. Pozwala to na szybkie przydzielanie zgłoszeń do odpowiednich grup wsparcia, gwarantując ich szybką realizację.
  • Lepsza przejrzystość i widoczność
    • Samoobsługa zapewnia użytkownikom wgląd w status i postęp realizacji zgłoszeń serwisowych. Użytkownicy mogą śledzić cykl życia swoich zgłoszeń, przeglądać aktualizacje i dodawać komentarze w samoobsłudze. Ta transparentność zwiększa zadowolenie użytkowników i zmniejsza potrzebę kontaktowania się z pomocą techniczną w celu uzyskania aktualizacji statusu.

Automatyczne powiadomienia e-mail

Rozwiązanie wysyła predefiniowane powiadomienia e-mail. Treść powiadomień e-mail może zostać zmieniona przez administratora. W razie potrzeby osoby przypisane do zgłoszenia mogą dezaktywować wysyłane do nich powiadomienia e-mail, edytując swoją kartę osoby. Poniższa tabela przedstawia automatyczne powiadomienia e-mail powiązane z procesem zarządzania incydentami.

Automatyczne powiadomienia e-mail są wysyłane za pomocą zdarzeń w narzędziu Efecte Service Management Tool. Jednak treść wiadomości e-mail jest definiowana za pomocą kart danych powiadomień e-mail . Wiadomości e-mail są wysyłane z krótkim opóźnieniem (~1 minuta) po wystąpieniu zdarzenia.

# Opis powiadomienia Adres nadawcy Odbiorca Wysłane kiedy
1 Bilet utworzony [zdefiniowane przez klienta] Klient biletu Po utworzeniu zgłoszenia.
2 Zmiana zespołu na bilecie [zdefiniowane przez klienta] Członkowie zespołu, do którego przypisano Bilet Po zmianie zespołu.

Bilet czeka na zatwierdzenie [zdefiniowane przez klienta]
Bezpośredni przełożony klienta Po utworzeniu zgłoszenia wymagającego zatwierdzenia.

Bilet zatwierdzony [zdefiniowane przez klienta]
Klient biletu
Po zatwierdzeniu biletu.

Bilet odrzucony [zdefiniowane przez klienta]
Klient biletu Po odrzuceniu biletu.

Utworzono lokalne dane uwierzytelniające użytkownika
[zdefiniowane przez klienta]

Klient biletu
Po pomyślnym przetworzeniu żądania użytkownika lokalnego.

Utworzono hasło użytkownika lokalnego
[zdefiniowane przez klienta]
Klient biletu

Po pomyślnym przetworzeniu żądania użytkownika lokalnego.

Nie udało się utworzyć lokalnego użytkownika
[zdefiniowane przez klienta]
Klient biletu
Po nieudanej próbie utworzenia użytkownika lokalnego (np. gdy użytkownik już istnieje).
3 Zbliża się termin SLA w przypadku zgłoszenia [zdefiniowane przez klienta] Kierownik kolejki zespołu Pięć godzin przed czasem rozwiązania docelowego
4 Dotarł nowy e-mail do zgłoszenia [zdefiniowane przez klienta] Mandatariusz Po otrzymaniu nowego e-maila na zgłoszenie
5 Klient dodaje komentarz z samoobsługi [zdefiniowane przez klienta] Mandatariusz Po dodaniu komentarza przez klienta
6 Zmiana osoby przypisanej do zgłoszenia [zdefiniowane przez klienta] Nowy cesjonariusz Po zmianie cesjonariusza
7 Osoba przypisana dodaje komentarz do samoobsługi [zdefiniowane przez klienta] Klient biletu
Po dodaniu komentarza
8 Zadanie przypisane [zdefiniowane przez klienta] Mandatariusz Po przydzieleniu zadania
9 Bilet został rozwiązany [zdefiniowane przez klienta] Klient biletu
Po rozwiązaniu zgłoszenia

Terminologia

Termin Wyjaśnienie
Przepływ zatwierdzania Proces zatwierdzania wniosku o usługę.
Zatwierdzający Osoba podejmująca decyzje o zatwierdzeniu.
Żądanie serwisowe Formalne zgłoszenie od użytkownika z prośbą o dostęp do usług IT, takich jak instalacja oprogramowania, konfiguracja sprzętu, resetowanie hasła lub uprawnienia dostępu. Żądania serwisowe są reprezentowane przez zgłoszenia.
Przedmiot usługi Pozycja katalogowa, którą użytkownicy końcowi mogą zamówić, składając wniosek serwisowy w systemie samoobsługowym. Pozycja może być przedmiotem materialnym, takim jak urządzenie, oprogramowanie lub usługa.

Wymagania wstępne

  • Zdefiniowany katalog usług
    • Dobrze zdefiniowany katalog usług, który jasno określa dostępne usługi informatyczne, ich opisy, poziomy usług i powiązane procesy obsługi zgłoszeń. Katalog ten służy użytkownikom jako punkt odniesienia, ułatwiając im zrozumienie dostępnych usług i wybór tych, które odpowiadają ich potrzebom.
  • Umowy o poziomie usług (SLA)
    • Ustanowienie umów SLA, które określają oczekiwany czas reakcji i rozwiązania dla różnych typów zgłoszeń serwisowych. Umowy SLA pomagają jasno określić oczekiwania użytkowników i zapewnić, że zgłoszenia będą rozpatrywane w uzgodnionych ramach czasowych.
  • Zespół wsparcia i przepływ pracy
    • Utworzenie dedykowanego zespołu wsparcia lub osób odpowiedzialnych za zarządzanie zgłoszeniami serwisowymi. Zdefiniowanie jasnych przepływów pracy i ról w zespole wsparcia zapewnia sprawną obsługę zgłoszeń, odpowiednie przydzielanie zadań i eskalację w razie potrzeby.
  • Kanały i Pro komunikacji
    • Ustanowienie jasnych uid dla użytkowników dotyczących zgłaszania zgłoszeń serwisowych (zazwyczaj w trybie samoobsługi) oraz przejrzystej komunikacji (zazwyczaj poprzez e-mail i komentarze w trybie samoobsługi). Użytkownicy powinni być poinformowani o tych uid i zachęcani do korzystania z wyznaczonej metody.
  • Szkolenia i świadomość
    • Pro szkolenia i sesje uświadamiające dla użytkowników i zespołów wsparcia w zakresie procesu zarządzania zgłoszeniami serwisowymi. Dzięki temu użytkownicy rozumieją, jak skutecznie zgłaszać zgłoszenia, a zespoły wsparcia są dobrze zorientowane w obsłudze i skutecznym rozwiązywaniu zgłoszeń.

Korzyści

  • Ulepszone wrażenia użytkownika
    • Proces ten podnosi poziom zadowolenia użytkowników poprzez zapewnienie przyjaznej samoobsługi, przejrzystych kanałów komunikacji i efektywnego przetwarzania żądań, co przekłada się na pozytywne ogólne doświadczenia użytkowników.
  • Szybsza realizacja usług
    • Dzięki usprawnionym przepływom pracy i przestrzeganiu umów SLA proces ten pozwala na szybsze czasy reakcji i rozwiązywania żądań serwisowych, co ogranicza przestoje i gwarantuje szybką realizację usług.
  • Standaryzacja i spójność
    • Proces ten umożliwia standaryzację formularzy wniosków, kryteriów klasyfikacji i przepływów pracy. Gwarantuje to, że wszystkie wnioski są rejestrowane w spójny sposób, co ułatwia ich zrozumienie, efektywne kierowanie i standaryzację procesu realizacji.


Aktorzy i role

Rola Opis Role w narzędziu Efecte Service Management Tool (ESM)
Użytkownik końcowy Osoba korzystająca z produktów i usług oferowanych przez firmę.

Brak (użytkownicy końcowi nie mają dostępu do ESM)
Agent Service Desk Pro wsparcie klientom końcowym. Agent Service Desk należy do grupy wsparcia, która działa
jako pierwszy punkt kontaktu dla użytkowników końcowych.
Agent Service Desk
Zatwierdzający Osoba zatwierdzająca (bezpośredni przełożony wnioskodawcy) podejmuje decyzje o zatwierdzeniu wniosków o usługi. Nie dotyczy
Aktorzy zewnętrzni Podmiotami zewnętrznymi są często dostawcy świadczący firmie usługi informatyczne. Nie dotyczy

Najlepsze praktyki dotyczące zmiany typów biletów

Incydenty, zlecenia serwisowe i zgłoszenia informacyjne są przetwarzane w szablonie zgłoszenia. Atrybut typu zgłoszenia służy do definiowania typu zgłoszenia. Zaleca się poinstruowanie użytkowników końcowych, aby korzystali z odpowiednich formularzy w portalu samoobsługowym, aby zapewnić im płynne działanie. Zdarza się jednak, że zgłoszenia nie są przesyłane za pośrednictwem prawidłowego formularza. W takich sytuacjach możliwa jest zmiana typu zgłoszenia, z pewnymi ograniczeniami. Poniżej wymieniono dozwolone i niedozwolone zmiany typu zgłoszenia.

Dozwolone zmiany typu biletu

  • Zlecenie serwisowe → Incydent
  • Zamówienie serwisowe → Prośba o informację
  • Incydent → Prośba o informację
  • Prośba o informację → Incydent

Niedozwolone zmiany typu biletu

  • Incydent → Zlecenie serwisowe
    • Typu zgłoszenia nie można zmienić z „Incydent” na „Zlecenie serwisowe”, ponieważ zlecenia serwisowe (zgłoszenia serwisowe) zazwyczaj wymagają zatwierdzenia. Zlecenia muszą zostać przesłane za pośrednictwem portalu samoobsługowego, aby zapewnić zgodność z predefiniowanymi procedurami zatwierdzania.
  • Prośba o informację → Zlecenie serwisowe

Często zadawane pytania

  • A co jeśli użytkownik końcowy spróbuje złożyć zamówienie, zgłaszając incydent?
    • Zaleca się, aby poprosić klienta o złożenie zamówienia za pośrednictwem odpowiedniego formularza w portalu samoobsługowym. Prawidłowy proces zatwierdzania, który pozostawia ślad audytu, jest możliwy tylko w przypadku zamówień złożonych za pośrednictwem portalu samoobsługowego.
    • W przypadku częstych przypadków zaleca się utworzenie formularza Quickfill, który umożliwi service desk instruowanie użytkowników końcowych. Zaleca się również korzystanie z predefiniowanego szablonu wiadomości e-mail.
  • Co zrobić, jeśli użytkownicy końcowi często zgłaszają za pośrednictwem formularza zgłoszenia zapotrzebowanie na usługi, których nie ma w katalogu usług?
    • Zaleca się identyfikację najczęściej zadawanych pytań i wprowadzenie ich do katalogu usług, aby umożliwić użytkownikom końcowym składanie wniosków poprzez zamówienie usługi w systemie samoobsługowym. Pozwala to na standaryzację procesu z predefiniowanymi zadaniami, które są również zgodne z zasadami zatwierdzania.
  • Jaki jest domyślny typ biletu, gdy bilety są tworzone ręcznie lub za pośrednictwem wiadomości e-mail?
    • Typ zgłoszenia, które są tworzone ręcznie lub docierają pocztą elektroniczną, jest domyślnie ustawiony na Zgłoszenie incydentalne. Powyższe zasady obowiązują niezależnie od kanału, którym otrzymano Zgłoszenie.

Was this article helpful?

Yes
No
Give feedback about this article

Related Articles

  • Przypadek użycia: Tworzenie żądań serwisowych
  • Przypadek użycia: Zatwierdzanie żądań serwisowych
  • Przypadek użycia: realizacja żądań serwisowych
  • Przypadek użycia: Zamykanie żądań serwisowych

Copyright 2026 – Matrix42 Professional.

Matrix42 homepage


Knowledge Base Software powered by Helpjuice

0
0
Expand