IT Support Ticket Template for Small Business Teams
A useful IT support ticket explains what stopped working, who is affected, when it started, and how support can reach you. You do not need to diagnose the fault. Clear observations are more helpful than a confident guess about a broken server.
This template is for employees and managers reporting an issue through their company's approved support channel. It works for a small office, a retail location, or a distributed team. Copy the fields below into your existing ticket form or support email, leaving anything you cannot confirm marked “unknown.”
Before filling out a routine ticket
If there is suspected account compromise, a suspicious payment request, or a business-wide outage, use your organization's urgent reporting route immediately. A complete form should not delay escalation. For a suspected mailbox takeover, our business email compromise checklist explains the information to preserve and the decisions an administrator needs to make.
For routine faults, save your work if possible and record the error before making changes. Do not repeatedly restart shared equipment, reset network devices, install repair utilities, or disable security controls. Report what you have already tried, including whether it changed the symptom.
Copyable IT support ticket template
Use a short subject such as “Brooklyn office — accounting app cannot export PDFs.” Keep this template in an internal document so staff do not have to invent a report during a busy shift.
Subject: [location or team] — [system] — [specific symptom].
Business impact: [task blocked, number of people affected, and whether work can continue].
Location: [site, department, floor or remote-working context].
Device or application: [asset label, app name, and version if readily available].
First noticed: [date, time, time zone, and whether the issue is still happening].
Last known working: [approximate date/time, or unknown].
Expected result: [what the normal action should do].
Actual result: [what happened instead, including exact non-sensitive error text].
Steps leading to the issue: [brief sequence; do not repeat unsafe or chargeable actions].
Scope and comparisons: [one person/device or several; what still works].
Actions already taken: [approved steps and the result of each].
Evidence attached: [cropped screenshot or relevant log excerpt, checked for sensitive data].
Timing and workaround: [real deadline, temporary alternative, or no workaround].
Contact and availability: [approved work contact, availability, and time zone].
Not every field needs a long answer. “Unknown” is better than an invented version number or an assumption that everyone is affected. Use your internal asset label rather than attaching an entire equipment inventory.
Write observations, not a diagnosis
“The internet is down” could mean one website fails, one laptop lost Wi-Fi, or every workstation is disconnected. Instead, describe a small comparison: “The inventory application will not load on the front counter laptop; the back-office computer opens it normally.”
You can also distinguish an action from its outcome: “I selected Export, expected a PDF download, and received an error before any file appeared.” Atlassian's bug-report template uses the same useful distinction between reproduction steps, expected behavior, and actual behavior. You can apply that reporting structure without buying a new ticketing platform.
Only repeat a step when it is safe. Do not rerun a card payment, delete a record, or trigger a bulk email just to demonstrate an error. State that you stopped and ask support how to capture evidence safely.
Attach evidence without exposing private information
A screenshot should show the relevant error, not your entire workday. Close unrelated windows and crop away customer records, payment details, private messages, and other information support does not need. Never include passwords, verification codes, recovery keys, or session tokens in the ticket.
On Windows, Microsoft documents Windows key + Shift + S as a way to open the screenshot overlay. Its Snipping Tool guidance also describes capture options and text redaction features. Review the finished image yourself: automatic redaction is not a guarantee that every sensitive detail has been removed.
If the error contains confidential information, describe the symptom and ask for an approved secure transfer method. Do not upload screenshots or logs to a public file-sharing service merely to make a ticket attachment easier.
Two fictional examples you can adapt
Office example: PDF export fails
Subject: Brooklyn office — accounting app PDF export fails.
Impact: One employee cannot generate the monthly report; other accounting work continues. The report is needed tomorrow afternoon, and no approved export workaround is known.
Observation: At 10:15 a.m. Eastern Time, selecting Export PDF displayed “Export could not complete.” The same report exported yesterday. The employee has not retried using real customer data or changed application settings.
Evidence and contact: A cropped screenshot excludes account names and balances. The employee is available through the approved work contact between 11 a.m. and noon.
Retail example: one checkout station is offline
Subject: Store front counter — checkout station 2 cannot connect.
Impact: One of two stations is unavailable; station 1 is still operating. The manager is redirecting customers to the working station.
Observation: Station 2 showed a connection message at opening. The manager recorded the device label and message, but did not reset the router, disconnect payment equipment, or repeat transactions.
Evidence and contact: The attachment excludes customer and card data. The manager can provide supervised access during the agreed support window.
These are reporting examples, not client stories or promises about response times. Your provider's support agreement determines urgency categories and service commitments.
Keep updates and closure useful
Reply to the existing ticket with new observations instead of opening duplicates for the same incident. Include the time of each update. If a workaround fails or more people become affected, say so explicitly; the original impact statement may no longer be accurate.
If support needs to visit, use the on-site IT visit preparation checklist to organize access, an authorized contact, and a practical test window.
Before closing the issue, test the business task that failed, not just whether a screen opens. Confirm the relevant report exports or the approved checkout test succeeds. Record any remaining limitation so a partial workaround is not mistaken for a complete repair.
Make clear reporting part of everyday support
A consistent ticket template gives your support team a better starting point and gives employees a simple way to ask for help. Keep the approved reporting channel beside the template, explain the urgent route, and review one example with new staff.
For help supporting your business's day-to-day technology, explore Sosa Solutions NYC's managed IT services.
Comments