TicketDesk – Design Philosophies Explained

It has been just over a year since I introduced TicketDesk over at CodePlex. While it hasn’t taken the world by storm or anything, it did generate a lot more interest than I would have expected. There are several companies using TicketDesk in production environments, and there have been a few thousand downloads from other people that may be using it too.

While TicketDesk isn’t generating the kind of download numbers that I’d want to base a software startup on, for an open source project it is what you might call “wildly successful”.

If there was a major failure on my part with bringing TicketDesk to the public, it would be that I didn’t do a good job explaining the ideas behind the overall design. So let me take a stab at explaining the philosophy behind TicketDesk.

The general idea behind TicketDesk was to take my 15 years or so of experience, much of it spent being frustrated by help desk issue trackers, and use that experience to design a different kind of help desk system; one that avoids those problems.

And believe me, I have a very long list of complaints with help desk systems!

I suppose the best way to explain it is to discuss the fundamental design ideas, then illustrate how TicketDesk implements them.

TicketDesk is an issue tracker for help desks… and that is all:

The help desk at most organizations will have many considerations aside from issue tracking. There are internal rank structures, chains of command, political issues, business practices, and financial considerations of all kinds. Unfortunately, the help desk is deeply involved in all of these things.

The mission of TicketDesk is to allow the help desk keep track of issues, and that is all it does.

  • TicketDesk does not attempt to understand your org chart.
  • It doesn’t recognize user rank, status, or departmental affiliations.
  • It doesn’t act as a time tracker.
  • It doesn’t do billing.
  • It doesn’t do project management.
  • It doesn’t manage your inventory.
  • It doesn’t handle your business process.
  • It doesn’t do inner-departmental accounting.
  • And it absolutely does NOT care about your internal politics.

TicketDesk is made for internal help desks:

TicketDesk was designed exclusively for use by help desks supporting users within the same organization. It assumes there is a high level of trust between all participants.

TicketDesk can be used in other environments, and there are plans for future versions to better enable external user scenarios.

You should carefully evaluate TicketDesk’s features before attempting to use it in a customer-facing capacity. Also, you may find the features insufficient for organizations that provide contracted support to users external to their own organization.

Have as few data fields as possible for any given ticket:

This the most basic design idea behind TicketDesk.

In most help desk systems there are just too many fields, and few of them turn out to be useful. During planning, management is hyped-up about the advantages all those fields will bring, but it doesn’t take long for the staff to learn that the free-text description field is the only reliable source of information (and even that is a dubious assumption).

So I’ve spent a lot of time thinking about the various fields common to similar systems.

There are many reasons why different fields fail, but it boils down to just three overall trends:

  1. The fields may not relate to the user’s specific problem. For example, Questions like “what OS are you using” aren’t useful when the user is reporting a problem with a printer or phone.
  2. The end user is incapable of answering some questions. It isn’t their fault, they just aren’t IT professionals. They just don’t know the answers, especially to the more technical questions like “what is the printer model number?”.
  3. The end user is not qualified to answer some questions. This isn’t a lack of skill, but just a lack of sufficient information. The classic example here is the priority field, to which end users cannot provide a meaningful answer. They don’t know how their problem stacks up in relation to other issues; so only IT can provide a useful answer here.

After exploring the problems I came to the conclusion that they just cannot be solved by software. It is also unlikely that training, threat, or corporate policy would help much either. The only viable solution is for the system to expect poor input from users, embrace that fact, then just concentrate on helping the humans work around the limitations on a case by case basis.

TicketDesk follows a couple of important philosophies:

  1. Avoid asking any question where the user cannot be expected to answer with 100% accuracy no matter what kind of problem they are reporting.
  2. Avoid asking questions that don’t apply to nearly every possible situation that could be reported.

Thus, TicketDesk asks as little from the user as possible. It expects that the only useful field will be the free-text details field. Other fields exist, but are general in nature, optional, or expected to be answered by the staff rather than the end-user.

Tickets should evolve as a natural conversation between the help desk and the end-user:

As discussed above, TicketDesk does not attempt gather a lot of detailed and quantifiable information up front. Instead it expects that help desk staff will have to ask for additional information.

Tickets are designed to be an ongoing two-way conversation with the users by borrowing heavily from web 2.0 and social networking concepts.

The activity area of tickets acts as a forum-style discussion board combined with an activity and history log. Every action that can be performed with a ticket solicits additional comments that also become part of the ongoing conversation.

The notifications system ensures that both staff and users remain informed as the ticket progresses toward completion. And TicketDesk makes it very simple to perform actions and add comments, which should encourages the staff to actually make frequent updates to the ticket as they work through the issues.

The result should be a constant stream of information flowing between the user who submitted the ticket and the help desk staffer assigned to deal with it. Either party, as well as interested 3rd parties, can jump in at any time to add to the conversation.

Avoid Workflow & Routing Hell:

This is one of the more controversial of TicketDesk’s design philosophies.

Most help desk systems have customizable and dynamic workflows and rule-based routing. This allows for a lot of control over how a ticket moves through the system.

There is no inherent “problem” with this kind of system in my experience. I have had the misfortune of working with system where the workflow customizations were insanely over-engineered to create horridly inefficient routes with many unnecessary steps. But when used wisely, workflow features don’t necessarily present a problem.

Avoiding advanced workflow and routing is a design philosophy based mostly on technical considerations. Workflow and routing are nightmares to code and maintain, especially for a small development team with limited resources. But on the other hand, the advantages to having workflow and routing features is very small. Other than making managers happy by having the system act as a policy-cop, there isn’t much added value to the system by including custom workflows.

Additionally, TicketDesk is designed to collect a very minimal set of fields, and doesn’t expect end users to necessarily fill them in with useful information, so in TicketDesk there just aren’t many fields that could participate in automated routing and advanced workflows.

Instead I designed TicketDesk to use a basic state-based workflow that should be simple and valid in just about any organization. While simple, it is also unobtrusive and frictionless for the most part.

There have been some requests for workflow options that require only simple workflow customization options or a limited set of pre-defined optional rules. I plan to explore those ideas for inclusion in future versions of TicketDesk, but I have no plans to introduce a full-featured workflow customization or rule-based routing engine.

Allow organic categorization:

Most issue tracker systems provide the end user with several cascading category lists, with context sensitive sub-categories. The options in sub-cats adjust according to previous selections to produce a granular categorization system. As described before though, this just doesn’t work that well in actual practice. Users don’t get these selections right very often, and over time the list of selections themselves tend to become outdated, and are always incomplete.

By omitting detailed categorization in TicketDesk, the searchability of tickets is slightly degraded, and it can be more difficult to locate related tickets.

To give TicketDesk decent searchability without reproducing all the problems of traditional over-categorization; TicketDesk includes a web 2.0 style tagging mechanism. This allows users and staff to organically add keywords to tickets as they desire.

Anyone can tag, but it is only really successful as a substitute for categorization if the help desk staff take it on themselves to ensure that tickets are tagged well before being resolved. This takes some discipline and effort, but the up-side is that it produces a degree of searchability that can far exceed traditional categorization mechanisms. And best of all, there isn’t a lot of administrative overhead to tagging since the system evolves and adapts all by itself over time.

Tagging is optional though, and many shops (mine included) choose not to make much use of it. That’s OK since TicketDesk doesn’t rely on tagging for any core functionality, and a lack of tagging doesn’t degrade the system’s ability to perform the primary mission.

Email Notifications should not spam users:

This is a major problem in a lot of different software systems. There is a need to keep users informed of changes in a timely manner, but if you send notifications too frequently the system will overwhelm users.

When this happens people tend to just ignore all the notifications, and so important messages start to get lost in the noise.

To combat this problem, TicketDesk puts an enormous amount of effort into reducing the number of notifications sent to ensure that the notification that are sent always contain useful new information.

Here are the basic rules behind the email system:

  • Do not notify users about changes that they have made themselves. You know what you just did right?
  • Wait a few minutes before sending a notification to see if additional events involving the same ticket happen. If so, wait until changes slow down a bit, then consolidate the events into a single message.
  • Convey all of the information about the ticket in the message so users do not have to log in to see what is going on.
  • Attempt to guarantee delivery by supporting an intelligent re-try mechanism.

Depsite the fact that this system took a while to get implemented, it has proven good at keeping down the number of messages sent as well as eliminating unnecessary notifications.

The actual format of the notification message is still a little rough around the edges, but that will be worked out in future releases.

TicketDesk will not provide performance reporting:

This is also a controversial philosophy, but one that is absolutely essential to the success of the system.

TicketDesk will not implement any reports or data collection features to assist management in measuring employee performance, or that could be used in this way.

Anytime the issue tracker becomes a tool by which management measures employee performance, the system ceases to have value. Instead it becomes an enemy of the users. Users will then manipulate the data in the system to protect themselves and inflate their performance numbers. Anything that would make them “look bad” will be deliberately obscured or omitted from the system.

Researchers call this “measurement dysfunction”, and it is a well established and thoroughly vetted reality. Despite that though, managers around the world still insist on attempting to automate the measurement of employee performance… which is ironic. If they were successful, then what would be the point in having managers?

Your help desk is probably staffed by very smart people. People that love figuring things out, and whose job is to be very good at solving puzzles. How long will take them to learn how to game the system?

Even if you have some honest staffers that don’t manipulate the system… measuring performance will only punish the few honest users, while rewarding users that manipulate data to their advantage.

The purpose of TicketDesk is to facilitate honest and open communication between users and help desk. If the system is used to gather performance metrics then it cannot provide honesty nor openness, and the result is a system filled with meaningless information that is of little use to anyone.

I first learned about this issue from Joel Spolsky, creator of the popular FogBugz bug tracking system, but have witnessed this same phenomenon in nearly every help desk environment I’ve ever worked with. .

You can read Joel’s take on the issue yourself if you wish; he explains it better than I can.

Now… there are ways to do useful reporting in a way that doesn’t lead to management dysfunction. But it takes very careful design where you deliberately create reports that cannot be used to show individual or group performance metrics. That is a slippery slope, and I have not yet had time to do the design for such reports yet.

I do have plans to add some reporting in the future, but the reporting will be carefully designed to prevent such abuses.

TicketDesk 1.2 Stable Release

I’ve just published the stable release for TicketDesk 1.2 over on CodePlex!

This release took much longer than I’d hoped, but it does significantly improve on the previous release in nearly every functioinal area.

TicketDesk is an open source help desk issue tracking system. Unlike many similar products, TicketDesk strives for simplicity for both end users and help desk staff.   

New in this release:

  • New Ticket Viewer/Editor
    • Rich Text Editor for comments and ticket details
    • Improved Work-Flow for resolved, closed, and more-info tickets
    • Smoother UI
  • Improved TicketCenter
    • Multi-Column sorting
    • Better Filtering
    • Remembers view settings between sessions
    • Improved performance
  • Improved Attachment Handling
    • Upload multiple attachments
    • Upload attachments for new tickets
    • Attachment Description field
    • Ability to add comments with uploading attachments
  • New Email Notification System
    • History and Activity stored in DB
    • Intelligently cuts spam when multiple updates occur rapidly
    • Automatic retry for failed deliveries
  • Customizable RSS feeds
  • Advanced error logging with ELMAH

TicketDesk 1.2 Alpha Release

I’m please to announce that the next major release of the TicketDesk Help Desk Issue Tracking and Support System is on track for a Mid-February release.

I’ve already put an alpha version of the new release on CodePlex while I wrap up a few loose ends and finish up some cross-browser testing..

TicketDesk is an open source help desk issue tracking system. Unlike many similar products, TicketDesk strives for simplicity for both end users and help desk staff.  

TicketDesk 1.2 is a significant upgrade over the 1.1 release from last spring with numerous improvements in nearly every part of the system. For a list of the major new features please visit the What’s New section over at CodePlex.

TicketDesk 1.1 released

I’ve released an update  for the TicketDesk  issue tracking application over at CodePlex.

TicketDesk is an issue tracking system for IT Help Desks and support centers.

TicketDesk is efficient and designed to do only one thing, facilitate communications between help desk staff and end users. The overriding design goal is to be as simple and frictionless for both users and help desk staff as is possible.

TicketDesk is an asp.net web application written in C# targeting the .net 3.5 framework. It includes a simple database with support for SQL 2005 Express or SQL Server 2005. It can leverage SQL server for membership and role based security or integrate with windows authentication and Active Directory groups.

TicketDesk 1.1 contains some bug-fixes and a few important new features. You can learn more about TicketDesk at the TicketDesk project home at CodePlex, or you can read my previous post about TicketDesk’s origins.

TicketDesk – Open Source Help Desk Issue Tracker

For the last several weeks I’ve been spending most of my spare time working on a new application, and now I’m proud to announce…


TicketDesk is an open source issue tracker. It is a fast, simple, and nearly effortless tool that will assist Help Desks in servicing the needs of their users.

TicketDesk is written in C# on the .NET 3.5 framework. It can be hosted on any IIS 6 or IIS 7 web server with SQL Server 2005 (or SQL 2005 Express). And it makes use of Microsoft’s Ajax and LINQ to SQL technologies.


At my employer’s office we use a help-desk application called Census by MetaQuest software. Census, to put it mildly, is total crap. It is slow, cumbersome, complex, and annoying to use. It is also a nightmare to install, keep running, and administer.

When searching for alternatives I came to realize that nearly all of the help desk applications on the market suffer from the same kinds of problems.

They all have these complex customizable workflows you have to manage, complex permission systems, and so many fields that even the dedicated IT staff end up ignoring most of them. They Also tend to be hard to install, difficult to configure, and tedious to maintain.

Then you have the endless categorization… what’s the priority, what’s the severity, what’s the impact on the users, what kind of problem is it, what kind of user reported the problem, what operating system is installed on the system with the problem, what gender was your first pet dog….


The end-user’s don’t want complexity.

Requiring end-users to fill out complex forms with all kinds of technical jargon just scares them… which means they don’t fill out tickets until their small problems have become really big ones.

The help desk doesn’t want complexity either.

Sure, they are used to complexity, but your help desk is overworked, under-staffed, and are under a lot of pressure to fix everything RIGHT NOW!

It doesn’t matter if it is a 5 person mom-and-pop shop or a fortune 50 company, your help desk is always under the gun and they just don’t have time to fill out a “detailed” report with 500 fields just to say “I rebooted the server and everything is fine now”. 

The marketing for most help-desk applications will go on about searchability, knowledge-bases, and how your help desk tickets can be used to build a database of problems and solutions which will improve efficiency by leveraging past experiences. Some even promise to turn your issue tracker into a customer-facing self-help support web site (if you aren’t ready to vomit now, you haven’t worked on a real help desk before).

That’s a great idea, and it does well the sales meetings with upper management.

But it also total bullshit!

It overlooks the obvious fact that a help-desk issue tracking system is exactly the wrong source for that kind of knowledge sharing. End users describe their problems as best as they can, which means they describe their problems badly at best. The help desk staff will do an equally poor job explaining what they did and how they fixed the problem.

That’s just how it is.

No amount of policy, management directives, training, or threats will change the fact that data in your issue tracking system will be hard to search, sketchy about the details, and will totally fail to make a useful knowledge base.

To be successful, your ticket tracking system needs to be efficient, fast, and easy to use. It needs to allow for quick and frictionless communications between the users and IT staff. And most importantly, the system must NOT get in the way. It must be nearly effortless to use and so simple that even a Mac user could figure it out.

TicketDesk is born:

TicketDesk wasn’t “planned”. It was just something I decided to in my spare time. I needed to write it in only a couple of weeks using no more than 4 hours a day of my time.

It needed to support the end-users and IT staff, but without any unnecessary administration or maintenance.

So the general idea was to implement the simplest ticket tracking system as possible. It would have a very simple non-customizable workflow, as few data fields as possible, and be easy to setup, maintain, and administer.

The other goal was to use as little code as possible. So TicketDesk would have to leverage everything the .net 3.5 framework could muster that might reduce complexity and improve my productivity.

In formulating the basic idea, I also realized that TicketDesk could probably meet the needs of most small IT shops, and probably many larger ones as well. It would also be a good learning tool for beginning programmers and could act as sample code for experienced developers that might be new to asp.net to the 3.5 framework.

So I decided that it would be a great open source project for CodePlex (I may be wrong on that, only time will tell there).

TicketDesk Design:

TicketDesk is designed as a pure help desk issue tracking system. The focus is on the relationship between your users and your IT staff.

It doesn’t attempt to be a customer facing support product.

It doesn’t attempt to be a customer relationship management system.

And it is not a bug-tracking system to support the software development life cycle.

TicketDesk allows users to submit tickets. It provides help desk with a way to keep track of the tickets. And it facilitates smooth communication between users and help desk.

That’s all it does.

TicketDesk concentrates on being simple and effortless. It has very few data entry fields, and demands almost no configuration or administration overhead.

TicketDesk leverages several common web 2.0 concepts to make tickets easier to track and to make working through a ticket more like having a conversation.

TicketDesk probably isn’t for everyone though. Large shops that demand tight administrative control over process and permissions will certainly not like it.

But if you have a help desk that wants a system that gets things done, take a look at TicketDesk over at CodePlex…

It’s simple to install and free.