Plan your tech groups and request types
As you plan request types for your organization, consider the following guidelines:
Hide internal request types from clients to avoid confusion.
Some request types are used only by techs (for example, a request for a system to be shut down for maintenance).
Create client-facing request types that reflect the client's (and not the tech's) point of view.
Name request types to reflect the problem or symptoms the client sees, not the solution or the underlying technical cause. Be sure to avoid specialized terms that clients would not know.
Use nested request types to subdivide broad parent categories.
Request types can have multiple levels. Nested request types can be used to:
- Provide more specific categories for reporting or categorizing FAQs.
- Route tickets to different tech groups. for example, Facilities > Plumbing and Facilities > Landscaping could be routed to different tech groups.
- Hide technical subcategories from clients. For example, a parent request type called Computer Problem could have nested request types to describe specific types of problems (such as VPN Connection Issue). These nested types are hidden from clients to avoid confusion. Techs can use them to provide more accurate reporting on the types of issues users encounter.
Do not make your system too complicated or granular. Create only the types you need to route and categorize requests.
Users can have difficulty selecting a type when there are too many options, and choose a generic type such as Other. If in doubt, start with fewer types and add more if needed.
Before deploying the request types and tech groups in a production environment, test all request types in a QA or development environment. Verify that each request type is routed to the correct group.
Map request types to tech groups
Create a list of your organization's request types, and map them to the tech groups who can support them. The following table provides an example of groups mapped to request types.
|Tech Group||Request Types|