Help Center Live Community
April 24, 2014, 12:25:45 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1]   Go Down
  Print  
Author Topic: Trouble Ticket features.  (Read 18781 times)
HCL Admin
Administrator
HCL Superstar
*****
Offline Offline

Posts: 882


WWW
« on: June 23, 2007, 06:02:48 PM »

For those using trouble tickets, what are the features that are important to you.  There are reasons why I'm not interested in supporting the eTicket module, all of which are my own.  However, HCL stands to gain a lot by having trouble tickets.  By knowing what features are important to you, I can either find a replacement, a set of donor code that would be translated into a full fledged module, or integrated (such as eTicket was).  Of those options, the last is the one I like the least.


<personal opinion>

I don't hate eTicket, nor do I think poorly of it's developers, they have come a long way with an old bloated TT system.  It's great stand alone.  In fact there are a LOT of great standalone systems.  However the integration system is really a hack.  It's not clean code, and trying to maintain a HUGE TT system just isn't going to happen by me.  Too much of the current osTicket/eTicket system requires near rewrites of chunks of code.  Not to mention the varied programming standards, and you have a real mess.

Should the eTicket module be continued, absolutely, but not by myself.  I simply can't do all of the work, HCL is a labor of love, it's something I really enjoy working on.

At this point I think it would be quicker to write fresh code or modify a more simple TT system then try to get eTicket even close to stable.  This week we've had issues of all variety, things that initial testing did not discover.
</personal opinion>

My gut feeling is that most folks want a SIMPLE to use, basic trouble ticket system.  Nothing glamorous or fancy, but collect the information and provide it to operators and support staff.
Logged

how may I help you today?
tommyjohn
Not too much to say...
*
Offline Offline

Posts: 36


« Reply #1 on: June 23, 2007, 07:16:45 PM »

  • Create New Ticket interface - viewer / operator
  • Auto Ticket numbers
  • Departments - admin
  • Operators; assignable to Department - admin
  • Full email integration; pull tickets from a mailbox into the interface and send emails out from the interface - operator
  • Assign ticekts to an operator - operator(config) / admin(config)
  • Assign Status to Ticket - operator(config) / admin(config)
  • canned email responses - operator
  • create canned email responses - admin
  • Ticket status checker- public (would be great if the login could be pulled from a referring form or Querystring) - viewer / operator / admin
  • Ticket Status Log (include status changes, answers (via email), notes added // all entries need user, datetimestamp, detail) - operator / admin (edit log entries)
  • Ticket Flags - operator(config) / admin(config)
  • Ticket filters (by status, date added, email address, title, operator, etc.) - viewer / operator
  • Ticket system banning - admin (stop spam)
  • Transfer ticket between operators - operators(config) / admin
  • Alerts (change of status (sent to client), or transfer emails (sent to receiving operator))
  • Securty code integration for New Ticket - public
  • Link Chat logs in HCL to a ticket for reference (i.e. new ticket created based on chat) - operator

Advanced Request:
  • Add a "Your Tickets" (tickets assigned to the operator)list to the main page (links to the ticket record) of HCL below the notes section - operator

Added:
  • Auto email sent to viewers when ticket is opened. Email should contain a link to a page to view ticket details. The link should also be customizable based on the install area of HCL & TT.

Edit: Clarified placement of features between viewer/operator/admin; items marked with "(config)" are items that can have their account level set (operator/admin). All config settings will then reside in the admin panel.
« Last Edit: June 24, 2007, 06:19:38 PM by tommyjohn » Logged
HCL Admin
Administrator
HCL Superstar
*****
Offline Offline

Posts: 882


WWW
« Reply #2 on: June 23, 2007, 07:41:48 PM »

I'm gonna go through this line by line. Smiley

Create New Ticket interface - public + admin
Actually, it would use the template system, so that it can be themed to the individual site

Auto Ticket numbers
This is easy, simply use the mysql id number

Departments - admin
Um, HCL already has these...  We can reference an HCL dept.

Operators; assignable to Department - admin
Ditto, already handled by HCL.

Full email integration; pull tickets from a mailbox into the interface and send emails out from the interface - admin
Shouldn't be too difficult.  This is mostly pretty standard PHP code.

Assign ticekts to an operator - admin
Ok, and maybe have it optional for operators to assume unclaimed tickets.

Assign Status to Ticket - admin
again, some people want ops to be able to do this, so maybe a config switch.

canned email responses - admin
Makes sense

Ticket status checker- public (would be great if the login could be pulled from a referring form or Querystring)
Or maybe just a link that is sent with the first report of the problem, let them click the link and look up the problem.  Use a random MD5 hash to use for authentication, then they don't need a "login"

Ticket Status Log - admin (include status changes, answers (via email), notes added // all entries need user, datetimestamp, detail)
Again, makes sense for an admin overview.

Ticket Flags - admin
What purpose are you thinking about?

Ticket filters - admin (by status, date added, email address, title, operator, etc.)
Hmm, I can see this being needed by ops as well, if you have a lot of tickets.  It would be more of a sort and filter.

Ticket system banning - admin (stop spam)
Initially yes, but once 2.2.x comes around, it will have built in banning, if their spamming the tickets, you probably don't want to live help them.

Transfer ticket between operators - admin
Again, maybe a switch to allow ops, some will want it, some won't.

Alerts (change of status (sent to client), or transfer emails (sent to receiving operator))
Yes, very important.  Thinking that when the new windows/linux native app is done, allow this to interface in as well.

On the advanced idea, that will be possible in 2.2.x, and maybe in 2.1.x (future versions).

All in all great ideas!
Logged

how may I help you today?
tommyjohn
Not too much to say...
*
Offline Offline

Posts: 36


« Reply #3 on: June 23, 2007, 07:51:44 PM »

I'm gonna go through this line by line. Smiley

Create New Ticket interface - public + admin
Actually, it would use the template system, so that it can be themed to the individual site

Poor wording on my part. I didnt mean to recode a New Ticket Interface. I meant that an external "Add/Create New Ticket" interface be available for use on a website without having to login. This would be the same (or similar) interface an op would use to add a new ticket on a client/viewer behalf.

To clarify my tagging of public / admin, I was meaning public = clients/viewers /visitors to the site, and admin=Area accessible by internal employees, not necessarily features available only to employees with Admin rights.
Logged
HCL Admin
Administrator
HCL Superstar
*****
Offline Offline

Posts: 882


WWW
« Reply #4 on: June 24, 2007, 03:38:44 PM »

Ah, ok, that makes much more sense.  Generally, I use the term visitors of people surfing the site, operators for staff without configuration access, and admin for the boss... Smiley

I'm using your list as sort of a road map.  After the e-mail I received from someone over at eTicket, I'm not going to even try to get it running.  I've actually downloaded phpticket, which is a minimalist TT system, and and basically rewriting it.  The basic reason for this is that I can cheat and re-use some of his code for now, and rewrite the rest in version .2 or something.

I should note, it won't be phpticket when it's released, in fact it can't live on it's own, the first thing I did was remove all authentication and now am removing all straight HTML.  Most of the classes are being redone, and nearly all the configuration is as well.  There is no need to replicate what is already in HCL.
Logged

how may I help you today?
tommyjohn
Not too much to say...
*
Offline Offline

Posts: 36


« Reply #5 on: June 24, 2007, 05:56:45 PM »


Ticket status checker- public (would be great if the login could be pulled from a referring form or Querystring)
Or maybe just a link that is sent with the first report of the problem, let them click the link and look up the problem.  Use a random MD5 hash to use for authentication, then they don't need a "login"
Let me explain how I would like this to work, and I am sure many others will as well. We use HCL, and eventually will add the Trouble Ticket system to an already built Client Center. There are a dozen or so links to the applications and services my company provides (account info, billing, etc.). The client has to login to this Client Center with credentials we supply when their account is setup. So what I would like here is a link that goes to the login page for TT, and if passed via Query String, logs them into TT without any input. This will then display any tickets that are open under their account and also allow them to open/add a new ticket.

Your suggestion of sending an email with a link and reference to the ticket # is another feature that should be included. For some companies the link will need to be customizable if TT is not fully exposed to the internet (i.e. its part of a client center: http://www.domain.com/clientcenter/hcl/tt/).

The ability to integrate TT with a prebuilt client area will be a request I am sure will come up again, by others.

Ticket Flags - admin
What purpose are you thinking about?
Many purposes, a VIP client, an issue that is very very important to the company, really anything that make the ticket more important to be handled or reviewed. This would be something that should be set by ops or admin. (config on/off for ops).


Ticket system banning - admin (stop spam)
Initially yes, but once 2.2.x comes around, it will have built in banning, if their spamming the tickets, you probably don't want to live help them.
Will 2.2.x have the ability to block/ban when they send in email, or the help@domain.com email is getting spam? Sure, this could be handled at the email server, but to include it in HCL would be ideal.
« Last Edit: June 24, 2007, 06:14:07 PM by tommyjohn » Logged
HCL Admin
Administrator
HCL Superstar
*****
Offline Offline

Posts: 882


WWW
« Reply #6 on: June 24, 2007, 07:59:49 PM »

Auth:

Look at the eTicket module, in the /hcl directory is an easy way to share logins.  Additionally it wouldn't be hard to add an integration module to replicate logins into HCL/TT

Flag:

Ah, so a status flag, that makes a lot of sense.  At some point it would be good to make the flags and their related status' admin definable.

Block/Ban:

This part of 2.2.x is still in the "dreaming up ideas" stage.  So it would be easy to add.  I'd like to have it setup so there is a user definable message that could be displayed/e-mailed.  That way the person knows why they are banned/blocked.
Logged

how may I help you today?
tommyjohn
Not too much to say...
*
Offline Offline

Posts: 36


« Reply #7 on: June 24, 2007, 09:25:27 PM »


Flag:

Ah, so a status flag, that makes a lot of sense.  At some point it would be good to make the flags and their related status' admin definable.


So we are on the same page, the Ticket Flag (Immediate Attention, VIP, Rush etc.) would be in addition to the Ticket Status (new, open, answered, closed).
 
You are right too, the Flags would be great if they could be defined by an admin.
Logged
Bob Paxton
Not too much to say...
*
Offline Offline

Posts: 1


WWW
« Reply #8 on: January 09, 2008, 07:40:56 PM »

Hi MLZ

Newly registered to your new forum and site.  I have been using HCL for several years now and am still on version 1.2.6 so I guess it is about time for me to upgrade I guess.  I am just not sure if all my information will pull over to the newer version or not.

The simplicity of the HCL program is what has worked for me and I use HCL for customers to log in and either ask for sales assistance (sales department) where they enter in what it is that they are looking for and I get back to them with an e-mailed quotation but use HCL to track and "open and close" the request ticket so that both the customer and myself can see what is open and closed and we have archiving to go back and look at all the items.  The second department I use is labelled (repairs) where the customers enter in specifics as to the Make, Model, Serial #, what accessories they are sending in, what the problem is with the unit, their own Lotus Notes Tracking #, and radio user's name and department, etc.  The third department I use is termed (system down) and is for major problems that require an immediate service call to the customer's site.  Here they describe the problem and location and any other pertinent information that we need in dispatching a technician.

I link the departments to specific operators so that (sales) requests go to specific sales operators, (repairs) go to specific repair operators, and (system down) requests go to technicians who can handle the call.

I like HCL as it automatically e-mails us or the customer upon entry of a ticket or any update to the ticket and also provides the convenient link to go right to the ticket.

One thing that would be nice to add would be a feature that I believe was in oz ticket where you could create specific line item entry templates (text boxes, drop down boxes, radio buttons, etc) and save them and then you could create a specific 'home' or entry page per customer.  Having these line items then go to the MySQL database would help in finding a specific unit in the 'open' or 'closed' tickets and would also assist in cleaning up and structuring the entry of a ticket by the customer especially when more than 1 person is entering tickets.

Along the same path as templating the entry screen would be the capability of somehow customizing the departments such that there could be special departments that are only accessible to specific customers or so that a (sales) only customer would not see the (repairs) and (system down) or other departments.

Thanks..
Logged
alivesite
Not too much to say...
*
Offline Offline

Posts: 1


WWW
« Reply #9 on: January 04, 2010, 03:23:11 PM »

really nice,thanks for this feature.
Logged

hxxp: articleleader. info
Pages: [1]   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.8 | SMF © 2006-2008, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Page created in 0.174 seconds with 18 queries.

Google visited last this page April 20, 2014, 10:36:28 AM