Isn't software support great? It's one of the few ways possible to make your problem someone else's! But when you've got one of those problems, you usually want it to be worked ASAP. Here are 4 tips to help your ticket go through as quickly as possible.
1) Have your artifacts handy
By 'artifacts', I mean logs, core dumps, mangled transaction prints, etc. If these things are not attached with your original ticket, there's a pretty good chance your first contact from the support engineer will be a request for you to go get them. Meanwhile, while you're off gathering those things your engineer isn't idly standing by-- he's off working another ticket! When your artifacts finally come in, the engineer may or may not be ready to put down that second ticket, you may have to wait. Avoid the asynchronous wait time associated with this first exchange-- provide them in the first place.
2) Open the ticket at the appropriate level of severity
Most ticketing processes involve a user-defined 'level' that indicates how important the ticket is to the holder. (Usually severity 1, or 'sev one', is the highest.) It's tempting to mark every ticket you enter as a sev one, but guess what happens if your development-environment problem isn't really the production-crash that sev one defines? (Check your support agreement to see what the definitions are.) Your ticket will be examined, re-prioritised, and put in a lesser queue. So you lose time 'till that first evaluation, your ticket is delayed going into the proper queue, and you may establish a reputation as a less-than-honorable ticket opener. (That last one is a bad one. Read on....)
3) Playing nice pays off
Often times there are more tickets than support engineers available, which means sometimes the engineer gets to decide which ticket to work first (all other things, like severity, being equal). In situations like these, the 'tone' of the ticket can make a difference. A polite and professional ticket tells the reader that the sender is a savvy user that's ready to collaborate and address the issue. On the other hand a defensive or accusatory note might signal an uncooperative sender. Which would you rather work first?
4) If at all possible, replicate the problem in a minimal environment
This is a big one-- if at all possible, encapsulate the problem in a minimal environment and attach it to the ticket. If your problem lies in a Spring application, isolate the offending components and attach them with an application context to run them. If it's a problem with JSF, build the smallest .war possible that shows the problem and attach the artifacts necessary to build it. It's not always possible, but when it is possible this really helps the engineer! Your ticket will be promptly picked up, and the problem will be put under the best microscopes the engineer has available.
That's it-- follow those 4 steps and your ticket will proceed at max speed.