If you have ever worked in an office, it is likely that you will have had at the very least indirect dealings with an IT service management system or process of some sort. Maybe you needed to get some software installed or a new keyboard.

If you have ever called the help desk to get some software installed, you might know what I'm talking about. The help desk analyst will take your details and raise a request ticket using an IT service management system. This is supposed to start a workflow that will route your request via various approvals (perhaps your manager and someone who has to ok any capital expenditure) to the team that can install the software, who will in turn push the application onto your desktop. Then, several days go by and your software still hasn't been installed and you have to call again. If you're lucky, you might have an email with a ticket reference number so that the helpdesk operator you speak to this time can track the progress of your request. If you're really lucky, you might even have access to the ITSM system. It may tell you what stage your request is stuck at but it may not tell you who is supposed to be working on it or what needs to happen next for your request to progress. This is a common complaint.

To contrast this with a slightly different scenario, at a smaller company, making a call to the help desk might go a little like this. You pick up the phone and call the help desk - you probably know the person who is going to answer as it's always the same person. He or she will come over to your desk sometime that day and help to sort out your problem. If it gets forgotten about, you call back to see what is going on.

The important difference between the large company scenario and the small company scenario is that the end user knows who is dealing with their issue. In a large company with a help desk covering a lot of users, the help desk doesn't want the end user to know who is dealing with their problem for a few reasons.

Teams are often small and managers don't want a single team member to become a bottleneck. Sometimes any team member can process any ticket.
Team members can be distracted if users can call them up directly and ask why their request has not been done. Having to field these calls can interfere with the team's priorities. Fielding these calls is the job of the help desk.

There are various off-the-shelf systems available to assist with service management: Remedy, HP service centre. Whilst the products themselves are very flexible and allow companies to customise them in every possible way to suit business needs, often implementations leave a lot to be desired.

The truth is - the choice of service management system is not nearly as important as having a clear IT service management process that is understood well both by staff dealing with the requests and end users requesting services. There are several key points that are helpful in setting up a successful service management process:

Responsibilities must be clear to all: the person responsible for the next action in any given ticket should be clear both to that person and to the end user. This way if the request is particularly important for the end user, they can chase it directly and escalate it if required.
Be transparent about priorities: users must appreciate that there has to be a priority order for the processing of tickets. Email support staff will clearly have to fix a broken email server which is affecting many users before they will be able assist a single user by installing a new email client plugin.
Clear escalation process: if the user needs a request to be carried out urgently due to a pressing business need, the process for doing so should be clear. This helps both IT staff and end users to prioritise correctly. Escalation should also carry some sort of approval or justification step so that tickets are only escalated for genuine reasons rather than simple impatience.
Understand request processing times: if the team can keep all eleven users happy by spending twenty minutes processing ten low-priority requests before then processing a single high priority ticket that might take two or three days, it is probably sensible to do the low priority requests first as they won't take much time and it gives a better impression if users generally get a fast request turnaround.