Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Advice wanted with launch of new internal support system 1

Status
Not open for further replies.

chriscboy

Programmer
Apr 23, 2002
150
GB
I currently work for a Business Support department of an SME, which has about 50 employees. I am part of a small team of 3 people, which run IT. I deal with all system design & programming for the databases at this company (along with PDA development, VBA development to name a few), one person deals with hardware/software and another supports me with my job, crystal reports, and general IT support.

We have decided to create a support system to monitor the calls and support issues we get, so that I can justify where my time is going, as the projects we planned to get complete are overrunning. I know this is down to the current imbalance of support/development time, so by introducing this system I can show my superiors where our time is spent (hopefully!).

We have created a paper-based system and worked with that internally for a few months now. (We logged issues on paper, then when they were completed the information was put on a spreadsheet, and a crystal report used to interrogate the spreadsheet). This system is working fine and we are getting results.

Now comes the tricky part. Whilst this system works fine, we find we are still getting all manor of interruptions from our users. Typically as we are in one building if someone wants something they will come and interrupt us no matter what we are doing. We also get phone calls from people working from home and from our consultants on site.

I want to reduce the number of interruptions by getting the users to fill in our IS support request form as opposed to us writing it in after they have explained the issue. Now in theory this sounds like a good idea but I have the following questions:

Will the users fill the form correctly and give enough information?
Will the users complain because they will need to fill in the form for every request?
Will this stop those stupid issues where “user X has asked you how to bold text for the 10th time in Word”?

The culture in the office at the moment is that we can be interrupted anytime/anywhere, but I wish to change that!

Any comments experiences regarding the introduction of support systems will be much appreciated as this is going to affect the whole company, so I have to get this right.
 
Hi Chris,
First of all I wish you luck with the new system - it is never easy to implement something new, believe me! I hope you have strong support from your management, because without that your task will be much more difficult.
Now to your questions:
Will the users fill the form correctly and give enough information?
That depends on how well the form is designed - you must ask for the information you need, don't depend on the users!
Will the users complain because they will need to fill in the form for every request?
Almost certainly, and this is where you need the support of your management, to make it clear to users that without filling in the form they will NOT have their request answered. Once they realise that, they will (reluctantly) fill in the form.
Will this stop those stupid issues where “user X has asked you how to bold text for the 10th time in Word”?
For this I would suggest preparing a "cheat sheet" containing answers to commonly asked questions - then when the question is asked again (and it will be!) you can simply refer the user to that sheet.

Again, best of luck, I'd be interested to hear how you get on with it.

John
 
I'd also take johnstrang's suggestion further and make the cheat sheet / FAQs available, either through a read only file on a network share with an easily accessible name (eg drive Z) or as a HTML file on your intranet.
Be certain to keep this up to date with the latest tips and tricks that you feel are worthwhile passing onto those you support, and create another one of technical tips/hints for yourself and colleagues.

John
 
Hello

I'm currently also supporting 50 users or so, and this is what I think:

Will the users fill the form correctly and give enough information?

My experience with the subject is that even if you are face to face with some users, it takes several questions before you can get to the core of the problem.

user: "Hey mim, I have a run-time error!"
Mim: "Which program was it? What kind of error?"
user: "It was such-and-such program. I clicked the error away. I think it was an error with number 3021 or so."
Mim: "What did the error say?"
User: "Euh, I don't know"
ect ect...

I think mostly in the beginning (when you will be introducing these forms) these situations will occur (when you will have to give a call to the user to get more information), but in time they will learn how to use it well.

Will the users complain because they will need to fill in the form for every request?

Same thing as above, I think they will complain, but at the end use it as they are supposed to be.


Will this stop those stupid issues where “user X has asked you how to bold text for the 10th time in Word”?

These issues will decrease, but not completely stop I'm afraid. (but decrease would also be fine :) )
What does improve the situation is a sepparate it-office. I am in an office together with accounting department and others, when they have a problem sometimes they just yell "Hey, I've got a problem" all accross the office (and it is no fun).


Anyhow, I think that the support system is a very good idea, but it will take some time before everything runs smoothly.

HelpDeskGreetz

VBMim
 
An FAQ-page or document is indeed a very good idea...
 
chriscboy

We recently moved to an on-line ticketing system using Lotus Notes database as the back end / front end.

The ticket form can be filled in from Lotus Notes or from a browser.

Although Lotus Notes databases are not relational (boo, hiss), it allows us to validate or authenticate the ticket, time stamp and route it to the appropriate support solution. We even have it paging out to the tech.

The user can place their trouble ticket from their desktop. If their desktop is not working, a collegue can place the call on their behalh, or the user can can the person managing the system.

From the user's perspective, it is very easy to use. "HelpDesk" usage went way up after moving to this system compared to an outsourced solution. Why, because it is easy to use.

From a manager's perspective, it gives you an idea on the volume of calls, volume of calls handled by each tech., time to resolution, time between creation and resolution or acknowledgement, etc. And it can give you the pulse of the IT system -- what is breaking? where am I spending my money?

You may not have Lotus Notes at your site. I do know it is possible to implement other systems from Microsoft Access to MS SQL server solutions that can also pop mail to support. Advantage here is that you can use a relational database, but then you are integrating systems which require more technical expertize.

Parting words...
Regardless of the system, it has to be easy (super easy) to use for the end user. Otherwise work-arounds will be developed. Oh no, now you have the techs entering the ticket info because the simple user was overwhelmed by the intricate complexity of the system.

Make sure you track the information you need to merit the effort in using the support database.

Make sure the database can adapt to the changing environment.

It helps if the support database is tied to an asset management system. User Jackie Smith has computer ABC123. Hmmm..., computer ABC123 has been crashing a lot lately. Or Jackie seems to have a lot of procedural problems. Or server LegacyNT01 seems to need a lot of reboots.

Going back to the keep it simple thought, the user should not be expected to tie in to the asset management system -- what asset tag? can't find it in the current database? -- Let the support tech tie in the data if necessary.

Good luck
Richard
 
I wish you luck! I hope this works out for you. After moving to a ticketing system, I've not only been able to show my supervisors what I do all day, but it also shows them what the other users are up to. When they see that one person needs help on an hourly basis with the same thing over and over, they can offer that person a chance at some additional training. They can also see who needed help with things beyond their job scope, or with things they didn't need to be into to begin with.

The fun part is getting the whole system going to begin with :)
 
Thank you all for your comments.

johnstrang,jbarnett
Good idea about the FAQ. I have one for common support issues for our PDA users, but didn’t think about the rest!

ALL
I had a team meeting today and discussed the roll out of the support system with my manager, a few users and the rest of the tech team.

We discussed various options and my manager has told me to action the support system in the following way:

1) All support issues must be raised by a phone call or by a support request form only. If a request is made via e-mail, a tap on the shoulder, or any other means of communication, it will be rejected.

2) IS Support then listens to the user request and decides if it needs to be actioned immediately. If it is, IS Support will fill in the support request, then fix the issue immediately. If the issue can wait, then the user must fill the support request and give it to IS Support in due course. The request will then get prioritised.

The reasons my manager wants to go down this route:

1) We can determine what the support issue is and write notes on the request form that is meaningful. (requests that say, “Word is broken” is not meaningful!)

2) Our users can still get an immediate response to important issues and they won’t have to fill a request for every support issue they raise. The users won’t feel like they are getting strangled with red-tape but will realise that our company is getting bigger and support needs to be monitored and measured to provide a better service in the future to our internal clients.

3) This will stop those interruptions that myself and the other tech person keep on getting, thus improving our productivity (unless the support request requires our assistance!).

What do you think of this? I personally wanted to get all users to fill in the form, but my manager believes the users would start get frustrated at doing this and we would end up with complaints from other departments. (Something we have not had yet, as we are very good at supporting our users (at the cost of new development)).
 
Don't forget to include closeout data. You might want to consider having on the form a place for the user to sign and date indicating that the issue has been resolved.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein
 
No matter how well a form is designed you can never make it foolproof...fools are so ingenious. [tongue]

If you ask them to describe the problem, it normally comes back with "My computer doesn't work" or something of that sort...either that or a long-winded description of what they think the problem is which turns out to be nothing even closely related.

These same people never read FAQ's, no matter how many times you give them the list.

As for the "Bold text in Word" syndrome, I had one secretary ask me four times in the same day how to make an attachment to an e-mail. [gorgeous] This is the same one that saved a blank spreadsheet with the same file name as one she had worked on all day. "What do you mean it's gone????"

I have found that having a form for them to fill out DOES help track incidents and justifies my existence here...I just have to make sure I add my comments to the forms to explain what the problem REALLY was.

::)
 
Chris

Not sure what you are intending to write the issue tracking system in, but there are a few things that you can do to help complete the job form if you are using a Windows application:

1. Use API calls to retrieve the user's login ID and computer name, and store these in hidden fields on the form. This means that you can register it against known issues with a PC or individual staff member.

2. Using either the PC name (by desk) if hotdesking, or tying an LDAP directory if you have fixed desks to login ID, you could pick out a telephone number and their full name.

3. Date/Time can be picked up from the computer's clock.

Present these as defaults, but let them overwrite it if they are reporting a problem on behalf of somebody else. Therefore, the only items that would need to enter would be specific items relating to their problem, but it does require an integrated system.

John
 
I built a project priority system for one company and here's how it worked..

Anyone on staff could report a problem or request a job.. I and a few staff members got an email when something was posted.. Any of these people emailed (including me) could assign a priority to the post and anyone could close or re-open a post..

I ordered the posts by closed/open, priority (descending) and date, descending.. It was a nice crisp system.. When people still called me up rather than post, I had a word with management and it became company policy that short of the network being down, all projects were posted there.

I did get posts like "I can't change the description of x item." And I simply responded either one the board or by phone call or however I chose asking for more information (the chosen method was based on how much the issue would affect things, if it was urgent, I made a call, if it wasn't I replied on the baord).

But my attitude simply was that posted projects got priority and that short of a serious error, projects not posted were for when I had nothing else to do.. They learned quickly that in order to get my attention and to stay in Management's good graces, use the board.

Also had a serious issue with people asking me for something and then later denying it.. With this method that no longer happened.. noone had anyone's password but their own so that if they wanted something they asked for it and Mgmt saw everything I was assigned by anyone.

ALFII.com
---------------------
If this post answered or helped to answer your question, please reply with such so that forum members with a similar question will know to use this advice.
 
Hi,

I had the same problem, but it was just me as the IT guy. I ended up creating a web based ticketing solution. This way I could enforce certian fields, (such as a drop down list of the program they were having problems with) and I did as John suggested by pulling username, computername and date/time from the local computer.

This intranet solution was a frontend to a Access database which I had fired up with a nice GUI to allow me to view the calls and run off reports.

If the user couldn't get to the Intranet I know it's quite a big problem, so I let them come to me and fill in a support request after.

I also found a groovy Javascript search engine that I put on the intranet which allows users with application problems to search for a solution. There is over 100 articles in there at the moment and getting regular use from the users.

Hope this helps,


Steve.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top