Results 1 to 21 of 21
  1. #1
    Join Date
    Jul 2005
    Posts
    598

    Building ticketing system

    Hi,

    I would like to build a support ticketing system. What would i need to take into considerations:-
    1) Language - Must be open source
    2) Structure
    3) functions
    4) Flow
    5) DB - MySQL

    Point 2-4 is most important. Hope could get more information regarding this.

    Any input is appreciated....Thanks....

  2. #2
    Join Date
    Jul 2005
    Posts
    598
    Anybody could help?

  3. #3
    Join Date
    Jun 2003
    Location
    California
    Posts
    51
    I have put together a small ticket system of my own for personal use. It is using PHP, mySQL and runs on Apache.

    I found that I needed to be able to give tickets a status (closed, open, pending, urgent) so I created a field in the mySQL database for this.

    If you have multiple people using this system to take tickets you will probably need to setup a privledge system as well to give these people a level. Maybe you have a level 2 call and you want to only show it to people who have that level of privledge to take the ticket.

    I don't know if that helps at all. Once you get the basics into your design it will probably be easier to come up with more ideas and get some pretty good features into your system.

  4. #4
    Join Date
    Dec 2004
    Location
    New York City, NY, USA
    Posts
    735
    If you want the absolute fastest way to program something like this, I'd recommend one of these object-database relationship systems like Ruby on Rails (for Ruby) or Django (for Python).

    That is if you wanted to use either of these languages. Good luck trying to (quickly) program stuff like this in PHP or Perl. The people who sell commercial systems for ticket management written in PHP and Perl can get away with their high prices for a reason...

  5. #5
    Join Date
    Jul 2005
    Posts
    598
    Thanks a lot, Shroder! Any futher information is much appreciated....
    I'm not developing a commercial ticketing system for now. Just need one for my own and clients.

  6. #6
    Join Date
    May 2001
    Location
    Prince Edward Island
    Posts
    964
    Why build a better mouse trap --

    there areplenty of Opensource Ticketing systems available to you.

    www.oneorzero.com comes to mind ..

    http://hotscripts.com/search/5386572.html
    [url]I got nothing/url]

    For clarity's sake, don't use "<ip address of hostname>" use the ACTUAL 32-bit numeric IP address of the machine.

  7. #7
    Join Date
    May 2001
    Location
    Prince Edward Island
    Posts
    964
    Why build a better mouse trap --

    there are plenty of Opensource Ticketing systems available to you.

    www.oneorzero.com comes to mind ..

    http://hotscripts.com/search/5386572.html
    [url]I got nothing/url]

    For clarity's sake, don't use "<ip address of hostname>" use the ACTUAL 32-bit numeric IP address of the machine.

  8. #8
    Join Date
    Dec 2004
    Location
    New York City, NY, USA
    Posts
    735
    Pre-made scripts can be (very) difficult to integrate. It usually isn't worth it either unless the pre-made script does something amazing you couldn't do on your own.

  9. #9
    Join Date
    Jul 2005
    Posts
    598
    MikeM, i need to integrate the ticketing system with my some other systems. That is why i prefer to build in house rather than using 3rd party. Therefore, i need to gather more information to work out my flow and structure

  10. #10
    Join Date
    Jun 2004
    Location
    Bay Area -USA
    Posts
    1,738
    The number 1 thing to think about is: user-friendly.

    Make it easy to use and make it look NICE.

    Perhaps pay a designer to come up with some designs and buttons that will make your program able to compete.
    <<< Please see Forum Guidelines for signature setup. >>>

  11. #11
    Originally posted by MikeM
    Why build a better mouse trap --

    there are plenty of Opensource Ticketing systems available to you.

    www.oneorzero.com comes to mind ..

    http://hotscripts.com/search/5386572.html
    Having a opensource ticketing system makes your company look unprofessional - since anyone can simply install one. Integrating it into your design/system would probably take the same time and effort as making one entirally from scratch yourself - if not more.

  12. #12
    Join Date
    Jul 2005
    Posts
    598
    I need more advise on the functionality. What the important functions that should not be miss out?C'mon, i'm trying to stucture out the flow now. Once i got the proper flow then only i will need to worry about the design. No big deal for the design.

    Personally, i do not much experience with support ticketing system. Therefore i am seeking some professional advise over here.

    What function should the user(client) have?
    What function should be admin have?Let say i have 5 support staffs (consider the admin group).

  13. #13
    Join Date
    Jun 2004
    Location
    Bay Area -USA
    Posts
    1,738
    User should be able to EASILY start a new ticket.
    User should be able to not fill in all fields if they dont want to
    User should be able to select where they want thier message to go
    User should be given other options if they dont want to start a trouble ticket.
    User should be able to click on support and then create ticket
    <<< Please see Forum Guidelines for signature setup. >>>

  14. #14
    Join Date
    Jun 2005
    Posts
    73
    depending on the size of your organization. You may need to add ticket groups or queues. That way all of one kind of ticket could go to a support group instead of one person.

    Ability to change ownership of a ticket on the customer and management side.

    public and private note section of ticket

    email ticket update on close/update

    the list is pretty long depending on what you are wanting to do.

  15. #15
    Join Date
    Jul 2005
    Posts
    598
    Anybody have links to any website explaining how support ticket suppose to work?

    I have 3 departments over here which are sales, order and support. Each of the department have more than 2 staffs. Which would be the essential method to start a ticket?Web based form, direct from user CP and from other email system (Hotmail, Yahoo, Netscape, Outlook and etc).

    Let me assume this, once the client start the support ticket. He should receive an autoreply stating the status of the support ticket. What should be included in the autoreply?

    How about tracking?What should be included?

  16. #16
    Join Date
    Jun 2005
    Posts
    73
    i would think the autoreply should have:

    Your company contact info
    A ticket id for reference
    A link to check ticket status
    Brief status message (thanks for opening a ticket, your ticket has been updated, your ticket has been closed)

    I would not put any ticket details other than the ticket number in the email. Customers will put CC numbers and other sensative info in the ticket.

    As far as how the system works, it will depend some on your organization needs and developement time constraints.

  17. #17
    Join Date
    Jul 2005
    Posts
    598
    Is it good to include in the autoreply:-
    1)How many tickets ahead
    2)Time to response
    3)Estimated time of response

    This is a hosting company support ticketing system. Any good example to test?

  18. #18
    Join Date
    Dec 2004
    Location
    New York City, NY, USA
    Posts
    735
    I would put anything about response unless you actually *know* the response times (most of the time you don't).

    It may be useful to look at one of the more heavy duty issue systems (like Bugzilla) and take features you think you need from that.

    Things that come to my mind:
    • add multiple contacts for a ticket: multiple people may care about a problem, such as an OP's client
    • respond to a ticket and view past responses in a message-board like fashion (viewable to everyone who can view the ticket)
    • add internal "comments" that are not viewable by the OP but by staff (useful for internal notes such as "this guy is a trouble maker"; "see <some file> on <super secret machine only staff know about> for more information)

  19. #19
    Join Date
    Jul 2005
    Posts
    598
    Originally posted by tamasrepus
    I would put anything about response unless you actually *know* the response times (most of the time you don't).

    It may be useful to look at one of the more heavy duty issue systems (like Bugzilla) and take features you think you need from that.

    Things that come to my mind:
    • add multiple contacts for a ticket: multiple people may care about a problem, such as an OP's client
    • respond to a ticket and view past responses in a message-board like fashion (viewable to everyone who can view the ticket)
    • add internal "comments" that are not viewable by the OP but by staff (useful for internal notes such as "this guy is a trouble maker"; "see <some file> on <super secret machine only staff know about> for more information)
    Very good point you have there, thanks!!By the way, what is OP?

  20. #20
    Join Date
    Dec 2004
    Location
    New York City, NY, USA
    Posts
    735
    OP = "original poster," or in this case the person who originally submitted the ticket

  21. #21
    Join Date
    May 2004
    Location
    Lansing, MI, USA
    Posts
    1,548
    Ok, I have actually built quite a few ticket systems, so let me cover some important areas that I have found to be very helpful.

    1st: OOP - Object Oriented Programming

    This will, potentially, greatly simplify any later expansion of your system at a later date. It will also allow you to use common methods across objects to keep things consistant and managable.

    A great example of this, I will pull from our own systems.

    Every data-bound object (database backed logical group) has 4 methods that always work identically.

    load($id), add(), update(), and delete().

    2nd: Role-based permissions

    Permission levels are, honestly, antiquated and arbitrary. Use a role-based permissions system so you have fine-grained control over who can do what. This also simpilifies access checking, as you just define PERMS_ADMIN_USERS as your bitwise placeholder (say, 8... so it would be the 4th permission listed), then for your access checking, you just do:
    Code:
    if (PERMS_ADMIN_USER & $_SESSION['user']->permissions)
    and you have very simple checking, which is very straight forward.

    3rd: Security

    Why list this here and not first? Because if you take the first two things into consideration, security becomes very simple. We handle all pages though a template system, and that template system needs to be instantized, so we extended the class to automatically setup things we needed for basic pages, and further extended the class to enable easy security.

    A simple way to show this is:
    Code:
    $page = new AuthedPortalPage(PERMS_ADMIN_USER);
    This gives the advantage that you only write your security checking code in one place, and it can be used consistantly throughout your project. It also enables you to do some other fun things as well, which you will think about as you get further into your project, I am sure.

    The other point of making sure your security is simple to implement on pages, is that you MUST make sure the user is authenticated and check permission levels BEFORE any business logic is done.

    4th: Status/State/Priority

    I noticed someone earlier grouped 'status' with 'priority' which would, in my opinion, not be the best layout. A ticket's status (new, pending, RESOLVED, etc...) is in no way related to it's priority (low, medium, high), and this would hinder later reporting opertunities (such as average time from new to resolved.) The other thought would be to add an 'action' value to detemine things such as 'currently being worked on' 'awaiting staff reply' 'awaiting customer reply' as they are all 'pending' but 'pending' in general is a nice cover-all *status* where as the former items are more the 'reason' for the pending status.

    5th: Extent of information stored

    Do you just need to know the client's email? Do you want their Name, contact information? We had one company who did on-site location work who needed to track individual locations under a single client, and have the locations themselves be tied to a specific local represntiave, as well as the company having an over-all managing rep. Consider the scope of the data storage and usability you require, as this could be very determinative of how helpful your system actually is.

    6th: Other misc pieces

    It is always a good idea to have some way to include attachments, per client or ticket notes, and emailing of responses. You may also want to look at extending your client side interface to include multiple login management and such, depending on your situation.

    In short, it can be a very simple task, though time consuming, to do things correctly in a way that you can expand, but make sure that you do spend enough time planning things out.
    Jacob - WebOnce Technologies - 30 Day 100% Satisfaction Guarantee - Over 5 Years Going Strong!
    Website Hosting, PHP4&5, RoR, MySQL 5.0, Reseller Hosting, Development, and Designs
    Powered By JAM - Professional Website Development - PHP, MySQL, JavaScript, AJAX - Projects Small & Large

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •