Użytkownik A.L.E.C napisał:
Klient zgłasza problem. Operator BOKu rejestruje zgłoszenie (inaczej ticket). Ticket zawiera nast. informacje: id - identyfikator id kolejki - o tym niżej temat - skrót problemu zgłaszający - nazwisko i imię/nazwa klienta (jesli zgłaszający jest klientem sieci należałoby zapisać jego ID w dodatkowym polu 'userid', jeśli zgłaszający jest spoza sieci (powiedzmy przyszły klient) to dostaje userid=0) data/czas zgłoszenia stan (status) - na jakim etapie jest zgłoszenie właściciel (owner) - to chyba przypisany do ticketa admin/albo ten co rejestrował, a może zrobić dwa pola na tego kto przyjął i komu przypisano? (przypisywać można później) description - opcjonalnie krótki opis zgłoszenia (opcjonalnie, bo treść zgłoszenia będzie zapisana w wiadomości od zgłaszającego, patrz koniec posta).
Każde zgłoszenie może mieć następujący status (stan): Nowy - w momencie zgłoszenia Przypisany - po przypisaniu do admina Rozwiązany (Zamknięty?) - wiadomo Zwrócony - (?) klient nie potwierdza rozwiązania problemu Usunięty - gry zgłoszenie przyszło mailem i okazało się, że to np. spam.
W dalszej kolejności możnaby dodać pole 'priorytet'.
Zgłoszenia są pogrupowane wg kategorii i w ten sposób tworzą kolejki (queues). Kolejki (kategorie) definiuje się samodzielnie. Dane dla kolejki to id, nazwa, e-mail (coś jeszcze? docelowo definiowanie uprawnień dla operatorów do kolejek). E-mail to adres na który przychodzą zgłoszenia mailowe (jak zrobimy backend do tego :) i z którego będą wychodziły odpowiedzi do klientów.
Teraz historia zgłoszenia. Żeby zgłoszenie powstało, ktoś musiał nas powiadomić, zatem na samym początku tworzymy wiadomość (co automatycznie tworzy ticket), następnie wszystkie podjęte kroki, korespondencja z klientem to są wiadomości. Jakie pola będą w wiadomości to można zobaczyć w doc/lms.mysql (tabela rtmessages).
-- Pozdrawiam Aleksander 'A.L.E.C' Machniak http://alec.pl gg-2275252 Lan Management System Developer http://lms.rulez.pl
nie wiem, czy to jest zawarte w powyzszych, czy moze jest sprzeczne (na razie zbyt ogolny opis) ale kiedys uczestniczylem w powstawaniu podobnego systemu (niestety zrodelek nie moge udostepnic - nie sa moje) i prztdala by sie jeszcze mozliwosc przesyslania zgloszenia miedzy adminam'i (uzytkownikami LMS'a) przyklad z zycia: 1. problem przyjmuje np. telefonicznie pani BOK1 stwierdza, ze to trzeba podeslac do admina A1 (bo jest w drugim pokoju) przesyla. 2. admin A1 czyta, ale nie ma dostepu do akurat tego serwera tego zeby to spradzic. przesyla do admin aglownego A2 3. admin A2 sprawdza i okazuje sie, ze to problem sprzetu i odsyla to do serwisanta 4. serwisant robi, albo nie (mialem pecha i serwisant byl len), jak juz zrobi to odsyla do _osoby mogacej zamknac zgloszenie_ (np: BOK1)
* kazdy z userow ma liste usterek/zadan przeznaczonych tylko dla niego * do kazdego wlasnego zadania moze dodac swoj komentarz (np: "to nie ja sie tym zajmuje", "serwer dziala - sprawdzic, czy user ma w domu prad", "zrobione", itp) i odeslac dalej (do kogos innego w tym do bok'u) * kazdy user widzi to co dodali inni - widzi co juz bylo robione * dodatkowo bok musi miec podglad w status zlecenia bedacego "w toku" - na podstawie jakiegos-tam-numeru: * usterki/zgoszenia obsluguje w dowolnej kolejnosci - zakladamy dobra wole pracownikow - widzi priorytety i czasy przyjecia zgloszenia
w ty czasie, klient jest upierdliwy i wydzwania, albo przychodzi do BOK1 i krzyczy. gdyby BOK1 miala taki system opieprzala by, wspolnie z szefem, S1, a tak przewaznie mi (A1) sie dostawalo, albo A2 :-)
nie moge podeslac kodu, ani nie pamietam dokladnie jak to dzialalo(dziala ?) bo nie ja go pisalem, ale moge w niego zerknac i podpowiadac/dopisac czesc funkcjonalnosci i opisac zastosowane rozwiazania i podejscie do tematu
program jest dosyc prosty (java - ok 5 dni pracy) dzialal wysmienicie i naprawdze pomogl nam zorganizowac prace
Jaqb