Hacker News new | past | comments | ask | show | jobs | submit login

A ticketing system that doesn't sux (I like RequestTracker, but it shows its age). Top players are ridiculously overpriced.

My management style is like this: every task/request is numbered, placed in a queue and assigned to a professional.

What I expect from my ticketing system:

- every manager should be able to assign tasks to someone and set the order they must be executed. He needs know what his team is doing and when they finish each task. - every professional should know what to do and what are the priorities. - everything is numbered and linked, all communication recorded.

Everything should be well integrated with email (please, don't send me a notification email about an answer and an url, send me the f* answer). If I answer the email, everything goes into the system, I should be able to send commands to the system by email (for example, add a keyword in order to make it a comment instead of answering).




The problem here seems to be that users/customers insist on customizing any such app to death.

Personally, I think the optimal ticket system would have this data for each ticket:

* A unique, prefixed ticket # (JIRA gets this right)

* An assignee (like an email To:)

* A reporter (like an email From:)

* A one-line summary (like an email Subject:)

* A multi-line body (like an email body, but ideally with markdown)

* Attachments (like email attachments)

* History for edits of all of these (not like email!)

That's it! It really is basically email, but with a unique ID, and editable with history instead of immutable with replies, and a decent UI, perhaps RSS + notifications.

Unfortunately, everybody else seems to think that their ticketing system should embody their vaguely defined and ever-changing workflow, prioritization, approval, and release management system, so they want to be able to add any number of possible statuses, approvals, workflows and and all the rest. Once you add that, you end up with another JIRA or ClearQuest or BugZilla, and the cycle repeats itself.


This sounds very like Redmine [0]. It's ostensibly for project "issues" however it's extremely customizable and all of the above are included in the default config and not much more. It sounds like if you removed about 2 default fields it'd be perfect for the ticketing system you describe above. Plus RSS + Notifications + a solid API.

[0] http://www.redmine.org/


Even the older Trac has all of those features.


A ticketing system is a tool to support a workflow, and any friction it creates with the preferred workflow is waste.

As is (consequently) friction it creates in changing the workflow as needs change.

Thats just the fundamental and immutable nature of the problem domain.


I am pretty happy with Enchant. It's is pretty simple, but flexible enough for up to medium scale environments.


The app you seek is Asana.

www.asana.com

I'm not associated with them, but I have used them successfully for months at a time (better than most productivity software). The reason is it is well integrated and similar to email.


Asana is pretty bad. It takes forever to load, which sucks when people send you URLs to tasks/projects and you have to open them individually and wait almost 10 seconds for each to open.


Asana's start up time is just ridiculously slow. Probably the slowest webapp I've ever used. Also, you can't assign more than one person to a ticket, which is a pretty big limitation


JIRA also doesn't let you assign more than one person to a ticket. Could you expand on why this is a problem? I'm not familiarized with this problem space so I'm just curious.

The recent GitHub updates let you assign multiple people to reviews and such, but I find it's usually better to tag everyone you want to look at something. I don't think assigning something will send a notification.


I blogged recently about some problems I have with JIRA:

http://www.storytotell.org/constraints-and-semantics/

In a nutshell, I argue that the problem with most ticket systems is that they do not constrain the domain enough, so they wind up having similar problems to email (sifting through a chronologically-ordered pile of text rather than structured, semantically-ordered information).

Your comments make me think the crux of the problem is that people want tickets to be like email and use email to manage them. I'm not sure you can ever overcome the "chronological pile-up" problem if you allow email as a user interface to ticketing.


The simplest solution to the 'chronological pile-up problem' (nice name BTW) is a Wiki model, where replies are appended by default but the entire content can be edited if necessary. (C2 demonstrates this quite well.) For simple problems, conversations behave exactly the way they used to, but when it starts getting complex someone can go in and rearrange the conversation into a more logical form. This actually maps quite well to email: by default replies are appended to the bottom, but they can also be inserted inline (some mailing list etiquettes even demand this) or indeed the entire conversation can be rewritten. You'd probably want some sort of merge algorithm in case someone replies to an older email.

In fact, my usual approach to dealing with tickets/issues/emails which start to develop this problem is to make my own private copy of the thread and edit it in precisely this manner, though I'm the only one this benefits since it doesn't get sent back upstream.


I also have an idiosyncratic way of organizing this stuff, which is basically to use Emacs + mu4e to search my mail, and if I need to create order, write a new document from scratch. I have a coworker who does what you do, now that you mention it—he will take a series of email, dump it into Word and edit it until it is a useful document of some sort.

I still think there is something here though. Stack Overflow replaced message boards, which were basically HTML versions of mailing lists, and part of that was identifying the semantics of question, answer and comment and defining new operators and new expectations for them.

A wiki is a good approach but because it's totally free-form, the user gets stuck doing the work of keeping things hygienic.

JIRA allows you to edit all the properties of a ticket whenever, but it generates such a huge cloud of email notifications in the process, it kind of disincentivises you from using it. And nobody is in the habit of rereading the page to see what is different since last time.


> Your comments make me think the crux of the problem is that people want tickets to be like email and use email to manage them. I'm not sure you can ever overcome the "chronological pile-up" problem if you allow email as a user interface to ticketing.

I agree that's partly it, but that seems ok when you're in the thick of discussing a problem/fix. If you're doing a code review or something after a fix has been pushed, you actually want certain messages to stand out to describe resolutions and whatnot.

So like gmail where you can star/mark certain replies as important and those messages would show up at top-level in the ticket, where all other messages are collapsed.


We're in our first month of releasing Zammad [1] an open source Zendesk alternative with pretty neat features. You can check out some screenshots or a free 30 day trial oft our hosted solution on our commercial site [2]. I really like your feature ideas and will later create issues for them. Would be great if you add some too if you have more of them.

Full disclosure: I'm part of the maintainer staff.

[1] https://github.com/zammad/zammad/ [2] https://zammad.com


Additional features: custom fields w/ user-chosen types: free text field, drop down list, etc.); time tracking (I spent n hours/minutes on this ticket); these should be searchable.

Major feature that allows me to work around any shortcomings in your office: API access to everything and/or database access (preferably direct read/write access, but even if it's just a downloadable .sql.gz it's a huge benefit).

I'm probably not a typical user, though, FWIW.


I've been building support and dev/ops ticketing systems for years and I still haven't found a platform that suits all needs.

For my latest startup I went looking for a service desk tool. The key criteria was "feels like email". The moment any alternative required a user signup just to lodge a support request, I ruled it out.

I ended up choosing Groove. I don't recommended it. All ticketing systems suck, this one just sucked the least for my support desk. Groove doesn't extend to other ticket types, and it's nowhere near as flexible or extensible as JIRA, and the mobile experience is horrible. But it does "feels like email" for my customers better than every alternative you care to mention.


> every manager should be able to assign tasks to someone and set the order they must be executed. He needs know what his team is doing and when they finish each task.

That sounds like unnecessary micromanaging. You couldn't possibly have enough detailed knowledge to know the proper order of tasks in all cases. Possibly even most cases.

I agree that communicating the priorities are important, but the boots on the ground have a much better understanding of what they're working with than you do.


we use Github issues + Zenhub for that (though Github has recently implemented a lot of Zenhub's features). Managers mainly use the 'boards' and 'milestones' views; devs use 'boards' and whatever else. Messages are included in emails and you can reply by email.


What would a reasonable price for this product be for you?


anything billing for data volume instead of by attendant would be a good start.


how about using an app like Trello for that?


Currently we use a mix of trello, smartsheet, slack and god knows what. It is a mess.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: