Small IT teams almost never start with a ticket system. They start with a shared mailbox, a chat channel called it-help, and somebody's memory. It works while the team is twenty people. Somewhere past fifty it stops working in a specific way: two people answer the same message, a request from three days ago is found unread, and nobody can say whether the printer problem on the second floor was ever resolved or just went quiet.
The usual next step is a service desk suite, priced per agent and built for a process larger than the one being run. Between the mailbox and the suite there is a middle option that gets overlooked: an intake form whose responses carry an owner and a status, so the ticket has a place to live without a full ITSM implementation. What follows is the field list for that form, how to set priority without a matrix nobody reads, and what the reply side has to do.
What a ticket has to contain to be workable
A help desk request is workable when the person picking it up can either fix it or ask exactly one question. Most requests arriving by chat fail that test, and the reason is consistent.
What was being attempted, not what failed. "Outlook is broken" describes a feeling. "Sending an attachment over about twenty megabytes fails with a message about the item size" describes something that can be checked. Asking for the action separately from the symptom gets both.
The exact wording of any message on screen. Paraphrased errors send technicians down the wrong path. A field asking for the message word for word, plus a screenshot upload, resolves a large share of requests without a second exchange.
Which machine, and which account. Requests come from people, but faults live on devices. Asset tag or machine name, operating system, and whether the person is on the office network, at home, or on a phone. Where an asset list exists, a fixed choice field beats free text because free text produces answers along the lines of "the laptop in the corner office".
When it started, and what changed. The pair is more useful than either half. Something that started on Monday morning after an update is a different investigation from something that has never worked for a new joiner.
Whether it happens every time. Reproducible faults get fixed. Intermittent faults get logged and correlated, which requires the request to say which kind it is.
Those five cover most of the diagnostic ground. Everything else is routing and priority.
The fields that decide where it goes
Category, kept short
Six to nine categories is the range that works: account and access, hardware, software, printing, network and connectivity, email, phone, security concern, something else. Long category lists get picked at random. The category exists to route, not to classify for a report, and a monthly review of the something else answers tells you which category is missing.
Impact and urgency, asked separately
Ask how many people are affected and whether work is stopped. Those two questions produce a priority without asking the requester to choose a priority, which matters because a requester asked to self assess urgency will choose high. One person inconvenienced and a whole floor unable to print are not the same ticket, and the form should be able to tell them apart without anybody's judgement.
A security flag
One yes or no question: does this involve a suspicious message, a lost device, or a password that may have been shared. A yes routes immediately and skips the normal queue. This is the single field most worth adding to an existing form today, because the cost of a phishing report sitting in a queue for a day is not comparable to the cost of a printer ticket doing the same.
Contact and availability
Where the person is, and when they can be reached. Remote diagnosis fails more often on scheduling than on technique. A simple field for available windows removes an exchange of three messages.
Attachments
Screenshots, exported logs, a photograph of a physical fault or a cable. Uploads sitting behind a sign in are the right arrangement here, because screenshots of business systems routinely contain customer names and should not be circulating as email attachments.
The template, written out
Rebuild in any form tool. Twelve to sixteen questions is the working range, and conditional questions keep the visible count lower.
Who and where
- Name. Short text. Required.
- Email. Email. Required.
- Phone or extension. Phone.
- Location or site. Multiple choice. Required.
- Best times to be reached today. Short text.
The request
- Category. Multiple choice. Required.
- What were you trying to do. Long text. Required.
- What happened instead. Long text. Required.
- Exact wording of any message on screen. Short text.
- When did it start. Date.
- Did anything change beforehand, such as an update or a new device. Long text.
- Does it happen every time. Every time, sometimes, once so far. Required.
- Has it been reported before. Yes or no.
Scope
- How many people are affected. One, a few, a team, a site, everybody. Required.
- Is work stopped completely. Yes or no. Required.
- Does this involve a suspicious message, a lost device, or a shared password. Yes or no. Required.
The device
- Machine name or asset tag. Short text or fixed choice.
- Operating system. Multiple choice.
- Connection. Office network, home, mobile, not applicable.
Attachments
- Screenshot, photo or exported log. File upload.
Recorded by the team, not shown to the requester
- Assigned technician.
- Stage.
- Priority as set by the team.
- Cause, once known.
- Whether it belongs to a known wider fault.
- Time spent.
The last block is the part a plain form cannot hold, and it is the reason requests end up copied into a spreadsheet. A tool that keeps internal fields on the response itself removes that copy step, and with it the drift between the two records.
Priority without a matrix nobody reads
Most published priority schemes are a grid of impact against urgency with four or five levels and a target response time per cell. They are fine on paper. In a team of two, the grid is read once and then ignored, because the technician already knows which ticket matters.
What survives at small scale is simpler: three bands, derived from the two scope questions rather than chosen by anyone.
| Band | Derived from | Target first response | Typical content |
|---|---|---|---|
| Stop everything | Security flag is yes, or a site with work stopped | Minutes | Suspected phishing, lost device, network down, shared system unavailable |
| Same day | A team affected, or one person with work stopped | Within the working day | Cannot log in, no email, no access to a system needed now |
| Scheduled | One person, work continuing | Two working days, with a stated date if longer | New equipment, software installs, requests for access, questions |
Three bands hold up because each one implies a different action rather than a different number. The stop everything band is worth defining narrowly, and worth reviewing monthly: if more than a small fraction of tickets land there, the definition has drifted and the band has stopped meaning anything.
Mailbox, chat channel, form, or suite
The choice is usually framed as whether to buy a service desk product. The more useful framing is which of four things is holding the ticket.
| Setup | Strength | What it cannot do | Reasonable at |
|---|---|---|---|
| Shared mailbox | Nothing to learn, everybody already has it | No status, no owner, no way to see the queue. Two people reply to the same thread | Under about twenty five staff |
| Chat channel | Immediate, and people actually use it | Requests scroll away. No record that survives a month | Any size, as a front door only |
| Form with response management | Consistent fields, an owner and a stage per request, the reply from the record | Not an asset database, and no change management workflow | Roughly twenty five to a few hundred staff |
| Service desk suite | Asset links, change and problem management, formal reporting | Costs per agent and needs configuring and maintaining | Where formal service levels or audits apply |
The third row is the gap most small teams are sitting in without knowing there is an option. The requirement list is short: consistent fields, an owner per request, a stage the team can rename, internal notes the requester never sees, and a reply that goes out from the record so the sent message stays attached. The feature list worth checking against is exactly that, and no longer.
A note on the chat channel. Removing it rarely works, because it is where people actually are. The workable arrangement is to keep it as a front door and have whoever is on duty submit the form on the requester's behalf, or paste the form link with one sentence explaining that it is how the request gets tracked. Within a few weeks most people use the form directly.
The reply side, which is most of the work
Three messages carry a help desk, and all three can be automatic or near enough.
The acknowledgement goes out on submission, with a copy of what was written and a reference. Beyond confirming arrival, it lets the requester notice that they described the wrong machine, which happens often.
The status note goes out when the ticket changes hands or enters a wait. Waiting for a part, waiting for a vendor, and waiting for the requester to be available are three different waits, and naming which one applies stops the follow up question. Saved wording makes each of these a few seconds of work.
The closing message states what was done and asks the requester to say if it recurs. This is the message that gets skipped when the fix is obvious, and skipping it is why the same fault gets reported twice by two people. Sending it from the record keeps the answer attached to the ticket, which is what makes the second report resolvable in one minute instead of ten.
Where several intake streams run side by side, the same arrangement covers them all. The common patterns look much alike whether the incoming item is a help desk ticket, an equipment request or an application, which is worth knowing before buying a separate tool for each.
What a month of tickets tells you
Once a few hundred requests share a form, four counts become available and each one changes something.
Tickets by category shows where to spend a day fixing the cause. Printing and password resets are the classic pair, and both have structural answers.
Repeat requesters are not a discipline problem. Three tickets from one person about the same system usually means a device to replace or a piece of training nobody offered.
Tickets arriving outside hours tells you whether the current cover matches reality, which is the argument that either justifies a change in cover or ends the discussion.
Time from submission to first response, split by band, is the number that shows whether the priority bands mean anything in practice. If the same day band and the scheduled band have similar response times, the bands are decorative.
None of this requires reporting tools. It requires that every ticket went through the same form with the same fields, exported as a CSV.
What to change first
Add the security flag and the two scope questions to whatever intake exists now, because they change what gets picked up first and cost nothing to add. Then give every request an owner and a stage so the queue can be read without asking anybody. If the current mailbox cannot do that, see what a request with an owner and a stage looks like in a tool built around it, such as Halict.
Q1. Is a form enough, or is a real ticket system needed?
It depends on whether asset links, change management and formal service levels are required. For a team fielding requests from a few dozen to a few hundred staff, consistent fields plus an owner and a stage per request covers the actual need. Formal service level reporting and audit requirements are where a full suite starts to earn its cost.
Q2. How do you stop people asking in chat instead?
Do not stop them. Keep the channel as a front door and have the person on duty submit the form on the requester's behalf, or reply with the link and one sentence about tracking. Most people move to the form once they notice requests submitted through it actually get answered.
Q3. Should requesters set the priority themselves?
Asking them to choose a priority produces mostly high. Asking how many people are affected and whether work is stopped produces the same information without the self assessment, and the team derives the priority from the answers.
Q4. What belongs on the form that requesters should never see?
The assigned technician, the stage, the team's own priority, the cause once known, whether it is part of a wider fault, and time spent. These are fields on the record rather than questions on the form, which is why the tool holding the responses needs internal fields.
Q5. How many fields before people stop filling it in?
Around sixteen visible questions is the practical ceiling for a help desk form, and conditional questions keep most submissions well below that. The faster route to compliance is a short form plus one follow up question when needed, rather than a long form that gets abandoned.