ticketing rendszer

Projektek általános

Sziasztok!

Szeretnénk bevezetni egy ticketing rendszert, ami valahogy így működik:
- ügyfél weboldalon nyit egy ticketet
- ez bekerül a rendszerbe, kap egy azonosítót, valaki felkapja, vagy escalálódik egy idő után.
- lehet az esethez csatolni fájlokat, megjegyzéseket, ...
- email-integráció: ügyfél kap státuszüzeneteket, ...
+ a létrejött esethez további infókat csatolni email-ben is lehet (ügyfél elküld egy levelet ami tartalmaz case ID van pl. a tárgy mezőben).

Ez az utolsó tűnik olyannak, amit (egyelőre) nem találok az OTRS-nél. Létezik ilyen készen? Valakinek van ötlete, hoyg mivel próbálkozzunk?
Ahogy az eddigi fórumokat néztem, a ticket-kezelő rendszerek közül elsőként az OTRS és a Mantis az, amit érdemes alaposabban megnézni.

Kösz, üdv.

  • 30542 megtekintés

( sfeher v | 2010. 01. 27., sze – 12:01 )

Hello,

Az OTRS-t használjuk produktívan több, mint két éve. Abszolút jól működik.
A webes felületét nem használjuk, de nem valami nagy meló beizzítani.
(A userek meg alapból lusták. E-mailt még csak-csak írnak, de egy webes formot kitölteni.. Ahhh.)
Nálunk egy Oracle 10g van alatta, userek LDAP-ból authentikálnak.

CPanel áll rendelkezésemre, ott is sima felhasználóként. Így korlátozottak a lehetőségeim.
Ezt találtam a cPanel felületén, mint lehetőség:
"Perl Module Installer
Perl modules are collections of functions that allow you to perform tasks in Perl. You will need to install a Perl module before you can use it inside a Perl program."
Illetve van "SSH key", gondolom mégis tudom használni az ssh-t. Viszont gondolom nem root-ként értelmez, ezért nem tudok akármit telepíteni.

( valaki123 | 2010. 01. 27., sze – 12:48 )

Még ránézhetsz a Trac illetve Opengoo nevű dologra is. A Trac és a Mantis inkább a fejlesztők számára kényelmesek.
Az otrs inkább adható ki ügyfeleknek használatra, bár azt is tudni kell használni. Az ügyfelek inkább telefonálni szeretnek többségében.

( gyorik v | 2010. 01. 27., sze – 13:11 )

Már sokat említettek az előttem szólók. Mi Request Trackert használunk céges szinten. Teljesen elégedett vagyok vele.

Igazabol nem teljesen ertem, hogy hogyan hasznaljak, de ok maguknak viszik fel (jobbara?) a dolgokat, ticketeket.
Van ket user, mint kiderult azokra panaszkodott csak, bar az allitasuk szerint ez nem igy van.
A lenyeg, hogy annak a 2 usernek az email cimet megvaltoztattam a rendszerben egy masikra es utana mukodott. Igy volt, h a kecske is megmaradt, meg a kaposzta is jollakott.
Mint kesobb kiderult a fentiek alapjan, mind2 cim szerepel ebben az opcioban, igy gondolom eleg lett volna, ha ezt egyszeruen uresre allitom, mivel amugy email fogadasra egyebkent sem hasznaljak a rendszert.
Az szamomra nem vilagos teljesen, hogy miert szerepeltek ezek a userek ebben az opcioban automatikusan, mivel valoszinuleg vhol meg el van szabva vhol a rendszer melyebben is. Annyira nem foglalkoztatott a dolog.

tompos

( agolon | 2010. 01. 27., sze – 15:00 )

bukmark
__________________________________
2e845cb4c3a5b5bd6508455b1739a8a2

( Sempi | 2010. 01. 30., szo – 18:45 )

Egy nem szorosan a témához tartozó kérdés:

Milyen módszerekkel lehet a felhasználókat rávenni, hogy telefon vagy email helyett inkább weben ticketet nyissanak?

Minden alkalommal elmondod, hogy "Legközelebb weben légyszi" és lassan rászoknak?

Vagy minden alkalommal te magad töltöd ki az űrlapot és nem változik semmi?

Köszi

PHPAdmin - Egyedi felületek készítése

pl. ez van a támogatási szerződésben mint elsődleges bejelentési felület. Ha nem ezt használják, akkor nem a meghatározott folyamat szerint járnak el, és az SLA sem indul el ... :)
Ha meg felhívnak kritikus esetben, akkor vagy tudatosítod ezt, vagy Te töltöd ki, de úgy, hogy amíg töltöd, addig ő se rakhassa le a telefont.
Nyilván csak a hibajavításhoz szükséges infókat célszerű megkövetelni, illetve azokat, ami alapján ellenőrizhető az, hogy egyáltalán az adott eszközre/rendszerre van-e support.

Mi OTRS-ben emailen keresztul vesszuk fel a ticketeket automatikusan. Inkabb arra nehez ravenni a usereket neha, hogy arra valaszoljanak, ne pedig kuldjenek egy mas subjectes email-t, es nyissanak uj ticketet - mert aztan en meg kezzel szerkeszthetem ossze oket :). OTRS-t amugy szeretik nalunk az ugyfelek nekik csak emailt kell kuldeni, ha esetleg telefonon keresnek akkor lehet ugyis felvenni jegyet, utana emailben ertesiteni oket a jegyek allapotarol. A jegyeket webes feluleten bejelentkezve megnezhetik, leellenorizhetik.

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

ISO-s munkautasításokban ez van, csak azon keresztül fogadunk el kérést, illetve hiba bejelentést (cégen belül).
Tartani kell oktatást, amiben kiemeled a rendszer előnyeit, ami nektek, illetve a felhasználóknak előny, pl.:
- nyomon követhető lesz
- lehet tudni, hogy ki foglalkozik/foglalkozott vele
- hol tart.

Mert mi van, ha:
- beteg lesz a kolléga,
- nincs rögzítve és elfelejti,
stb.

Szóval próbálni hatni az értelműkre.
A végső érv: CSAK :D

Persze még sokáig próbálkozni fognak, de lassan csökken :)

Webappz - http://sys-admin.hu/

"Milyen módszerekkel lehet a felhasználókat rávenni, hogy telefon vagy email helyett inkább weben ticketet nyissanak?"

Ki kell kommunikalni. Jol. Az egyes departmentek vezetoinek, hogy telefonon nem all modotokban requesteket fogadni. Nem biztonsagos, nem azonosithato a user etc.

Ha nem megy, akkor a managementtel le kell szervezni, hogy joval dragabb legyen egy (mondjuk "emergency", "severity 1", "ohhshit!") telefonon erkezett request kezelese, mint a webes.

Ehhez persze a webes rendszernek 100%-osnak kell lennie. Nem lehet lassu, nem lehetnek benne nyilvanvalo bugok.

Vegszukseg eseten a telefon rendszer megreformalasa jelentheti a kiutat. A dept. kap egy, azaz egy darab telefonszamot, amit vilagvege eseten fel lehet hivni. Mindenki mas telefonjarol csak kimeno hivasokat lehet kezdemenyezni.

Ahhh, megint bilibe log a kezem ....

Olyat nem lehet, es felelos vezeto nem is engedhet meg ilyesmit. Es folyamatosan kell kommunikalni. Jon mailba egy ticket: legyszi kuldd ujra a ticket@ceg.hu cimre. Jon telefonon: oke, de legyszi kuldd el emailben a ticket@ceg.hu cimre is a problemadat. Egy ido utan atszoknak, de olyat sosem szabad csinalni, hogy nem reagalunk az ugyfelkeresre semmit. Valamit muszaj.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Sehogy. Ha valaki telefonálni akar akkor az telefonálni fog. Legrosszabb esetben odasétál. Nálunk épp azon gondolkoznak, hogy csak online ticket only-ra kéne átállni, de mikor mondtam, hogy nézzék át a ticketeket, az incidensek 90+%hoz be kell lépni távolról, vagy élőben kell tájékoztatni, hogy lássa pontosan mit csinált rosszul/máshogy, tehát eleve gyorsabb ha hívás közben megoldom és nem kell napokig pingpongozni a userrel. A szolgáltatás/kéréseknek meg eleve is 90+%ban emailből jönnek be (ennek kb fele a mailboxba másik fele meg a ticketing rendszerbe emailben és automatán generálódik, egyenlőre még nincs self service portal élesben, akik meg tesztelik azok szeretik, mert velük eggyutt fejlesztjük) a maradék meg incidensnek indul de végül kérés (is) lesz belőle. Van egykét user aki imád mindent emailben küldözgetni ticketnek utána meg hisztizik, hogy napokig/hetekig húzódik egy 3 perces problémamegoldás mert ha hívom sosincs ott vagy épp “fontosabb” dolga van, bezzeg ha email irogatás helyett felhívott volna akkor már el is felejtette volna, hogy baja volt...

pro:
kinéz valahogy

kontra:
bugos email processzálás
magyar karakterekkel elszáll
utf8 ismeretlen számára

Ez volt az első ilyen rendszerek egyike, amibe belefutottam annó, majd 2 napig próbáltam az itt-ott megjelenő bugokat betömni, de mivel egy hiba kijavításakor 2 új került elő, a 3. napra kidobtam a francba. Azóta otrs.

( secretx v | 2010. 01. 30., szo – 20:04 )

GLPI-t nézd meg, az pont ezt tudja (meg millió mást) nagyob profi.

( p.zoltan | 2010. 01. 30., szo – 20:33 )

Hű, jut eszembe!

Olyan rendszert ismertek, ami ticket és crm is egyben? Egy ilyen rendszer az álmom!

( freeoli v | 2010. 02. 01., h – 16:40 )

OCS Inventory + GLPI ? Együtt igen jó lehet, de még nem tudtam kipróbálni.

( pillerk | 2010. 05. 03., h – 16:09 )

Én Joomla 1.5 CMS (OpenLdap hitelesítés) + Billets komponensel oldottam meg. Kétnyelven, szépen megy, tud mail->ticket konverziót is. Pedig mit kerestem az ingyeneseket! Lehet nem tudtak OpenLdap hitelesítést? Már rég volt, nem emléxem.

( freeoli v | 2010. 09. 14., k – 08:51 )

Ki mit használ?

eticket? osticket? otrs?

Valoban van ott egy ilyen mezo. Nalam ugyanaz van benne, mint ami a username.
Ugy latom, van itt egyebkent egy ID mezo is, de nem ertem, mire hasznalhatja.
En arrol beszelek, hogy ha az ldapban a tompos usernek 123456 az UID-ja, akkor legyen a jira-ban is az es az alapjan azonositsa a usert mindehol.

Ezt en ugy tudom, nem tudja.

tompos

Mert nem is kell tudnia. Az LDAP-ban a DN szamit, meg esetleg talan a CN. Az uid az pont irrelevans, tekintve, hogy az amugy is csak egy extension, ami akar nem is letezhet, nem kotelezo attributum (oke, a posixAccount-nal az, de pl. a person-nal nem).
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Hol, a jira-ban? Nincs Vagy nem ertelek.
A konkret problema nem az, h nem kezeli, hanem az ebbol eredo anomalia.

John Smith jon a ceghez, megkapja a john.smith felhasznalot, belep a jira-ba, ott a jira szinten ezzel azonositja. Innentol kezdve meg1 john.smith usernevvel rendelkezo felhasznalo nem lehet a halozatban, mert a jira miatt kotott. Hiaba lepett le, utotte el a villamos, vagy lett vele akarmi, lett egy uj felhasznalni masik uid-dal, john.smith felhasznalonevel, a jira azzal fogja azonositani. Pl. frankon odaadja neki a ticketeket, bejegyzeseket, stb.

tompos

A tortenet akkor lesz igazan vicces , ha egy masik alkalmazas ugy van kitalalava, hogy nem lehet usert torolni, csak deactivalni.
Egy megint masik alkalmaz meg hibakat dobal, ha egy user eltunkt az AD bol es biz. lepeseknel hivatkoznak ra.
Egy harmadik , meg ha atnevezed usert es az e-mail cim nem valtozik, megprobalja importalni, de az egyezo email cim meg tiltott..

Igazabol, ha az AD-ben sem torlunk usert es utana meg sorszamot kapnak a userek, akkor szinte minden alkalmazas boldog lesz.
User atnevezeset meg nem kell engedni. Felolem a hazasagot is betilthatjak :)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Elsőre jó. Szép. Gyors. Letisztult színek. Vannak hozzá pluginek, némelyik free, némelyik fizetős.
Aztán elkezded használni.
Bejövő emailek... kimenő emailek... issue-k... html formátumú emailből betöltött comment szétbassza a template-et...
Közben az userek jönnek, hogy: "Lehessen keresni az issuehoz csatolt állományokban is!" Erre egyetlen (és az is free) plugin van készen, ami működik is, bár 4 éve nem nyúltak hozzá... a jira meg Lucene-t használ, de nem dependencyként, külön jarból, hanem be van húzva a forrása. És módosítva. Mint minden más is.
Ergo mindig, milliméter pontossággal tudnod kell, hogy hol, milyen verziójú jar-t kell letöltened a plugin mellé, hogy illeszkedjen a forrásfába behúzottal. Gyakorlatilag egy igazi, replaced által gyakran fikázott foss projekt, csak még fizethetsz is a supportért, ami a hp openview support portal hatékonyságával vetekszik.
Pl. screenshot készítő applet, aminek a neve hardcodeolva van egy classban (ami annyibol all, hogy hardcode-oltan document.write-ol egy statikus html-t, soronkent egy, ami jquery-n at letrehoz egy applet htmlelementet es a statikusan kirakott valtozokbol betolti az appletet), mint xyapplet.jar, DE az adott könyvtárban jelen levő egyetlen fájl neve 3x olyan hosszú. Szimplán más néven dobták oda a jart és fostak rá, hogy megnézzék, megy-e. Ja, support szerint a kliens java verziója nem jó. Kénytelen voltam egy hardlinket csinálni rá.
Vagy backup: egy zip. benne egy xml. az xml-ben minden. MINDEN. Gyakorlatilag egy 1 évet futott jira, amin van 8ezer user és napi 400 interakció, egy darab, 3GB-os xml-t köp ki backupként, bezippelve. Már ha nem timeoutol az ezt készítő servlet. Importálás is webes felületen át. Igen, tölts fel egy 600 megás zipet.
Létrehozol egy projektet. Később mindent megváltoztathatsz, kivéve a project key-t. Az egyetlen dolgot amihez semmi sem kötődik. Meg szinte mindent megadhatsz kreáláskor, kivéve a metaadatokat, ahhoz nem csak hogy be kell fejezned a kreálást, még admin módból is ki kell lépned, hogy lásd azt a menüpontot!

Többet nem mondok, mert azt nem lenne illendő.

turul16 majd jól beszól, de nekem halálosan faszom kivan a jirával.
Gyere vissza!

Nem pont ide illik, de erről a ClearCase/ClearCase Remote Client ugrik be. Elsőre az is egy használható eszköznek tűnik, de ha dolgozni kell vele, akkor jönnek ki a bajai. Egységesen, szívből gyűlöli itt mindenki a cégnél. Aktívan tud akadályozni a munkában.

* Igen, tudom, van egy csomó hely, ahol jól működik, de nálunk nem.
--
http://www.open-st.eu

Oruj, hogy nem a tobbi ott levo ticketing rendszer melysegeibe kell bele meni.
Es oruj, hogy a tobbi kodjat nem latod, mar a viselkedesuk is sok nekem :)

A jira sokat fejlodott, te mar egy sokkal letisztultabb valtozatot latsz. Nehol valoban nem atgondolt az API, de mintha latnam a fenyt az alagut vegen. Kitartas.

Nem veletlen mondtam, hogy bugzilla az elejen. :)

Nem rosz a jira, csak arra es ugy kene hasznalni amire valo, ahogy valo.

Az attachment plugin migrilasat sajnos nem veletlen felejtettem ki, megmondtam hogy hogyan kene egy ujat implementalni, mert az hivatalosan is hallott plugin es csak sok verzioval ezelotti jiraval kompatibilis. Nem is volna nagy munka..
Mar kezdetekkor szoltam, hogy baj lesz , de ...
Masik lucane jar-t nem volna szabad hasznalnod (duplicalni), meg warningokat is dobal, nem veletlen szoltam az elejen.

Sok plugin letezik a jirahoz, de nem volna szabad hasznalni mindet, sokat mar az alkalmazott technologiak miatt kidobnek mielott magat plugint lattam volna.

Az alap jira nem rosz, es meg igy is masodik legjobbnak tartom.

A zip export csak 4G-ig megy, utana jobb ha kikapcsolod az osszes automatikus xml backupot.

Nem megyek, itt bugzilla van es nem kell meggyoznom senkit, hogy legalabb jirat hasznaljunk :)

Sot a legkiralyabb kernelrol sem kell vitatkozni :)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( hrgy84 | 2012. 10. 10., sze – 01:46 )

Az utolso ponthoz hasonlot nezegettem en is, csak nekem forditott a gondom, nekem van egy szimpla adatforrasom, es a customerhez kellene megjeleniteni (pl. hogy milyen csomagja van). Ahogy neztem az OTRS forrasat, meg az API doksikat, elvben van lehetoseg kulonfele panelkeket csinalni, amibe az adatot perl kodbol tolod, es csinalsz hozza egy DTL sablont, amiben meg az adatokat jelenited meg. Engem mondjuk rettenetesen zavar a Perl benne...

Nincs valami olyan kepessegu ticketing rendszer, mint az OTRS, csak PHP-ben? Mondjuk az nem baj, ha free... Irto jo lenne egy csomo mindent piszkalni benne, de a Perl tudasom eleg korlatozott, foleg ami az OOP-t illeti.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem vagyok ellene, valamennyire tudok is perlezni, csak ez a modern, OOP perl ez teljesen kimaradt nekem, es egyaltalan nem latom at, hogy mit es hova, idom meg nincs rendesen megtanulni.

Ezert keresek olyan ticketing rendszert, ami olyan mint az OTRS, csak nem perlben van irva. Java/Ruby/PHP barmi jo, a Perl az pont nem annyira. A JIRA sajnos nagyon nem erre valo, mas hostolhatot meg nem talaltam ertelmeset. Meg WHMCS lenne jo, csak az meg ahhoz kepest draga, hogy nekunk igazabol csak a ticketing modul kell belole, meg az ugyfelnyilvantarto, a tobbihez nagyon sok munka lenne illesztest irni.

De lehet az lesz a vege, hogy van egy jo SOAP szerverem benne, es irok ele valami frontendet.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( freeoli v | 2012. 10. 10., sze – 17:22 )

Az otrs ezt mind tudja, csak idő mire rájössz, hol és hogy konfigurald. Javaslom, mert a későbbiekben könnyen lehet vele extra igényeket is kielégíteni.

( palotti | 2012. 10. 10., sze – 18:17 )

Nálunk a megoldás otrs: kapcsolatfelvételi ürlap, subject adott típus alapján kitöltve, otrs subject alapján teszi várólistára a ticketeket. Hibás subject esetén meg autoreply: használd a kapcsolatfelvételi űrlapot
--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...

( WG | 2012. 10. 11., cs – 00:57 )

Hasonlót keresek én is, ezért nem nyitok újabb topicot, ha nem haragszotok.
Nekem egy szerviz forgalmának nyilvántartására kellene egy ticketing rendszer.
Különböző Ügyfelek különböző készülékeket hoznak javítani.
A készülékek kapnak egy egyedi azonosítót (sorszámozott vonalkódos matrica), Ügyfél egy autoincrement ID-t kap.
Egy készülék több Üf.-hez is tartozhat (pl. eladja másnak), ill. több készülék is tartozhat egy Üf.-hez.
Előzményeket, statisztikákat szeretnék látni, javítási folyamatról haladásáról, fejleményekről publikus infókkal e-mailben tájékoztatni Üf.-et, belső megjegyzések, fájlok tárolhatóak, kereshetőek legyenek, ilyesmi.
Elkészültekről automatikus értesítést küldjön, a javításra várók listázhatóak legyenek, stb.
Az OTRS demóját nézegettem, de az szvsz nem pont erre való.

Ha CRM-el, webáruházzal is összeköthető, az lenne a legjobb. :)
Van ötletetek, mit használjak erre a célra? 

openSUSE 12.2, vagy ami éppen jön.

( kiuka | 2019. 11. 26., k – 06:53 )

felhozom kicsit a topicot, hátha változott azóta a helyzet. olyan ticketing rendszert keresnék ami lehetőség szerint az alábbiakat tudja:

  • fel tudom vinni benne az ügyfeleimet (és ahhoz kötni a ticketeket amik bejönnek - egy user tartozhat több ügyfélhez is)
  • normális parsol maileket
  • egyszerűen lehet szabályokat kezelni benne (feladó, tárgy, szövegre - mi történjen az emailekkel)

zendesk jó lenne, viszont az árazása nem szimpi, ha akarom kezelni az ügyfeleket akkor a 8usd/hó helyett 50usd/hó/agent amit már soknak tartok. kayakoban nem megoldható, hogy egy user több ügyfélhez tartozzon.

nyitott vagyok self hosted megoldásra is, valaki ötlet?

( FoREE | 2019. 11. 26., k – 12:50 )

nezd meg a helpspot -ot. helpspot.com Nem tudom, tudja-e ugy az ügyfélkezelést ahogy szeretnéd. 3 userig (agent) ingyen használhatod

( kiskakas | 2020. 01. 29., sze – 08:42 )

Sziasztok,

magam is felhoznám kicsit a topicot, hasonlóan egy olyan ticketing rendszert keresek, minimális, pár 100 ügyfélszámra, ami eset bejelentésre használható, bejelentő kap értesítést és online weben tudja követni a ticket statuszát. Fontos,h a rendszer tudjon magyarul, illetve valamilyen szinten "belső" oldalon lehessen költséget rendelni egy adott feladathoz.  Van valakinek bevált, használatban lévő tippje?