Slashdot Mirror
Web-Based Helpdesks?
Vanbo asks: "My job requires that I be in the field all day, and I don't have the ability to check my voicemail regularly, so I ask people to email me with problems, then I check my mail with Webmail. Lately, I have been thinking it would be much easier if people could post their problems (ala ask slashdot) to a webpage on our mailserver. I don't need something as powerful as slashcode, but just maybe something that allows them to select from pull downs of common problems, and then when they submit it, it could be emailed to me. Anyone, implimented a support system like this? Any draw backs to this approach?" Seems like a novel approach. Does this seem like a good idea to you?
The only problem I would see is the problem with all internet based tech-support. If your computer won't boot, or you can't get online, you are sort of out of luck. But as he said he also has voicemail, so with both the idea is pretty sound. Plus it would be pretty easy to set up. 'e-Support' is a good idea, but it will never fully replace phone support, especially for novices.
I Haven't Lost My Mind -- It's Backed Up On Disk Somewhere
My rantings, only longer and with better spelling..
-Nathan
Check freshmeat! I've tested out several systems listed there. Most are PHP/MySQL scripts..
so they are easily customized.
I've written a simple help desk tracking system in ASP. It's nothing too complicated... and I never got around to finishing the reporting features, however it is great for keeping a paper trail of all the requests that come into the helpdesk, and a history of tasks performed to solve the issue.
It is all setup for some in depth reporting, and it's ASP so I don't claim it.
I'd be happy to post it for interested parties. Just contact me at my email... remember to nuke the spam proofing before you mail me.
I'm not trying to flame the faceless masses, but...
I think it would be very problematic if the main "customers" were not technically/computer inclined. We live in a world where X thousand people clicked on a VBS script without knowing what it is, then blamed Microsoft for letting them do it. So many people can barely figure out e-mail, you could be asking to trouble by giving them a more complex system to deal with.
That said, it would probably be pretty cool if it was used by sharper minded folk. Throw in a indexed stash of prior problems, and it would cut your workload quite a bit.
...
Got Warez?
We have a system set up for the tech department at my school that is like this. We instruct people to go to our web site, and they fill in all of their contact information, as well as a quick description of their problem (hardware, software, network, user error, etc...) and then issue a description of their own.
This is all backed up to a database so that it can be sorted and later archived. A simple adminsitrative interfaces allows several techs to access this system, and mark something as theirs to work on, or delegate it to the particular person. There is also room for us techs to make comments on particular requests.
This method has worked great for us, the only problem is remembering to check it on a routine basis, and from the sounds of it, that won't be a problem for you. And obviously, it wouldn't be too difficult to tie it to an email program.
(Heck, if all you want is for the problems to get emailed from a nice interface to you, you dont even need a fancy system behind it, just a decent mailto script.)
--Ed
I'm facing the same issues right now, and trust me, it's not the nicest field to play in. Basically, you have four options : Get commercial off-the-shelf solutions, get some open source solution (IRM and PHPHelpdesk jumps to my mind right now.), hire a developper to make one custom fit, or make one yourself.
Now, on the the debunking of my own affirmation (Trust me, I've done 4 weeks of research on that recently).
1- Commercial off the shelf : I dont know how big a user base you'll be dealing with, but since you seem to be alone, I'll assume under 250 users. The cheapest "helpdesk" commercial solution you can get with web based problem reporting goes around 5000$. And you'll have to setup your own MS SQL / MS NT / IIS to support it.
2- Open source: IRM is nice, PHPHelpdesk seems promising, but unless you have extensive MySQL / PHP / Apache experience, I recommend you stay away from them. They are poorly documented, and even tho the end result is nice, they seem a bit "unfinished".
3- Getting someone to develop: Now, that's my best option so far. For under 5000$, I'll have someone develop a simple set of forms + reports + agent based on our Domino server architecture. Meaning I get an already enterprise supported platform to build on, some scripting I can understand, web-based user forms, and something that can grow. The best thing is that we plan to open source the scripts once we're up and running.
4- Developping the bugger yourself: Well. This one I crossed right off. If you're anything like me, you're already overloaded with supporting your users, and dont have much free time to start hacking a helpdesk together.
That being said, my opinion is to go for option 3, find some nice person that will custom-fit a solution to your needs, and make it usable for you. That way, you get support, working solution in no time, and expansion possibilities. You dont need / cant afford / dont want to support the cheapest of the "off-the-shelf" solution out there. Trust me. Mail me if you want to discuss this some more.
Marriage is considered capital punishment for the theft of a goat in some third world countries...
While i would recommend a web based ticket tracking system, I'm not altogether sure that a fully web based support system is the answer. For one thing, it removes the personalized aspects of the support process. Customers, or whoever, may have problems letting you know exactly what needs to be done, as they may not fully know themselves. After all, that's what you're there for.
That being said. There is a really good utility that we use here at my company, a Problem Resolution support system. Users are allowed to login and create problem reports, then assign them a priority and a status (such as open, feedback, etc.) - This allows the most pressing problems to get tackled first. Additionally, when a problem report changes status, or gets closed, - both the user and the tech (or whoever) get notified via email.
While this may not be exactly what you're looking for..it's a good variant. Just remember...none of it is as good as a phone call, or better yet, being there in person.
FluX
After 16 years, MTV has finally completed its deevolution into the shiny things network
"It is seldom that liberty of any kind is lost all at once." -David Hume
RT, Keystone, and php Helpdesk would be good starting points.
We are all in the gutter, but some of us are looking at the stars. -- Oscar Wilde
Check out Apache Jetspeed . We are working on version 1.2 right now and it will include Project Management and iCalendar support. Should be just wnat you need. Expect about a week or so for version 1.2.
Kevin
McAfee/NAI has a really slick setup called Total Help Desk that we've got installed at our company. It's much more cost-effective than you might think: sure, you're going to shovel $20k in up front, but the functionality is unbelievable.
It includes a lot of things you wouldn't be able to put together yourself. For example, it has a built-in knowledge base that you can search, and it automatically indexes all of the generated tickets. When you enter a ticket, or when you're working with a user, you can see all of their previous tickets at the click of a mouse, so you can see if some junior help desk flunky screwed up their system yesterday.
It has a lot of canned reports that show the average time to solve a problem, average hold time, and more.
It e-mails everyone involved when the status on a help ticket changes - for example, if I say that a ticket is fixed, that status update is emailed to me, to the user, and to the user's manager. It keeps our help desk staff from "hiding" tickets, and it keeps the users from whining that nobody has looked at their ticket recently.
It has an awesome "escalation" mechanism that can automatically escalate tickets to the right staff member based on their skill set. For example, I'm registered in the system with certain key words. If an FTP problem goes unsolved for more than 2 hours, I get an e-mail, and I know I should jump in. If a TCP/IP problem goes unsolved for more than 3 hours, our network admin is e-mailed, because she can probably help out - but I don't want to know about it. However, if any ticket is open for more than 16 hours, all of the key managers are e-mailed.
It even works as a development tracking utility. We track requests for enhancement in it, and we can see how long it takes for a bug to get fixed. The testing department loves it, because we can track how many times an issue gets bounced back to development because the coders can't code worth a damn. The contract programmers love it because they can work from home and still maintain full contact.
Before you start thinking about writing one of these, I'd strongly suggest looking at a demo of McAfee's solution. We looked at it and realized that we could put a talented coder to work for a year and not come out with a solution this hot. (The best thing is that it's all in SQL, so you can do your own PHP interface if you want. I wrote some addons in Drumbeat already.)
What's your damage, Heather?
Take a look at Call Center, Bug Tracking and Project Management Tools for Linux, which has a bunch of these.
Gnu Bug Tracking System (Gnat) has a billion (or so) user interfaces you can use with it - Tk, web, command-line, etc.
Even the high-end call-tracking systems like remedy can be (and often are) configured to email you when you get a new case assigned to you, but these are hugely expensive and it doesn't sound like you wanted to spend a lot of money.
This is a neat idea, and I'm thinking about impelmenting something similar for my users who aren't able to contact us during business hours.
However, I have personally dealt with other support departments via email and web-based help desks, and it can be tedious if either party lacks experience. If the user can't give a detailed account of the problem, you'll find yourself trying to fish out the true nature of the problem for an extended time, possibly several days. Conversely, if the people on the support end lack experience (ie they don't know how to ask the right questions), the problem is compounded.
Abstainer: a weak person who yields to the temptation of denying himself a pleasure.
--Ambrose Bierce
Abstainer: a weak person who yields to the temptation of denying himself a pleasure.
Abstainer: a weak person who yields to the temptation of denying himself a pleasure.
--Ambrose Bierce
...we had one email address that all users used to send their support issues (upgrades,hw/sw troubles etc etc). Of course if the network was down or something there was also phones, but email was the primary way of communication (if you machine doesn't work, the one in the next room probably does).
All the support personel there used an app which showed one folder for each technician plus one for the incoming support requests and one for solved issues. As mails dropped in to the central "Incoming" folder any free technician just moved that mail to his folder, solved the issue, replied to the mail with the solution (making it a thread) and then moved the entire thread into the "solved" hierarcy.
The users were also given lots of examples on how to write good problem descriptions etc in order to get as informative reports as possible.....this was one of the best systems I've seen....creating something like that shouldn't be too hard?
I've found great success with the Keystone system. It's a PHP and MySQL web-based incident tracking system that makes good use of email for notification and status reports. I believe there is also a module that lets you submit incidents via email.
90% of techical support is not finding an answer, or even explaining the technical part of the answer. Most of technical support is providing emotional support to a worried user, and then explaining how to fix the problem to the customer, even if they don't have basic OS skills.
My expereince is hardly exhaustive, but in technical support, we were never wondering to ourselves what "Error 678" meant, or what "Netscape can not find host meant", we were trying to explain to customers that Netscape was not thier ISP, and that it was not that "our server" was down when Netscape was corrupted.
The techincal problems of any one software program are actually pretty easy to figure out after the first week or so of using it, it is the customer service aspect that keeps most help desks buzzing.
Hopefully I didn't put any [] around my words.
My organization used to have a crude ugly conference system, which left recent postings at the top and did a little bit of nesting. It was very popular, the sales people could use it to talk to each other, and yeah, it got slower every month as the number of articles grew. They replaced it with a fancy system that pretends to do lots of nesting, keep track of what you read, and everything's sorted by topics. It's flaky, hard to navigate in, forgets what you've read, and (worst) doesn't get used as much as the crude system it replaced. They'd have been much better off leaving it alone and occasionally dragging old articles to another directory (or even just trashing them after 6 months, though archiving would be much better.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I use VNC for the exact same thing. Only I'm the expert. :-) It sure beats trying to explain how to do something over the phone. Just log in and fix it.
What I'm trying to say is: if you start such a thing, be very very sure they'll leave a valid and rapid mode of contact, and urge them to give you a full description of the actual problem. Make it clear in big letters, that if you can't contact them, they're the ones up shit creek, with that paddle, and that you won't shower them should they get out.
Stefan
"Microsoft follows standards, much like fish follow migrating caribou." Paul Tomblin, in the monastery,
The truth shall make you fret. (Ankh-Morpork tImes motto)
Firing the guy was unfortunate for two reasons.
1- The guy lost his job, I've been there, that sucks for anyone.
2- The real problem didn't get fixed by firing the guy. (not the segment)
The source of the problem is the processes in your IT and Ops worlds sound pretty broken, and although firnign the poor guy made a few people happy and inflated the egos, it did nothing to prevent the same scenerio from happening again. Thats too bad. The real problem was broken process, not the fact that some slacker was focused more on talking to his girlfriend than giving world class support. Midville School for the Gifted. Tell you exec's to stop trying the same things, yet expecting different results.
Don't just whine about poor internet privacy and freedom policies,
And it works, sort of. It works well for me, and it works quite well for my more computer capable clients, but some other clients:
Not that those problems are really majors, but they get in the way, and so they don't always submit their problems.
What I need to do is let people e-mail their problems into it, and exactly how to achieve this is churning away in the back of my mind at the moment.
I've also done a WAP gateway on it so that I (and others, because the whole company uses my system now) can enter timesheets and lookup jobs and such with a WAP phone.
If you're interested in the code I'm sure we can dig something out. It uses Apache / PHP / PostgreSQL and handles through to the billing stage.
E-Mail me if you want more information.
Andrew.
Look for KEYSTONE online, it runs under php3 uses Mysql and is free to use for small departments. is open source and better than anything out there. (Even the commercial overpriced stuff) Use Keystone, it works and is great. (It has one drawback, if your Network Operations center is a bunch of MS nuts they wont let their precious exchange server talk to that nasty Linux/Freebsd box running keystone.. at this point get a dial-upservice for the box and it will send the email out the pop3 on the isp.
Do not look at laser with remaining good eye.
Of course, this technique won't work if your computer can't boot or you can't get Internet access, but it's not intended to solve those problems. Frankly, I think it's a stupid idea, because it's only going to convince the user even more that they don't need to read the manual.
I think there should be an incentive for support - if the solution to the problem can't be found in the documentation, the support call is free. That has a double benefit: the software vendor wants to make the manual as complete as possible, and the user wants to save money by reading the manuals first.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
The biggest problem with most users is, that they only tell you, at first contact: "It doesn't work!"
So provide a form with the information you need, and refuse to submit it if it's not filled out.
They have that at a client's site, and it seemed like most of the people used it, but then called if they didn't get an answer back within 10-15 minutes. So unless you're really committed, or put an "Average Wait Time" up on the page, you'll probably still get most of the calls.
Later,
Blake.