Request types provide the basic structure for routing tickets, providing approvals, generating reports, building workflows and displaying FAQs in Web Help Desk. They determine which custom fields appear on a ticket and which techs are assigned to the ticket through ticket routing. You cannot submit a ticket in Web Help Desk without a defined request type.
Request types can be defined as
parent and child types. For example, when a user requests a password reset, you can configure the parent type as IT Request and have its children as Hardware Support, Network Support and Software Support. You can even break it down further so that the child type Network Support will have its own children like In-Office Connectivity, Password Reset, Wireless Access, and so on.
Whenever you have a request type with children, it's called a sub-request type.
Every parent type may have a child, but it's not required. Since almost everything in Web Help Desk is derived from request types, it’s important to think about how you want them to relate to each other and to the overall flow of your ticket process.
To begin, build your parent types first and then add their corresponding child types. If you build a child type before you build the parent type, you can't set the child type as a child. It might be helpful to chart these relationships out in a spreadsheet first, so you don't miss something important. Request types will be used by all your users, as well as your technicians. So, the structure and types should reflect how users view problems they encounter. If the structure is too complex or unclear, users won't be able to figure out which request type to choose. It's also a good idea to provide one generic "problem" request type to capture unique requests or confused users.
When you
build your request types, be sure to think in the language of your end user, and not your techs. If you get too technical, the end user clients may get confused with selecting the appropriate problem. This also ensures that the ticket is routed to the correct team the first time. So, make it as user friendly as possible.
To manage request types, click the 'Setup' icon in the toolbar and select 'Tickets' and then 'Request Types' in the left menu. This will display the Request Types screen in the user interface.
In this example, the request types we've created are for Email Report, Facilities Request, HR Request, IT Request, Legal Request, SolarWinds NPM Alert, and Web. When I click the arrow next to IT Request, I can see the child request types: General, Hardware Support, Network Support, Software Support, and IT Project. The right arrow next to the Request Type name is an indicator that the request has a child. When I expand Hardware Support, notice other children show up. I can keep doing this until I get to the last child.
Let's create a new request type. Click 'New.'
Add a name to your request type. I'll name mine "Customer Support Request."
I'd like this to be a top-level or parent, so I won't choose a parent type. However, if I wanted to make this a child of another request type, I'd simply find the desired request type here in the Parent Type drop-down menu. That's why it's necessary to create the parent types before the child types. I chose a Tech Group here.
If you haven't defined your tech groups, you can always come back to this or associate it to the tech group within the tech group configuration settings.
A tech group contains a group of similar request types handled by a group of techs. In my case, I would create a tech group called 'Customer Support' and associate this and all other customer-related request types to it. This ensures that tickets with those request types are handled by the same group of techs who understand that area.
I'll leave Request Detail Required enabled. This forces the client to describe the issue in their own words.
You can restrict request types to techs, or to both clients and techs. Setting it to techs only would be helpful if you know the person reporting the issue will always be a tech. For example, if you need to schedule a maintenance window to upgrade the operating system on a router, the client doesn't need to see this request type. In this case, you would uncheck 'Visible to Clients.' But for my demonstration, I will leave it checked.
When enabled, the Use Models option prompts clients to select an asset or model when they create a ticket with this request type. Let say it doesn't apply to Customer Support. I'll uncheck it for my case.
You can extend the
request type visibility by location, department, or company.
This means that if a client selects a location or is assigned a location that isn't enabled for this request type, they'll never see it as an option.
For this example, I want this request type visible to all clients in my organization. So, I'll leave Companies, Locations and Departments defined for All. There's no need for an approval process for this, so we'll skip that.
Click the 'Lead Technician' drop-down menu and select the tech who'll receive the highest-level escalation after group manager. If you decide not to implement tech groups, the system will auto assign any tickets with this request type to the lead tech.
When you're done, click 'Save' to complete the request type setup.