IT Ticket Template: Intake Forms For Every Request Type

An IT ticket template is the short form a user fills in to ask IT for help. It asks who they are, where they are, what broke or what they need, and how badly it stops them. Copy a general version and five per-type versions below.

They come from the team behind SherpaDesk, a helpdesk and professional services automation (PSA) tool a small IT team can run alone.

Key takeaways

• Every field needs a job. If nobody uses an answer, delete the question. Why it matters
• One form per request type. An access request needs an approver; an outage needs a callback number. Copy the templates
• Ask for facts, not priority. Scope and workaround as fixed choices beat "ASAP". Best practices
• Plan for email. A subject tag such as [Access] carries the template when users skip the portal. Form or email

What Is An IT Ticket Template?

It's the set of questions a requester answers when they open a ticket, in a web form, a portal, or an email. Per-type versions add what one kind of request needs, such as an approver for access.

It is not the reply your technician sends back; those are our support ticket response templates. It also stops before routing: once the ticket exists, ticket triage sets its class, priority, and owner.

Why Intake Templates Matter On A Small Team

A missing answer costs a round trip: the technician asks, waits for a reply, and the ticket sits.

GOV.UK form guidance starts with one rule: know why you ask every question. The NHS service manual turns it into a test. Among other conditions, keep a question only if you need the answer to deliver the service, know why, and know who uses it and how.

One r/helpdesk poster described the pattern: "a manager submits a request saying 'give Bob the same access as Sarah,' and on the surface that sounds dead simple." It isn't. The poster's team is two people at a 150-person organization. They get "2-3 of these a week, each one eating 20-40 minutes of clicking through Okta and chasing down manager replies."

Asking for system, access level, and approver up front answers those questions first.

Copy The Templates

Copy one block, or download all six below. Keep the [Tag]; replace text in {braces}. Every line that applies is required unless it says "(optional)", as the NHS and U.S. Web Design System advise for optional fields.

1. GENERAL REQUEST
Subject: [Help] {what is wrong or needed}
Your name and callback number:
Site, building, and room:
What do you need, or what is not working?:
Since when, or needed by when?:
Who is affected? (me / my team / everyone here):
Can you keep working another way? (yes / no):
Device name or asset tag, if a device is involved
("can't find it" is fine):
Exact error message or a screenshot (optional):
What you already tried (optional):

2. ACCESS REQUEST
Subject: [Access] {person} - {system} - {date needed}
Person who needs access (name and email):
System, app, folder, or mailbox:
Access level (view / edit / admin):
Why they need it (task or role):
Approver (manager or data owner):
Needed by (date):
End date, if temporary (optional):
List each system. Never write "same access as Sarah".
Never put a password in a ticket.

3. NEW DEVICE OR HARDWARE FAULT
Subject: [Device] {asset tag, or "new"} - {what is needed}
New device, or fault with a device you have?:
Site, building, and room:
Fault: asset tag (sticker on the device):
Fault: what happens, and since when:
New device: who it is for, and needed by when:
New device: software it must run:
Cost approver, if your policy needs one (optional):

4. SOFTWARE INSTALL
Subject: [Software] {app name} - {person}
Software name and version, or a link:
Who needs it, and on which device:
What it is for:
License: already bought / needs buying / free:
Approver (manager or budget owner):

5. OUTAGE: SOMETHING IS DOWN
Subject: [Down] {system} - {site} - {since what time}
What is down:
Site or building:
Since when:
Who is affected? (me / my team / the whole site):
What you see, or the exact error:
Can people work another way? (yes / no):
A number we can call for the next hour:
If a whole site is stopped, also call (IT: add your number).

6. NEW HIRE, LEAVER, OR ROLE CHANGE
Subject: {one of [New hire], [Leaver], [Role change]} {name} - {date}
Change (new hire / leaver / role change):
Full name, job title, department:
Manager who approves access:
Date the change takes effect:
Leaver: last working time and time zone:
New hire or role change: accounts and groups to add:
New hire: device and software needed:
Role change: access to remove:
Leaver: who takes over their email and files:
Leaver: equipment to collect:

Why Each Field Is There

Each required line answers a question the first technician would otherwise ask.

The triage owner confirms scope and workaround and sets the priority from them, as in our ticket priority levels guide.

Access requests

The approver line exists because access is approved before it's granted. NIST's account-management control requires approvals, by people or roles the organization defines, for requests to create accounts. "Access level" and "why they need it" follow NIST's least privilege control: only the access needed for assigned tasks.

"List each system" answers the Sarah problem. One commenter in that thread rejects such requests: "We don't allow it, cancel out the request and reach out to the submitter. They must be explicit in their access requests."

Devices and software

A fault needs the asset tag, so the technician sees the device's history first. A new device needs the person, a needed-by date, and software.

Software gets an approver and a license line because it's a security and budget decision. CIS Control 2 aims for a network where only authorized software is installed and can run. NIST asks organizations to set policies governing software installation by users.

Outages

When something is down, speed beats detail: what, where, since when, how many people, and a number to call. "Since when" lets the technician match the start to a change or an alert.

New hires, leavers, and role changes

These requests carry a date and a manager, both required. NIST's termination control includes keeping access to information the leaver controlled. Hence "who takes over their email and files". For a transfer, NIST asks you to confirm current access is still needed, so role changes list access to remove.

Good And Bad Filled-In Examples

The same requests, written badly and written to the template.

A complete access request from a 40-person accounting firm:

Subject: [Access] Dana Ortiz - Finance drive - March 2
Person who needs access (name and email): Dana Ortiz,
  dana.ortiz@example.com
System, app, folder, or mailbox: Finance shared drive,
  folders AP and Vendors
Access level (view / edit / admin): edit
Why they need it (task or role): new accounts payable
  clerk, enters vendor bills
Approver (manager or data owner): Sam Patel, finance manager
Needed by (date): March 2
End date, if temporary (optional): none

The technician knows what to grant, at what level, and who to ask for approval.

Best Practices And Common Mistakes

The NHS manual adds optional questions only when some users clearly need them. GOV.UK keeps help text next to its field and brief, since people rarely read past about three lines. NIST lists protecting authenticator content from disclosure as part of authenticator management.

On urgency, one r/helpdesk commenter asked of a bare "ASAP" ticket: "is this a 2 min fix or a system-wide fire?" Two fixed-choice questions, scope and workaround, answer that better than a priority box.

Turn The Templates Into A Web Form Or Email

Plan for both. One r/ITManagers member said: "We have a portal that no one uses. If we required the portal, they'd send messages in Teams, call, or text. They will always use the easiest path."

1. Build one form per request type

   The user picks "Access request" and sees only those questions. Group related ones, as the U.S. Web Design System does with fieldsets.

   Common mistake: one long form with every question, half of them skipped.

2. Write hint text from last month's weak tickets

   Find the answers technicians had to chase most often and add a one-line hint to those fields only.

   Example: "The asset tag is the white sticker under the laptop."

3. Publish the email subject tags

   Users paste a block into an email. The tag shows the request type the user picked, and triage confirms the class.

4. Review the form after a month

   Look for fields left blank or answered with junk. If you don't know how you'll use an answer, remove the question.

For setting up support@ itself, see our email ticketing system guide.

Set Up Intake Forms In SherpaDesk

How this works in SherpaDesk

Each request type gets its own questions

You can make each template a class and link custom fields to it, so users see only the fields for the class they pick. Follow-up questions can sit under a field. Each custom field can show description text on the customer portal, which is where your hint text goes. Classes carry a description too.

If users email, forward support@ to a dropbox address and incoming emails become tickets. If you run your own portal page, you can pass values from it into SherpaDesk web forms. You can run it for your own staff or for the clients you support.

A helpdesk and PSA a small IT team can run alone. No contract. No implementation project. No dedicated admin. Base Camp is $45 per agent per month ($40 billed annually), the first agent is free, forever, and the trial is 14 days free with no card.

See SherpaDesk Ticketing →

Frequently Asked Questions

What should an IT support ticket template include?

What's the difference between an intake template and a response template?

How many fields should a ticket form have?

What if users email instead of using the form?

How do schools adapt these templates?