Zarządzanie zgłoszeniami

Nowe zgłoszenie zakładasz przyciskiem „New Ticket” na lewym pasku. Formularz nazywa się „Create new ticket”. Jako agent zapisujesz nim także sprawy innych osób. Do tego służy pole „User”: mówi ono, dla kogo jest sprawa, a nie kto ją wpisuje.

Wszystko z gwiazdką jest obowiązkowe: „Title”, „User”, „Main category” i „Description”. Jest jeszcze jedno, które łatwo przeoczyć: formularz nie zapisze się bez podkategorii, choć „Subcategory” nie nosi gwiazdki. Kategoria główna i podkategoria należą do siebie i zawsze ustawia się je parami.

To, które pola są obowiązkowe, ustawia się pod „Settings → Ticket Settings”. Karta „Admin / Agent Field Settings” ma do tego tylko przełącznik „Field is mandatory”. Karta „Customer Field Settings” ma dodatkowo „Is hidden for Customer” i „Is not editable”. Dlatego klient może widzieć krótszy formularz niż Ty, a nikt nie musi utrzymywać dwóch formularzy. „Title” i „Description” są zawsze obowiązkowe. Tego nie da się wyłączyć.

Potem możesz zmienić prawie wszystko: po prawej stronie zgłoszenia stoi karta „Details” ze zgłaszającym, telefonem, adresem e-mail, lokalizacją, kategorią i numerem referencyjnym. Zmieniasz samo pole i potwierdzasz przyciskiem „Save” pod nim. Status, przypisanie, priorytet, kanał i obserwatorzy stoją jedną kartę wyżej pod „Actions”. Status i przypisanie działają natychmiast. Priorytet, kanał i obserwatorzy zapisują się dopiero przyciskiem „Save” na karcie „Details”.

Zmieniać to mogą tylko agenci i administratorzy. Zgłaszający może czytać sprawę, komentować ją i dołączać pliki, ale nie zmieniać klasyfikacji, na której opierają się Twoje raporty.

Jeden skutek uboczny warto poznać raz: jeśli edytujesz zgłoszenie, które nie należy jeszcze do nikogo, potem należy ono do Ciebie. System wpisuje Cię jako agenta i przesuwa status z „Open” na „Assigned”. Jedno i drugie trafia do historii. Jeśli tego nie chciałeś, przypisz je potem komuś innemu.

Każda z tych zmian trafia do historii zgłoszenia, z nazwiskiem, czasem, starą i nową wartością. Nie musisz nic do tego włączać.

Zostaje pytanie, jak znowu pozbyć się zgłoszeń. Pod „Settings → Archive” wybierasz zakres dat, przyciskiem „Preview” widzisz, ile zamkniętych zgłoszeń obejmuje, a przyciskiem „Create archive” tworzysz plik ZIP: zgłoszenia, komentarze, historia, pola własne i załączniki, wszystko w jednym pliku. Utworzenie niczego nie usuwa. Zgłoszenia opuszczają działającą bazę danych dopiero osobnym krokiem „Delete from live DB” na liście „Existing archives”, a z tego samego pliku da się je przywrócić.

Opis i komentarze nie są gołymi polami tekstowymi. Każde ma nad sobą pasek narzędzi, a przyciski mówią po najechaniu, co robią: „Bold”, „Italic”, „Underline”, „Strikethrough”, „Text color”, „Highlight color”, „Bullet list”, „Numbered list”, „Quote”, „Link” i „Clear formatting”.

Tak powstaje odnośnik: zaznacz tekst, kliknij „Link”, wpisz adres w małym okienku. Puste pole usuwa odnośnik z powrotem. Dopuszczone są adresy internetowe i pocztowe (http, https, mailto). Wszystko inne jest odrzucane przy zapisie, żeby komentarz nie mógł niczego nikomu podsunąć.

Obrazki wchodzą przez schowek: zrób zrzut ekranu i wklej go wprost do edytora skrótem Ctrl+V. Na początku w tekście widać tylko oznaczenie w rodzaju „[inline-image:1]”. Przy zapisie system wysyła obrazek i pokazuje go dokładnie tam, a poza tym trafia on do zakładki „Attachments”, gdzie mieszkają wszystkie pliki sprawy. Wklejanie obrazków działa w opisie istniejącego zgłoszenia i w nowym komentarzu. Nie działa w formularzu „Create new ticket” ani podczas edycji komentarza.

To, co widzisz, widzą też inni: formatowanie, listy i odnośniki zostają zachowane w zgłoszeniu, a także w wiadomości do zgłaszającego. Obcy kod, na przykład ze skopiowanej strony internetowej albo z przychodzącej wiadomości, zostaje przycięty do tego dopuszczonego zestawu. Nic z Twojego tekstu przy tym nie ginie, znika tylko opakowanie.

Komentarz można oznaczyć jako wewnętrzny przełącznikiem „Internal note (not visible to the customer)”. Nosi wtedy etykietę „Internal” i jest niewidoczny dla zgłaszającego. Nie znajdzie go też wyszukiwanie.

Każdy może zmieniać i usuwać własne komentarze. To, co napisał klient, może zmienić albo usunąć tylko ten klient albo administrator. Dotyczy to także jego wiadomości e-mail. Komentarze kolegów może zmieniać i usuwać każdy agent, który może pracować nad zgłoszeniem. Dotyczy to także zespołu, który miał zgłoszenie wcześniej.

Pliki należą do sprawy, a nie do pojedynczego komentarza. Przy zgłoszeniu zakładka „Attachments” prowadzi do listy: „Upload file” dodaje plik, a każdy wiersz nazywa plik, jego rozmiar i datę. Załączyć coś może każdy, kto bierze udział w zgłoszeniu, także zgłaszający. Dzięki temu nikt nie musi wysyłać Ci zrzutu ekranu pocztą. Klient może usuwać tylko załączniki, które sam wgrał. Gdy podzgłoszenie zostaje zamknięte, jego załączniki są kopiowane do zgłoszenia nadrzędnego, gdzie noszą etykietę „Internal”. Agenci je widzą, a klienci ani ich nie widzą, ani nie pobierają.

Kliknięcie nazwy otwiera podgląd, bez pobierania pliku. Obrazki można w nim powiększać, pomniejszać i obracać, co przydaje się przy wyświetlaczu sfotografowanym pod kątem. Plik PDF jest pokazywany w tym samym oknie, z przeglądem stron, powiększeniem i drukiem. Pliki tekstowe są pokazywane jako tekst. Przyciskiem „Open in new tab” otwierasz plik we własnym oknie.

Załącznik należy do sprawy i wędruje razem z nią: pojawia się w historii („File uploaded: …”), przeżywa przekazanie do innego zespołu i trafia do pliku archiwum, gdy zgłoszenie zostaje zarchiwizowane.

Zakładka „History” przy zgłoszeniu odpowiada na pytanie stojące za każdą dalszą pracą: kto co zmienił i kiedy? Każdy wiersz nazywa osobę, pole, starą wartość przekreśloną, nową za nią i czas co do sekundy. Najnowszy wpis jest na górze.

Wpisy powstają bez Twojego udziału: przy zmianach statusu, priorytetu, przypisania, kategorii, lokalizacji, obserwatorów, tytułu i opisu, a także przy założeniu („Ticket opened”), przy każdym komentarzu i przy każdym wgranym pliku. Liczba na zakładce mówi z góry, ile ruchu było w sprawie.

Historii nie da się edytować ani wyłączyć. Właśnie to czyni ją użyteczną: to z jej powodu zgłoszenia nie da się usuwać pojedynczo, a wędruje ona do pliku archiwum, gdy zgłoszenie zostaje zarchiwizowane.

Przy komentarzu historia zapisuje tylko, że go dodano, edytowano lub usunięto. Brzmienie znajduje się w zakładce „Comments”. Komentarz wewnętrzny też pokazuje się w historii, ale tylko agentom i administratorom.

Status mówi, gdzie zgłoszenie właśnie stoi. System przychodzi z dwunastoma statusami: Open, Assigned, In Progress, Waiting for User Response, Resolved, Closed i dalszymi. Znajdziesz je pod „Settings → General Settings” w sekcji „Drop-down lists” za zakładką „Status”. Przycisk „+ Add status” tworzy własny, a „Edit status” otwiera istniejący.

Ważna jest różnica między nazwą a znaczeniem. W edytorze statusu, pod „Meaning of this status”, są trzy przełączniki: „Counts as resolved”, „Counts as closed” i „Waiting for the requester”. Tylko te przełączniki mówią systemowi, jak traktować status.

Każdy status możesz zmienić, także te, które przychodzą z systemem: na dole edytora, pod „Translations”, jest pole „Name” dla każdego języka. Wpisz tam to, co mają czytać Twoi ludzie. Nazwa techniczna za nim zostaje nietknięta i właśnie dlatego nic się nie psuje: automatyzacja, raporty i przełączniki powyżej wiszą na tej nazwie, a nie na Twojej etykiecie. Dzięki temu „Resolved” może stać się „Done”.

Usuwanie nie działa jednak przy wszystkich. Osiem statusów nosi na liście etykietę „Mandatory”: Open, Assigned, In Progress, Resolved, Closed, Reopened, Waiting for approval i Rejected. Można je zmieniać i porządkować, ale nie usuwać, a próba kończy się jasnym komunikatem. Nie jest to po to, żeby Ci dokuczyć: wiszą na nich procesy, które inaczej stanęłyby bez słowa, na przykład automatyczne zamykanie, które potrzebuje statusu „rozwiązane” jako punktu wyjścia.

Dwa statusy należą do samego systemu: „Waiting for approval” i „Rejected” noszą etykietę „System only”. Wychodzą z procesu zatwierdzania i nikt nie powinien móc ręcznie twierdzić, że odrzucono coś, co nigdy nie stanęło do decyzji.

Co robią te trzy przełączniki: status liczony jako rozwiązany zamyka zgłoszenie sam po 24 godzinach. Status liczony jako zamknięty to stan końcowy, do którego zgłoszenie jest przenoszone. A „Waiting for the requester” znaczy dokładnie to: czekamy na zgłaszającego, a nie na inny zespół i nie na usługodawcę. To jest oznaczenie, na którym zatrzymuje się zegar SLA, jeśli tak to ustawisz.

Pod tym stoi „Allowed transitions to new status”. Zaznaczasz tutaj, do których statusów da się przejść z tego. Zostaw wszystko puste, a nic nie jest ograniczone. Zaznacz coś, a każda inna droga zostaje zamknięta. Tak buduje się obieg, którego nie da się przeskoczyć, na przykład: z „Open” można przejść tylko do „In Progress” albo „Assigned”, ale nie wprost do „Closed”.

Pozostałe przełączniki w edytorze to drobiazgi o dużym skutku: kolor na liście, „Sort order” dla kolejności, „Show status in new ticket form” (czy ten status ma być w ogóle do wyboru przy zakładaniu zgłoszenia?), „Requires comment in dialog” (wymuś uzasadnienie) i „System only” dla statusów, które może ustawiać tylko sam system.

Do czterech statusów pojawia się na zgłoszeniu jako przyciski pod „Change Status to:”. Wybierasz je w edytorze przełącznikiem „Set as primary status (max. 4)”. W ustawieniu fabrycznym są to In Progress, Waiting for User Response, Waiting for Service Provider Response i Resolved. Wszystkie pozostałe statusy są pod „More statuses”.

Wszystko, co pojawia się w zgłoszeniu jako lista wyboru, należy do Ciebie. Pod „Settings → General Settings” stoi karta „Drop-down lists” z sześcioma zakładkami: „Department”, „Position”, „Location”, „Role”, „Status” i „Priority”. Obsługa różni się w zależności od listy.

Pojedynczo: wpisz angielską nazwę w puste pole i kliknij przycisk obok. Nosi on nazwę listy, więc „+ Add location”, „+ Add department” i tak dalej. Wiersze poniżej to istniejące wpisy. W „Department”, „Position” i „Location” tam właśnie zmieniasz nazwę i potwierdzasz przyciskiem „Save” obok.

Do wielu wpisów naraz „Department”, „Position” i „Location” oferują też „Export JSON” i „Import JSON”. W świeżo zainstalowanym systemie pobierasz przyciskiem „Export JSON” pustą strukturę, wypełniasz ją i importujesz z powrotem. To nie jest droga do zmiany nazw, karta mówi to sama.

Niektóre wpisy noszą etykietę „Mandatory”. Należą do nich trzy role „Admin”, „Agent” i „Customer”, osiem statusów przychodzących z systemem oraz po jednym miejscu zastępczym na listach lokalizacji, stanowisk i działów („None selected or available”). Żadnego z nich nie da się usunąć: wiszą na nich uprawnienia i procesy, które inaczej stanęłyby bez słowa. Nazwy statusów da się mimo to zmienić w ich edytorze. Nazw ról i miejsc zastępczych zmienić się nie da. To, co jest dozwolone, zależy od listy. „Role” jest zablokowana: roli nie da się ani dodać, ani zmienić jej nazwy. W „Priority” dodajesz i usuwasz wpisy, ale nie ma pliku ani zmiany nazw. „Status” ma własny edytor i też nie ma pliku.

Na inne języki nie tłumaczysz tutaj, tylko za jednym razem na stronie tłumaczeń. Tutaj wystarczy nazwa angielska, bo to na niej zawieszą się później tłumaczenia.

Status to jedyny wpis z własnym edytorem, bo wisi na nim więcej niż nazwa. Ma własną kartę niżej.

Kategorie to to, co zgłaszający albo agent wybiera przy zakładaniu zgłoszenia, i to, według czego grupujesz potem swoje raporty. Każdy zespół ma własne: helpdesk porządkuje inaczej niż dział sieci, a żaden z nich nie widzi list drugiego.

Znajdziesz je pod „Settings” jako wpis „<nazwa zespołu> Categories”. W przykładzie zespół nazywa się „Helpdesk”, więc wpis brzmi „Helpdesk Categories”.

Strona ma trzy karty: „Main categories”, „Subcategories” i „Links”. Najszybszy początek: wpisz angielską nazwę w pole „EN (required)” i kliknij „+ New main category” albo „+ New subcategory”. Wszystko tłumaczysz później za jednym razem na stronie tłumaczeń, tutaj nie trzeba nic do tego przygotowywać.

Jeśli masz przed sobą wiele kategorii, wybierz drogę przez plik: „Export JSON” pobiera strukturę, a w świeżo zainstalowanym systemie plik jest pusty i pokazuje tylko układ. Wypełniasz go, ręcznie albo z pomocą sztucznej inteligencji, zapisujesz i wysyłasz z powrotem przez „Import JSON”. To nie jest droga do zmiany nazw: nazwę zmieniasz w polu danej kategorii i potwierdzasz przyciskiem „Save” obok, o czym mówi też sama strona.

Trzecia karta, „Links”, to miejsce właściwej pracy. Wybierz na górze kategorię główną, zaznacz pod spodem należące do niej podkategorie i zapisz przyciskiem „Save links”. Sztuczka polega na tym, że jedna podkategoria może wisieć przy kilku kategoriach głównych. Dzięki temu potrzebujesz „Malfunction” tylko raz i używasz jej ponownie przy drukarce, sieci, sali konferencyjnej i notebooku.

Od tej chwili kategorie są dostępne w zgłoszeniu. Usunięcie może się nie udać, dopóki zgłoszenia jeszcze korzystają z kategorii. Jest to zamierzone, inaczej stare zgłoszenia straciłyby swoją klasyfikację. Jeśli usuniesz powiązanie, zgłoszenia korzystające z tej pary nadal da się zapisać. Z powiązaniami sprawdzana jest tylko nowo wybrana kategoria.

Jeśli przekażesz zgłoszenie innemu zespołowi, jego klasyfikacja zostaje, nawet wtedy, gdy nowy zespół w ogóle nie ma tych kategorii. Stoi ona wtedy w polu razem ze swoim pochodzeniem, na przykład „Meeting-Room · from Helpdesk”, i jest wyszarzona: nowy zespół widzi, pod czym sprawa dotąd szła, ale sam takiego wpisu nadać nie może. Do przesortowania wybiera z własnej listy, a system chce wtedy kategorię główną i podkategorię razem.

Każde zgłoszenie niesie kanał. Stoi on w formularzu, a później na karcie „Actions” pod „How the request came in”, i odpowiada na pytanie, które w raportach szybko staje się ważne: czy praca przychodzi przez portal, czy przez telefon?

Wybrać możesz tylko to, co wie człowiek, a czego nie wie system: „Phone” i „Entered by an agent”. Dwie pozostałe wartości ustawia sam system. „Self-service”, gdy zgłaszający utworzył zgłoszenie w portalu, i „E-mail”, gdy wyrosło ono z przychodzącej wiadomości. Gdy zgłoszenie tworzy agent, formularz zaczyna od „Entered by an agent”.

Kanału nadanego przez system nikt nie może później zmienić. Pole mówi wtedy „Recorded by the system. It cannot be changed.” Inaczej pole straciłoby dokładnie to stwierdzenie, dla którego istnieje. W drugą stronę, w zgłoszeniu przyjętym przez telefon możesz nadal zmieniać wszystko inne.

Kanał może ustawić tylko agent albo administrator. Dla zgłaszającego byłoby to stwierdzenie o własnej sprawie, a raporty zależałyby od tego, czy wszyscy są uczciwi.

„E-mail” wymaga podłączonej skrzynki, która należy do edycji Professional. Trzy pozostałe kanały istnieją w obu edycjach.

Nad każdą listą zgłoszeń jest pole „Search tickets…”. Nie przeszukuje ono samych tytułów, tylko całą sprawę: tytuł, opis, nazwisko zgłaszającego, jego adres e-mail i numer telefonu, lokalizację, numer zgłoszenia referencyjnego, wszystkie komentarze i wartości tekstowe Twoich pól własnych.

Przykład to pokazuje: słowo „coffee” nie występuje w żadnym tytule, tylko w opisie jednego zgłoszenia, a i tak zostaje znalezione. Nie musisz więc pamiętać, jak zgłoszenie zostało zatytułowane. Wystarczy jedno słowo ze sprawy.

Wielkość liter nie ma znaczenia. Wyszukiwanie działa zawsze na liście, w której właśnie jesteś, i da się je łączyć z „Filter” obok. „Reset” czyści wyszukiwanie i filtry z powrotem. Lista zapamiętuje twoje filtry, osobno dla każdej listy zespołu. Nadal są ustawione, gdy wracasz ze zgłoszenia, odświeżasz stronę albo logujesz się na innym komputerze. Tekstu wyszukiwania lista nie zapamiętuje. Dla klientów jest ograniczenie, którego nie widać, a warto o nim wiedzieć: nie przeszukują komentarzy wewnętrznych. Inaczej mogliby z listy wyników wywnioskować, o czym rozmawiano wewnętrznie. Nie przeszukują też pól własnych ukrytych przed klientami.

Każdy sam składa swoją listę zgłoszeń. Służy do tego przycisk „Columns” obok „Filter”. Otwiera on okno „Choose columns”.

W oknie zaznaczasz każdą kolumnę, którą chcesz widzieć. Strzałki obok ustalają kolejność. „#” i „Title” są zawsze uwzględnione. Szerokość kolumny zmieniasz w samej liście, przeciągając krawędź jej nagłówka.

„Save” zapisuje Twój wybór przy Twoim koncie użytkownika. Dlatego obowiązuje on na każdym komputerze i zostaje po wylogowaniu. „Default columns” przywraca listę do ustawienia fabrycznego.

Gdy brakuje miejsca na wszystkie kolumny, jako pierwsze znikają te najbardziej po prawej. „#”, „Title” i „Status” zostają zawsze. Dlatego to, co dla Ciebie najważniejsze, przesuwasz do przodu.

W edycji Professional do wyboru są też Twoje pola własne. Pojawiają się w oknie pod własną nazwą, tutaj na przykład „Asset tag”.

Klienci mogą ustawić swoją listę w ten sam sposób, ale mają do wyboru mniej kolumn. „Team”, „Created by”, „Last activity”, „Status changed at”, „Deadline”, „Follow-up” i „Time” nie są dla nich dostępne. Pola, które ukryłeś przed klientami, również nie pojawiają się jako kolumna.

Na telefonie przycisk nie jest wyświetlany. Lista pokazuje tam kolumny, które się mieszczą.

Zgłoszenie oferuje do tego dwa przyciski obok siebie, a różnica jest wypisana pod nimi drobnym drukiem. „Involve another team”: odpowiedzialność zostaje przy Tobie, a drugi zespół pracuje obok w powiązanym zgłoszeniu. „Escalate to another team”: drugi zespół przejmuje sprawę.

Przy przekazaniu odpowiedzialność przechodzi dalej, a drugie zgłoszenie nie powstaje. Twój zespół zachowuje dostęp do odczytu i może dalej komentować, ale nie może już nic zmieniać. Dokładnie to mówi Ci okno, zanim potwierdzisz. Wybierasz w nim zespół docelowy i możesz dodać uzasadnienie.

Przy dołączeniu zespołu Twoje zgłoszenie zostaje w Twoich rękach i dostaje podzgłoszenie w drugim zespole. Twoje przechodzi na status „Waiting for other team”. Gdy drugi zespół zamknie swoje, Twoje wraca jako „Back from other team”. Nie musisz więc pytać, czy coś się tam wydarzyło. Załączniki podzgłoszenia są kopiowane do Twojego zgłoszenia z etykietą „Internal”, a klient ich nie widzi.

Co do klasyfikacji: kategorie przekazującego zespołu zostają na zgłoszeniu, nawet wtedy, gdy nowy zespół w ogóle ich nie ma. Pokazują się tam ze swoim pochodzeniem, wyszarzone. Dzięki temu nowy zespół widzi, pod czym sprawa dotąd szła, i w razie potrzeby przesortuje ją do własnej listy.

Przekazać zgłoszenie dalej może tylko ten, kto jest za nie w tej chwili odpowiedzialny. Wcześniejsza stacja nadal widzi sprawę, ale nie może przekazać jej drugi raz. Może komentować, ale nie może zabrać zgłoszenia z powrotem do siebie.

Na liście Twojego zespołu zgłoszenie pokazuje wtedy „Waiting for other team”, dopóki drugi zespół nad nim pracuje. Pole „Also show tickets this team handed over” jest fabrycznie zaznaczone, a wybór każdego użytkownika zostaje zapamiętany. Dla drugiego zespołu zgłoszenie zaczyna jako „Open”.

Kto przekazuje zgłoszenie, zostaje jego obserwatorem. Okno mówi o tym, zanim potwierdzisz. Jako obserwator dostajesz e-mail, gdy zmienia się status, zgłoszenie zostaje zamknięte albo ktoś dodaje komentarz. Jak każdy obserwator usuwasz się przyciskiem „Stop observing”.

Kiedy w Twoich zgłoszeniach brakuje jakiejś informacji, na przykład numeru inwentarzowego, końca gwarancji albo miejsca powstawania kosztów, dodajesz ją sam. Pod „Settings → Ticket Settings”, na dole, stoi karta „Custom fields”, a przycisk nazywa się „Add custom field”.

W oknie nadajesz nazwę i typ pola: „Text”, „Multiline text”, „Integer”, „Decimal”, „Date” albo „Yes / No”. Typ decyduje o tym, co da się wpisać. Pole daty nie przyjmie „w przyszłym tygodniu” i właśnie dlatego da się je potem policzyć w raporcie.

Pod „Scope” decydujesz, gdzie pole obowiązuje: „All teams (including new ones)” albo „Selected teams only”. Pierwszy wybór obejmuje też zespoły, których jeszcze nie ma. To ta różnica, którą zauważa się dopiero pół roku później.

Trzy przełączniki pod „Defaults” to „Mandatory by default”, „Hidden for customer by default” i „Not editable by customer by default”. Dotyczą pola tylko tak długo, jak w ustawieniach pól na tej samej stronie nie zapisano niczego dla tego pola. Gdy tylko ustawisz je tam, decydują ustawienia pól.

Przy zgłoszeniu pola własne stoją na własnej karcie „Additional information”, między opisem a komentarzami. Bez szablonu formularz pokazuje wszystkie pola własne zespołu. Jeśli przy zakładaniu zgłoszenia wybierzesz szablon, pokazuje on dokładnie te pola, które wymienia, i w swojej kolejności, czyli „tylko pola, których ta sprawa potrzebuje”.

Szablon może dodatkowo uczynić pole obowiązkowym. To, co administrator ukrył przed klientami, zostaje ukryte, nawet gdy szablon to pole wymienia. Pole obowiązkowe, którego szablon nie wymienia, nie jest odpytywane, więc ten wymóg nie dotyczy zgłoszeń utworzonych z tego szablonu.

Ile pól własnych może mieć zespół, ustawia się pod „Settings → General Settings” na karcie „Custom fields limit”. Pola pozbywasz się przyciskiem „Deactivate”: znika ono z formularza, ale jego wartości zostają na starych zgłoszeniach. Przełącznik „Show deactivated” przywraca je na listę.

Czasem ktoś powinien śledzić sprawę, nie pracując nad nią: kierownik zespołu przy delikatnej sprawie albo kolega, który przejmuje ją w przyszłym tygodniu. Do tego są obserwatorzy. Przy zgłoszeniu pole „Observers” stoi na karcie „Actions”, a przycisk nazywa się „Add observer”. Formularz „Create new ticket” ma to samo pole. Przy zgłoszeniu zmianę w tym polu zapisuje przycisk „Save” na karcie „Details”.

Wybrać można tylko agentów i administratorów zespołu, do którego należy zgłoszenie. Klient nie może być obserwatorem, bo dostawałby wtedy pocztę o pracy wewnętrznej.

Obserwator dostaje e-mail, gdy przy zgłoszeniu coś się dzieje: nowy komentarz, zmieniony status, nowe przypisanie, zmienione pola. Nie wychodzi on natychmiast, tylko zbiorczo: po ostatniej zmianie system czeka minutę i wysyła JEDNĄ wiadomość obejmującą wszystko, co się w tym czasie wydarzyło. Dzięki temu przerobienie zgłoszenia za jednym razem nie wywołuje siedmiu wiadomości. Jeśli w tym czasie przyjdzie kilka komentarzy, wszystkie są w wiadomości.

To, kto obserwuje, należy do historii: zmiana jest zapisywana jak każda inna, ze starym i nowym stanem.

Wpisywanie obserwatorów należy do Basic. Wiadomość do obserwatorów należy do Professional, bo potrzebuje wysyłki poczty. Bez niej obserwatorów da się wpisać, ale nic nie wychodzi. Obserwator może usunąć się sam przyciskiem „Stop observing”. Nie wymaga to prawa do zmiany zgłoszenia.

Obserwator dodaje się też automatycznie: kto przekazuje zgłoszenie przyciskiem „Escalate to another team”, zostaje obserwatorem. Dzięki temu wie, co drugi zespół z nim robi.

Gdy dwie osoby pracują nad tym samym zgłoszeniem w tym samym czasie, późniejszy zapis mógłby nadpisać wcześniejszy i nikt by tego nie zauważył. Dlatego zgłoszenie pokazuje, kto jeszcze ma je otwarte. Odrzuca też zapis, który opiera się na nieaktualnym stanie.

Komunikat stoi w nagłówku zgłoszenia. „Marco Rossi is viewing this ticket” oznacza, że Marco ma zgłoszenie otwarte. „Marco Rossi is actively editing this ticket” oznacza, że Marco ma w nim niezapisane dane. Może to być rozpoczęta odpowiedź, komentarz w trakcie zmiany, tytuł lub opis w trybie edycji, przypomnienie, pole własne albo wpis czasu. Liczą się też zmienione pola na kartach „Actions” i „Details”, dopóki nie zostały zapisane przyciskiem „Save”. Otwarte okno przy zgłoszeniu również się liczy. Są to okna „Involve another team?”, „Escalate to another team?”, „Close ticket”, „Resolve incident” i „Start a workflow”, a do tego okno komentarza do zmiany statusu. Po dwóch minutach bez wpisywania komunikat znowu pokazuje „viewing”, nawet jeśli szkic nadal tam jest.

Jeśli zgłoszenie ma otwarte kilku współpracowników, komunikat ich podsumowuje, na przykład „Marco Rossi and 2 more are viewing this ticket”. Wskaż komunikat, aby zobaczyć wszystkie nazwiska. Gdy tylko ktoś aktywnie edytuje, wiersz liczy już tylko osoby, które edytują. Siebie nie widzisz nigdy. Jeśli masz zgłoszenie otwarte w dwóch kartach przeglądarki, liczysz się raz. Jeśli zgłoszenie jest otwarte tylko w ukrytej karcie, po mniej więcej minucie znikasz z komunikatu innych.

Gdy współpracownik zapisze zmianę, komunikat brzmi „Marco Rossi changed this ticket”, a obok jest przycisk „Refresh”. Nowy komentarz od kogoś innego pokazuje „Marco Rossi added a comment”. Jeśli zmiany nie wprowadziła żadna osoba, na przykład reguła automatyzacji albo przychodzący e-mail, komunikat brzmi „This ticket was changed”. Komunikat zostaje, dopóki nie odświeżysz.

„Refresh” wczytuje aktualny stan zgłoszenia, na przykład status, przypisanie, pola i historię. Nie przeładowuje całej strony. Twoje niezapisane dane zostają. Rozpoczęta odpowiedź zostaje w polu odpowiedzi, a otwarty tytuł lub opis zachowuje Twój tekst. Jeśli zapisany tekst w międzyczasie się zmienił, pod polem pojawia się „The saved text has changed in the meantime.”. Jeśli wtedy zapiszesz, Twój tekst zastąpi zapisany. Przycisk „Refresh” w nagłówku zgłoszenia robi to samo.

Jeśli mimo to zapiszesz na nieaktualnym stanie, zapis zostanie odrzucony. Otwiera się okno „Ticket changed in the meantime”. Jeśli zmianę wprowadziła osoba, okno ją wymienia. Twoja zmiana nie została zapisana. Kliknij „Refresh”, sprawdź swoją zmianę względem aktualnego stanu i zapisz ponownie. Dotyczy to każdej zmiany samego zgłoszenia, na przykład statusu, przypisania, priorytetu, karty „Details” i pól własnych.

Komentarze nigdy nie są odrzucane. Dwie odpowiedzi się nie nadpisują. Obie trafiają do zgłoszenia. To samo dotyczy załączników i wpisów czasu. Działania zbiorcze na liście zgłoszeń i reguły automatyzacji także nie są sprawdzane względem stanu. Zmieniają zgłoszenie bezpośrednio. Kto ma je otwarte, widzi potem komunikat.

Klienci nic z tego nie widzą. Nie pojawiają się w komunikacie. Nie widzą też, kto pracuje nad ich zgłoszeniem.

To, kto ma zgłoszenie otwarte, jest przechowywane tylko w pamięci roboczej serwera. Mniej więcej minutę po tym, jak osoba opuściła zgłoszenie, wpis znika. Nic z tego nie trafia do logu. Zgłoszenie zapisuje, kto ostatni je zmienił. Ten wpis należy do eksportu danych tej osoby. Gdy osoba zostaje zanonimizowana, wpis jest usuwany.

Kanał pocztowy to jedna droga w dwie strony, a obie należą do siebie: przychodząca wiadomość zamienia się w zgłoszenie, Twoja odpowiedź wychodzi jako wiadomość, a odpowiedź zgłaszającego trafia jako komentarz do tego samego zgłoszenia, a nie do drugiego.

Dopasowanie nie odbywa się na wyczucie: odpowiedź trafia do istniejącego zgłoszenia tylko wtedy, gdy wiadomość niesie oznaczenie sprawy w temacie albo przynosi ze sobą nagłówki odpowiedzi programu pocztowego. Wiadomość bez jednego i drugiego zaczyna nową sprawę. Lepiej jedno zgłoszenie za dużo niż dwie niezwiązane sprawy scalone tylko dlatego, że temat przypadkiem pasował.

Wszystko do tego stoi pod „Settings → E-Mail Settings”. Górna karta, „SMTP settings”, to droga na zewnątrz: host, port, „Use SSL”, użytkownik i hasło, a do tego adres i nazwa nadawcy. Przyciskiem „Send test e-mail” wysyłasz sobie próbkę. Najpierw zapisz, potem testuj, jak mówi sama karta.

Karta „IMAP settings” to droga do środka: host, port, częstotliwość odpytywania i dwa foldery. Nazwy folderu nie musisz zgadywać: „Read from server” pobiera foldery, które naprawdę istnieją w Twojej skrzynce, a „Create on server” zakłada nowy. Pole przyjmuje wtedy ścieżkę, jakiej używa do tego Twój serwer pocztowy. Jeden serwer pisze „INBOX/Processed”, następny „INBOX.Processed”, a oba znaczą to samo.

„Processed folder” przyjmuje wiadomości, które system odkłada na bok: wiadomości od zablokowanych nadawców, wiadomości wygenerowane automatycznie i wiadomości, które obieg przenosi działaniem „Move to folder” bez własnego folderu. Zostaw je puste, a zostaną w skrzynce odbiorczej. Poniżej ustawiasz, kiedy działa sprzątanie („Hour”, „Minute”) i jak stara może być wiadomość („Retention (days)”). Inaczej skrzynka po cichu rośnie.

Skrzynki należą do zespołu, a nie do systemu: pod „Team mailboxes” każdy zespół wpisuje własny adres z hasłem. Ten adres jest jednocześnie nadawcą wiadomości tego zespołu, więc zgłaszający odpisuje w to samo miejsce, z którego poczta jest odbierana.

A teraz część, bez której nic z tego się nie dzieje: obieg. Sama skonfigurowana skrzynka nie robi zupełnie nic. Jeśli zespół nie ma włączonego obiegu, skrzynka nie jest nawet odpytywana. Żadnego zgłoszenia, żadnego potwierdzenia, wiadomości po prostu leżą. Automatyczna odpowiedź do Twoich klientów istnieje tylko tutaj i ustawiasz ją sam. Jest to zamierzone: system, który bez pytania pisze na każdy adres nadawcy, byłby gorszy niż taki, który milczy.

Pod „E-Mail workflows” wybierasz na górze zespół i tworzysz obieg przyciskiem „+ Add workflow”. Dostaje on nazwę (tylko dla Ciebie), przełącznik „Enabled” i dwa stwierdzenia o tym, kiedy obowiązuje: „Match” decyduje, czy wszystkie warunki muszą być spełnione („All conditions”), czy wystarczy jeden, a „Stop after match” kończy przebieg, gdy tylko ten obieg zadziałał. Obieg stojący niżej nie dochodzi wtedy do głosu. Kolejność zmieniasz strzałkami obok.

Pod „When?” stoi sam warunek. „Every e-mail in this mailbox” bierze każdą wiadomość, a „Only when subject or text contains” wymaga słowa w temacie albo w treści. „Advanced” pozwala to uściślić: wybierasz tam, na co system patrzy, czyli „Subject or body”, „Subject”, „Body”, „Sender (From)” albo „Recipient (To/Cc)”, i jak porównuje: „Contains”, „Equals” albo „Regex”. Tak oddzielisz na przykład zgłoszenia na wspólny adres od całej reszty.

Poniżej stoi pięć działań jako przełączniki. To one są właściwą treścią obiegu, bo co nie jest włączone, to się nie dzieje:

„Create or append ticket” zamienia wiadomość w zgłoszenie albo dopisuje ją jako komentarz do istniejącego, gdy oznaczenie jest w temacie. Bez tego działania wiadomość nigdy nie staje się sprawą.

„Set fields” ustawia priorytet, status, kategorię główną i podkategorię, zespół prowadzący i osobę przypisaną już przy zakładaniu zgłoszenia. Wszystko, co zostaje na „— Keep default —”, wygląda tak, jak wyglądałoby bez obiegu.

„Auto-reply” to potwierdzenie dla nadawcy. Przy wyłączonym przełączniku Twój klient nie dostanie potwierdzenia, choćby cała reszta była ustawiona wzorowo. Do nadawcy może pisać też „Send mail”, jak pokazuje następne działanie.

„Send mail” wysyła dodatkową wiadomość: albo do nadawcy przychodzącej poczty, albo do wybranych członków zespołu i stałych adresów. Ma własne „Send conditions”. Zostaw je puste, a wiadomość wychodzi przy każdym przebiegu tego obiegu.

„Move to folder” odkłada przetworzoną wiadomość do folderu. Zostaw pole puste, a obowiązuje ogólny „Processed folder” z ustawień IMAP powyżej.

Działanie „Auto-reply” w szczegółach: temat składasz z klocków. „Original subject {originalSubject}” przejmuje temat przychodzącej wiadomości, a „Ticket reference {ticketTag}” wstawia oznaczenie sprawy. Razem dają coś takiego jak „Printer problem [TICKET-99-a1b2c3]”.

Oznaczenie nie dopisuje się samo. Pojawia się tylko tam, gdzie postawisz {ticketTag}. {ticketId} wstawia tylko sam numer i system nie rozpoznaje po nim odpowiedzi. Bez oznaczenia w temacie odpowiedź zostanie mimo to przypisana, jeśli niesie nagłówki odpowiedzi do potwierdzenia. Nowym zgłoszeniem staje się tylko wiadomość bez jednego i drugiego.

Tekst pod spodem to Twoje potwierdzenie. Pisz je po angielsku: przechodzi ono przez ten sam eksport i import co każdy inny tekst i tylko tak da się je przetłumaczyć na pozostałe języki. Zostaw je puste, a system wyśle własną wiadomość domyślną. Tutaj dopuszczone są te same zmienne.

„Reply language” decyduje, w jakim języku wychodzą temat i tekst: „Standard English” bierze angielski, „Fixed language” wybrany przez Ciebie język, „Assigned agent's language” język przypisanego agenta, a „Team default language” język domyślny zespołu. Same tłumaczenia utrzymujesz na stronie języków.

Jedna rada, którą system wypisuje też nad kartą: wszystko, co należy do jednej sprawy, należy do JEDNEGO obiegu. Tylko działania w tym samym obiegu znają właśnie utworzone zgłoszenie. Dlatego potwierdzenie może podać jego numer, a działanie z drugiego obiegu już nie.

Cały kanał pocztowy, do środka i na zewnątrz, należy do edycji Professional. W Basic system ani nie wysyła, ani nie odbiera poczty. Zgłoszenia powstają tam przez portal, telefon i agenta.