How does your Service Desk know where to route incidents and requests?

[snevans]

I have a couple of questions.

Does your Service Desk use knowledge articles to know where tickets should be routed?
                    - If yes, how do you go about updating those when they assignment groups change?

If multiple assignment groups work on tickets (i.e. same configuration item), how do you separate those out? i.e. assignment group X works ONLY on the tickets where they have to actually contact the user with the problem; while assignment group Z works on code.

[darius_koohmare]

Generally I don't see customers putting 'escalation' or 'reassignment' instructions directly into knowledge articles.

The reason being is that if it's a standard enough process to be documented, you can probably use business logic through assignment groups/business rules to actually route incidents in the system based on current field values. Sometimes a new field has to be created (e.g. a true false for 'escalate', or 'internal vs external' designation), but in either case it can drive pre-defined business logic.

In terms of different teams accomplishing different functional tasks (e.g. communication vs code fix), consider having the primary incident assigned to the communication assignment group, with that team responsible for creating an incident task and assigning it to the development/code fix assignment group for additional technical support.

[dpalmer]

Hello Savannah;

        Knowledge articles are not always necessary as long as there is a good   level of understanding, support, and communication by a Support Center/Service Desk manager of what teams work on which issues. As far as multiple assignment groups, from my experience, tickets are routed to an assignment group for further investigation if they do not require any code/development changes. If an incident is called in that requires further changes or development to an application/CI, a problem will be opened for assignment group z that works on code, with the incidents linked to the problem. Those incidents can then be set to status "Awaiting Problem", and once the problem is closed, the tickets will be closed as well.

The process I have experience with includes:

User calls in for assistance from help desk;

If needed, ticket is routed to team responsible for CI

If team responsible for CI needs to apply code changes, a problem will be opened and assigned to ticket (a change control may be required as well)

If a problem does not need to be opened, however a different assignment group needs to work on issue, then the tickets are simply routed to the next team for review.