Hi!
Not really code specific but does anyone know anything about "trouble tickets" or "problem tokens" used in helpdesk applications.
I only get manufacturers' marketing rubbish when I try any searches
:(

Any ideas would be a help :D

Simon

__________________
You want it in half the time? That\'ll be twice as much...

What exactly are you looking for? Do you want to buy a system? Are you looking to design a system? Or are you having trouble with a current system?

Yehuda

Hi Yehuda
I'm building a helpdesk application in which a trouble ticket mechanism is required. To be fair I'll probably use a link table in a database to act as the ticket to be passed between engineers and just update the details there. However, I feel i don't really know enough about token / tickets to just dive in and do without at least a bit more research into the problem area.
I was really hoping someone might have either had a bit of experience in this field or could point me in the right direction.

Cheers
Simon

While I have never worked with trouble tickets, the first place I would look is the engineers who will be filling them out. Ask them what they need. Ask if they have a copy of whatever they have been using until now to show you. My hunch on the architecture is that it will be a form front end. The information will be sent to a back end database through a business layer. The ticket will be able to be read from a queue. This is a rather basic three tiered application structure. While I have not handled support tickets for help Desk I have written applications to do similar things.

Cheers yehuda, I'll do that. I don't think it's the sort of app that can be written in a non-specific manner, the chaps using it don't really know what they want other than to be quicker than the mainframe app they have at the moment :)

That's the easiest project specs. All you need to do is analyze what they have and build something similar. My advice from similar situations, if possible when you get to the testing phase try to get some of the engineers who use the system to look it over and give feedback. To often projects are tested by the managers who gave the specs not by the users who will need to use the system after all is said and done.

hi there..

if you want another piece of advice, try to be there when they do their actual work..

look how they enter the data into the program.. see how they manage to memorize codes or lost a lot of times finding data..

the best thing you can do is sit behind one or two of them.. an see how they really work...

never, never, trust in the way manage said thing should be do.. probably the people using it do it the opossite way...

Gonzalo Bianchi