IT request form template: which fields should an IT support request form have?

An IT specialist’s morning often starts with this sentence: “My computer isn’t working, can you take a look?” Which computer, since when, what kind of error, what else has been tried, how urgent is it? The specialist has to ask these questions; by the time the employee has answered, two rounds of messages have gone back and forth and work on the request has not even started. The job of an IT request form is to ask these questions up front and collect the answers in the same order. Below you will find which fields are needed, what changes by request type and how to move the form from paper or Word into a tracking system.

“My computer isn’t working, can you take a look?” — To whom, since when, which device, what error, how urgent: none of it is clear.

An IT request form is the form that records the fault, access, software or equipment request an employee sends to IT, with the necessary information and in the same order every time. It is also called an IT support request form. A good form lets the specialist start work without asking follow-up questions.

The six questions specialists keep asking are the backbone of the form

• Which device or system? Asset tag number, computer name or account name.
• When did it start? When the problem was first noticed; it may be related to an update, a move or an installation.
• What do you see? Error message, description of the behaviour, a screenshot if available.
• What have you tried? Steps already taken, such as restarting or switching to another cable.
• How urgent is it? Does it stop your work or slow it down? How many people does it affect?
• How can we reach you? Extension number, department and the hours you are available.

IT request form example: field table

Completed IT request form example (fictional)

When the field list feels abstract, a completed sample form shows how short it can be:

This form takes half a minute to fill in, and before going to the printer the specialist can already suspect a sensor fault rather than a jam. There is no need to ask the employee a single question.

Should the IT fault request form be the same as the form for other requests?

The common fields stay the same, and a few extra fields are added depending on the request type. Making employees fill in the same long form for every type wears them out; showing only the relevant extra fields keeps the form short.

In what order are requests handled?

Two fields on the form, urgency and number of people affected, almost set the priority by themselves. The small matrix below shows how these two answers can be turned into a priority class (the classes are examples; change them to suit your own setup):

The matrix takes the “which one matters more” burden off the specialist who has to rank two requests arriving on the same day, and ties the employee’s choice to an objective rule. It also reduces the problem of everyone ticking the “urgent” box.

What happens if the form circulates in Word or by email?

In a one-person IT department with a few requests a week, a Word form works; nobody has to learn a new tool. The problems start when requests multiply: employees leave a required field blank and the form comes back, the same form circulates in different versions, a request lands in several people’s inboxes and it is unclear who is handling it. Requests cannot be queued either, because there is no shared field to separate the urgent from the routine. At the end of the month, you have to open the forms one by one to count how many faults came in. That is why the form should be designed not as a file but as a structure that creates a record every time it is submitted.

Who manages the form, and when is it updated?

Once the form is set up, it should not be left without an owner. Name one person as the form owner; from the first weeks, collect the questions specialists still ask and the fields employees keep leaving blank. Remove a field that is never filled in, and add the topic the specialist keeps asking about to the form. When a new device type, new software or a new access process is introduced, update the relevant section of the form too, so the form does not lag behind changes in the company.

IT request tracking system (help desk): from form to record

A request tracking system turns the fields on the form into a record. The request type maps to a category, urgency to priority, department and requester to assignment, and the description to the basis for the solution. In the IT Support / Help Desk module of YazSis KurumsalPortal, the request is opened as a ticket; computer, software, printer, user account and network requests are classified by category and priority, assigned to the relevant specialist team, resolution time and SLA are tracked, and satisfaction is measured at closure.

Moving from a form to a tracking system gives you these concrete gains:

• Every request becomes a numbered record the moment it is submitted; no form gets lost.
• Category and priority result from the answers on the form, not from the specialist.
• Who has the request and what stage it is at can be seen from its status.
• Resolution time and satisfaction are measured at closure.
• Recurring requests on the same topic become visible, and a solution note can be added to the knowledge base.

There is a practical approach for the device field on the form: the Asset & Assignment Management module of the same portal keeps every fixed asset under a unique asset tag number and shows its owner, location, status and movement history on its card. When the employee writes the asset tag number in the request, the specialist can easily reach the device’s card. We do not claim that an automatic link is created between the request and the device record; for now, this is information written in the request description.

Once you have prepared your form, see the IT Support / Help Desk page to view the flow, and the Asset & Assignment Management page to see how device records are kept.