I've installed RT to be used for managing incoming support emails. Having got it installed and "working" I'm finding it very hard to work out what to do next in terms of actually using it. (Eg I created myself a user, but can't see how to let that user see incoming emails, although I can see them fine logged in as root.)
Are there any good guides to using RT around? Google has let me down so far, and the RT wiki seems a bit to broad to get me started.
Where I need to get to pretty quickly is having a number of users, any of whom can take a ticket and work with it, or allocate it to another user where necessary. I also need to manage the email process (I have one particular client I want to push in this direction, but to do that I need to make sure they don't get most of the automated emails otherwise they'll be swamped as they send us probably 200 emails a week that will become separate tickets once I get this working).
On 20 December 2010 13:59, Mark Rogers mark@quarella.co.uk wrote:
I've installed RT to be used for managing incoming support emails. Having got it installed and "working" I'm finding it very hard to work out what to do next in terms of actually using it. (Eg I created myself a user, but can't see how to let that user see incoming emails, although I can see them fine logged in as root.)
Are there any good guides to using RT around? Google has let me down so far, and the RT wiki seems a bit to broad to get me started.
Where I need to get to pretty quickly is having a number of users, any of whom can take a ticket and work with it, or allocate it to another user where necessary. I also need to manage the email process (I have one particular client I want to push in this direction, but to do that I need to make sure they don't get most of the automated emails otherwise they'll be swamped as they send us probably 200 emails a week that will become separate tickets once I get this working).
We use Spiceworks at work. http://www.spiceworks.com/ It offers a helpdesk system which does hook into email, we use a generic helpdesk@ mailbox but the system forwards new tickets to our own addresses if we want it to - Spiceworks also offers a "user portal" so the user can log in to that to view their currently open tickets on a web-based system which sounds better for your high-volume client. The system allows allocating tickets to particular people etc. It also allows closing/updating of tickets directly from the automated email system, e.g. I can reply to an email with #close and a message which will close the ticket and push a message back to the user through the helpdesk@ mailbox. In Spiceworks you can also allocate time spent on each ticket and thus money charged in the latest version. It's got a good purchase tracking system also if you need to buy something to complete a particular ticket.
And it's open source!! Maybe it's more what you're looking for - maybe not. Just my 2p.
Thanks, Simon
On 21/12/10 08:51, Simon Elliott wrote:
We use Spiceworks at work. http://www.spiceworks.com/ It offers a helpdesk system which does hook into email, we use a generic helpdesk@ mailbox but the system forwards new tickets to our own addresses if we want it to - Spiceworks also offers a "user portal" so the user can log in to that to view their currently open tickets on a web-based system which sounds better for your high-volume client. The system allows allocating tickets to particular people etc. It also allows closing/updating of tickets directly from the automated email system, e.g. I can reply to an email with #close and a message which will close the ticket and push a message back to the user through the helpdesk@ mailbox. In Spiceworks you can also allocate time spent on each ticket and thus money charged in the latest version. It's got a good purchase tracking system also if you need to buy something to complete a particular ticket.
And it's open source!! Maybe it's more what you're looking for - maybe not. Just my 2p.
That all sounds about perfect, thanks for the suggestion!
The only downside is that it seems to require a Windows host. I might experiment anyway (I wonder if it works under Wine?). But I had assumed that I'd be using something which sits out of the office on a virtual server somewhere so that everyone (eg customers) can access it without me opening up the office connection, but for that to work it would need to be Linux based.
Worth a look though. Thanks!
"Simon Elliott" alug@sionide.net wrote:
On 20 December 2010 13:59, Mark Rogers mark@quarella.co.uk wrote:
I've installed RT to be used for managing incoming support emails.
Having got it installed and "working" I'm finding it very hard to work out what to do next in terms of actually using it. (Eg I created myself a user, but can't see how to let that user see incoming emails, although I can see them fine logged in as root.)
Are there any good guides to using RT around? Google has let me down
so far, and the RT wiki seems a bit to broad to get me started.
Where I need to get to pretty quickly is having a number of users,
any of whom can take a ticket and work with it, or allocate it to another user where necessary. I also need to manage the email process (I have one particular client I want to push in this direction, but to do that I need to make sure they don't get most of the automated emails otherwise they'll be swamped as they send us probably 200 emails a week that will become separate tickets once I get this working).
We use Spiceworks at work. http://www.spiceworks.com/ It offers a helpdesk system which does hook into email, we use a generic helpdesk@ mailbox but the system forwards new tickets to our own addresses if we want it to - Spiceworks also offers a "user portal" so the user can log in to that to view their currently open tickets on a web-based system which sounds better for your high-volume client. The system allows allocating tickets to particular people etc. It also allows closing/updating of tickets directly from the automated email system, e.g. I can reply to an email with #close and a message which will close the ticket and push a message back to the user through the helpdesk@ mailbox. In Spiceworks you can also allocate time spent on each ticket and thus money charged in the latest version. It's got a good purchase tracking system also if you need to buy something to complete a particular ticket.
And it's open source!! Maybe it's more what you're looking for - maybe not. Just my 2p.
Thanks, Simon
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
Ummmm! Doesn't seem to run on Linux.
Mick
Simon Elliott wrote:
On 20 December 2010 13:59, Mark Rogers mark@quarella.co.uk wrote:
I've installed RT to be used for managing incoming support emails. Having got it installed and "working" I'm finding it very hard to work out what to do next in terms of actually using it. (Eg I created myself a user, but can't see how to let that user see incoming emails, although I can see them fine logged in as root.)
Are there any good guides to using RT around? Google has let me down so far, and the RT wiki seems a bit to broad to get me started.
Where I need to get to pretty quickly is having a number of users, any of whom can take a ticket and work with it, or allocate it to another user where necessary. I also need to manage the email process (I have one particular client I want to push in this direction, but to do that I need to make sure they don't get most of the automated emails otherwise they'll be swamped as they send us probably 200 emails a week that will become separate tickets once I get this working).
We use Spiceworks at work. http://www.spiceworks.com/ It offers a
[SNIP]
FWIW, we used that because a client did, and we all hated it. Also, it is impossible to get them to stop send marketing and "informative" emails. I wouldn't go near Spiceworks with a barge pole. IMO...
Cheers, Laurie.
On 21 December 2010 10:37, Laurie Brown laurie@brownowl.com wrote:
[SNIP]
FWIW, we used that because a client did, and we all hated it. Also, it is impossible to get them to stop send marketing and "informative" emails. I wouldn't go near Spiceworks with a barge pole. IMO...
*gulp* I honestly didn't know they did not offer a Linux server version!! Maybe not the best thing to rave on about on a LUG list but at least it is definitely open source.. in my defence I don't have much to do with running it here, only using it and running the helpdesk through it. From a users perspective I think it does fit the bill of the OP, regardless of the running on Windows thing. :(
I don't get any gumpf emails though, must have switched all that kind of stuff off.
Cheers, Simon
On 20 December 2010 13:59, Mark Rogers mark@quarella.co.uk wrote:
I've installed RT to be used for managing incoming support emails. Having got it installed and "working" I'm finding it very hard to work out what to do next in terms of actually using it. (Eg I created myself a user, but can't see how to let that user see incoming emails, although I can see them fine logged in as root.)
Create a queue (support, admin, etc.) and add users to that queue? Then when you email that queue all users in that queue should see the same email?
We use RT here at Memset and works well enough for us. I've never administered an RT system, but I do recall upgrading between version 2 and 3 was a royal pain in the arse.
Regards,
Martyn
You might want to take a peek at GLPI (I shudder at the thought of including a link, as every-time I add a link my message gets rejected)
so try Googling glpi-project dot org
Best of luck
Rob
On 21/12/10 13:29, Rob Snow wrote:
You might want to take a peek at GLPI (I shudder at the thought of including a link, as every-time I add a link my message gets rejected)
so try Googling glpi-project dot org
Not sure why you have problems with links (like http://www.glpi-project.org - maybe your mail client switches to HTML email as soon as you add a link?) but thanks for the pointer anyway.
I have looked at the GLPI website before but it seems more biased to asset tracking than issue tracking. Do you have experience with it? Would it suit me as a method of handling incoming support emails, and making sure each one gets actioned?
IMHO Glpi is a great issue tracker - we have it picking up emails from an (yuk) exchange mailbox, and users also submit requests via a web page. GLPI keeps them informed every time we do something to their ticket ( if we want them to know).
We also use it to manage requests for loan equipment.
If you also want to use its asset tracking capabilities it needs another package called OCS-NG.
Every day I find more ways for it to make my life easier. We support about 200 users here and even they took to it like the proverbial ducks to water. We only needed to show our most "challenging" users the basics - everyone else just accepted it and ran with it!
Regards,
Rob
On 22/12/10 11:06, Rob Snow wrote:
IMHO Glpi is a great issue tracker - we have it picking up emails from an (yuk) exchange mailbox, and users also submit requests via a web page. GLPI keeps them informed every time we do something to their ticket ( if we want them to know).
That all sounds promising, worth a look.
Every day I find more ways for it to make my life easier. We support about 200 users here and even they took to it like the proverbial ducks to water. We only needed to show our most "challenging" users the basics - everyone else just accepted it and ran with it!
That's pretty impressive, most of my attempts so far have been more like duck to Chinese restaurant! I also like the fact that (IIRC) GLPI is PHP based so it falls into my skillset rather than relying on things "just working" like some of the others do.
On 21/12/10 14:32, Mark Rogers wrote:
I have looked at the GLPI website before but it seems more biased to asset tracking than issue tracking. Do you have experience with it? Would it suit me as a method of handling incoming support emails, and making sure each one gets actioned?
Sorry for adding another thing to look at but we use OTRS at work http://otrs.org/
I have never got round to fine tuning it to fix the behaviour of a few things that annoy us but we use it for support emails and support call management for a number of products and it works pretty well and is easy to get going out of the box.
I did look at RT first but it seemed a bit less usable out of the box, although possibly more flexible once you got it working. One thing OTRS does do quite well is manage service contracts so there is a calendar where you can mark a contract renewal date and it will flag any service tickets for that customer if they are out of contract. This and the ability to add scheduled tickets for routine service was something that was important to us, but maybe not so relevant in your case. It also allows you to feed in support hours for a ticket resolution or at each point in the case notes and then produce a report that does hours to ticket or hours to customer which again is handy for billing.
Wayne Stallwood wrote:
On 21/12/10 14:32, Mark Rogers wrote:
I have looked at the GLPI website before but it seems more biased to asset tracking than issue tracking. Do you have experience with it? Would it suit me as a method of handling incoming support emails, and making sure each one gets actioned?
Sorry for adding another thing to look at but we use OTRS at work http://otrs.org/
I have never got round to fine tuning it to fix the behaviour of a few things that annoy us but we use it for support emails and support call management for a number of products and it works pretty well and is easy to get going out of the box.
I did look at RT first but it seemed a bit less usable out of the box, although possibly more flexible once you got it working. One thing OTRS does do quite well is manage service contracts so there is a calendar where you can mark a contract renewal date and it will flag any service tickets for that customer if they are out of contract. This and the ability to add scheduled tickets for routine service was something that was important to us, but maybe not so relevant in your case. It also allows you to feed in support hours for a ticket resolution or at each point in the case notes and then produce a report that does hours to ticket or hours to customer which again is handy for billing.
We use RT mainly because it was essentially all that was about 10 years ago when we started working that way. We are now a long way behind the latest-version-curve, and updating RT is a royal pain. We think we will take the opportunity to use another, simpler tool, more in tune with our needs. RT is extensive and extensible, but far too complex for a simple helpdesk.
With RT, we like the idea of a queue per client or function, and we have written reporting tools to assist billing and stats. From your comment above, it sounds as if OTRS will provide the latter, but does it use queues, or have some similar functionality? There's a Turnkey Linux VB image for this, which I think we'll play with, but I'd appreciate a brief synopsis if you have the time, please.
I've already looked at GLPI, but I agree with you, and asset tracking isn't the core we need, helpdesk is.
Cheers, Laurie.
On 04/01/11 14:30, Laurie Brown wrote:
With RT, we like the idea of a queue per client or function, and we have written reporting tools to assist billing and stats. From your comment above, it sounds as if OTRS will provide the latter, but does it use queues, or have some similar functionality? There's a Turnkey Linux VB image for this, which I think we'll play with, but I'd appreciate a brief synopsis if you have the time, please.
Yes it does use Queues, Although I am not sure how well the user interface works if you have lots and lots of them.
How we work with it is we have one Engineering team that are responsible for maintaining several customer products plus some equipment on site.
I have some product specific queues for support enquiries, then I have queues for Engineering functions such as scheduled service, installations, Post Delivery Prep, Site Visits, Site surveys etc and a Queue for Internal Engineering (non customer) tickets.
Support calls for a product go into the products queue, this queue then notifies any engineers that are trained on that product. The installation of a new machine has a ticket generated in Site Surveys (being the first function of a new installation) and we then move that ticket between the other queues depending on it's status.
Then I added a free text field which is the Machine Serial number and a Drop down for the equipment type (product). So given a serial number I can see a whole machine history from the day it was taken out of the box. That so far has pretty much been the extent of my modifications beyond setting up queues and users.
Hope that helps but it is best to have a play and get your head around the configuration options (there are lots) . The PDF manual is pretty good too.
On 21/12/10 12:55, Martyn Drake wrote:
Create a queue (support, admin, etc.) and add users to that queue? Then when you email that queue all users in that queue should see the same email?
I'll have another look at this, but this all seemed quite convoluted.
<later>
OK, I've created a group and added lots of rights to it for my main support queue (no idea what half of them do!) and added my user to the group, and I can see stuff in the queue.
I can see how to "Take" a ticket, although no idea how I might allocate it to someone else.
Also, what I will almost certainly need to do is to have mail from certain email addresses automatically go into certain queues regardless of the address they were sent to, I assume that's possible somewhere?
I have to say that RT just feels very much like hard work, although I appreciate that a lot of people use it so it must be doing something right. (Could use the same argument for Windows mind you....)
Mark Rogers wrote: [...]
I can see how to "Take" a ticket, although no idea how I might allocate it to someone else.
Go into the Basic details editor and assign it to them.
Also, what I will almost certainly need to do is to have mail from certain email addresses automatically go into certain queues regardless of the address they were sent to, I assume that's possible somewhere?
rt-mailgate is the command you require. I think you set the --Queue option in the email alias.
I have to say that RT just feels very much like hard work, although I appreciate that a lot of people use it so it must be doing something right.
The co-op has used it for a while and it gives us a *lot* of detail which we can use to plan our improvement. Sorry that I can't send you a link to our guide - I don't think he'd appreciate it! ;-)
Regards,