I have a fully configured mantis bug tracker for tracking issues in apps that I create. When an user is disciplined and goes straight to mantis to write a issue report, he/she will have fastest response and everything regarding the issue will be very easy to track.

However, not everyone is keen to do so. They report their problems via phone, e-mail, don't report them at all.

What would be the best way to nudge them towards the using a bugtracker system? Clearly, they HAVE to see some immediate benefits so they can return and look for more benefits.

7 Answers
7

Your bug tracker is for your convenience, not your customers'. If you can't be bothered to take their phone or email issue and enter it yourself, how do you think they feel?

You need to be able to enter issues and assign them manually to a client. Then when they call in with an issue you can say, "Thanks for reporting that! I'm going to enter it into our issue management system, and you'll start getting email (or whatever) as we deal with it. In the future, if it's easy for you, you can enter that sort of thing right there. Or feel free to just call me, that's fine too."

One of the best such systems I've worked with as a customer is the one at the hosting provider I resell. Email to support@ gets parsed for a domain name in the subject line, assigned to a client account based on the from address, and auto-entered into their ticket system. Pretty slick.

@tcrosley - then you need a better bug tracking system. The key here is not whether the users have to use the tracking system but rather how do you persuade the users that its better (easier, quicker, more likely to achieve the desired outcome) to use the tracking system.
–
MurphOct 29 '10 at 12:50

1

I really can't agree with this. Programmers should never be receiving bug reports directly from users by phone, e-mail, or any other venue for that matter. If users want to report bugs "personally" then they should be doing it through support personnel. If they refuse to do that then their only option should be to submit a real bug report, either directly through the UI or via a dedicated e-mail inbox that forwards into the tracker. And if you're an ISV and don't have support personnel, well, that's another issue entirely.
–
AaronaughtOct 29 '10 at 14:30

1

As an ISV startup, i really can't have support personnel. And not for the obvious reason - that is expense, but the reason that I want to be as close to the user as possible to steer the product in the right direction according to the needs and wants. Middle man would dilute it to some degree.
–
Daniel MošmondorOct 29 '10 at 19:52

This answer isn't entirely true. As discussed at programmers.stackexchange.com/questions/191961/…, at least in the context of open source development, a bug tracker can be quite beneficial for users: it acts as a support knowledge database of known issues, and can provide workarounds, if they exist. It lets the user assess how quickly their issue is being addressed, helping them decide whether to move to a different solution. It also helps potential contributors how the team operates and where help is needed.
–
naught101Sep 12 '13 at 1:41

A user who complains is better than one that doesn't, gives up, and calls your competitor. For this reason, I would make it as easy as possible to send a complaint. I would let them continue to call and/or send emails and not ask them to file bugs.

Look at it from their point of view -- If you had to not just take the time to call/write an email but also be forced to learn someone's wonky bug tracking system-- odds are you're just not going to complain.

If need be, hire a customer service person so developers don't get interrupted. They can take the complaints from the customers and make bugs for the dev team.

I would like that user that complains is better than the one that doesn't PERIOD. If there's something I dislike the most is the user that uses the software in faulty way, doesn't report anything and accumulates grief.
–
Daniel MošmondorOct 29 '10 at 11:50

+1 - Email is the only way I want my customers to interact with my bug tracker. The Mantis UI is far from user friendly, but even with a slicker solution, customers will feel like they're doing your work for you.
–
grossvogelOct 29 '10 at 14:13

"Please report this on the bug tracker at http://your/url/. I cannot keep track of bugs if you don't report them there."

Perhaps it's possible for you to write a plugin for your mail client to turn an email into a bug report, or to use a dedicated mailbox - bugs@foo - for taking bug reports. (But the latter of course requires training your users...)

There is a plugin for mantis for collecting bugreports from e-mail.
–
Daniel MošmondorOct 29 '10 at 11:48

1

+1..because talking on the phone is distracting, unproductive, and unofficial. It also leaves no trace on who said what and why. Later on, when people ask why you did something you have to explain yourself instead of pointing them to issue #xxxxxx. Phone should be banned. If your users don't know how to use your bug tracker, you can educate them.
–
dr Hannibal LecterOct 29 '10 at 14:30

Internally we have a site template for web applications that includes a feedback link in the corner. This feedback link is provides the user with a jQuery UI dialog that prompts them for a description of the bug, new feature, or other that they encountered and also captures some details about the page and time they are reporting from. All this is pushed directly into JIRA behind the scenes and the user can get updates with the status of the issue.

In sort the best way of doing things is usually by making it as simple as possible for the users, if there is a feedback link in a menu that handles sending the information where it needs to go, they are much more likely to use it.

Well, if you want to use a global exception handler, then you've got lots of options. For Delphi we use MadExcept, but also have used Eureka Log, both of which will (with the user's go ahead) email, or upload via HTTP, a bug report to you.

You could have a button in your app that just throws an exception and launches this bug tracking stuff. MadExcept is pretty cool because it takes a screenshot of the app and uploads it along with the bug, that way even if the user can't properly explain what they were doing, you can have a pretty good hankering.

Something else to think about is coding to make it obvious where bugs are coming from. If you've got beta users, maybe include debug info with their app so you can get extra data from them when crashes happen.

None of this helps for implementation bugs (i.e. the button is in the wrong spot) though so hopefully you don't have any of those.

Of course I do have an e-mail exception handler with, but that is really last resort. More things what I would like to capture comes from user wishes for new features and improvements on the system.
–
Daniel MošmondorOct 29 '10 at 14:10

OK good, got a baseline then. So I would start by not calling it a "Bug Tracker" if you want a more of a uservoice forum! If your current bug tracker captures screenshots, maybe you could have it open MS paint and let them suggest improvements for you before they send off the message.
–
Peter TurnerOct 29 '10 at 14:16

We got the biggest increase in uptake by configuring a service to pick up email from an address and automatically log it as an issue. The nice side effect of this system is that you can also easily add conversations to an issue by including a special syntax in the subject (eg. TeamITNo:12345). Also, if you send all your email communication via this system, and they hit reply then you'll get the reply right back into the bug tracker, with the issue updated.

This had the biggest positive effect, as it uses technology users are comfortable with, and also means you get all your issues in one place.