Submitting ICT support tickets
What is it?
Submitting an ICT support ticket is the formal process of requesting assistance, investigation, fixes or enhancements from an ICT support team or external vendor who supports a system, platform or application.
Why is it important?
Vendors rely heavily on the information provided in support tickets to assess severity and impact, determine root cause and assign priority. This enables vendors to diagnose issues faster, prioritise work correctly, and deliver better outcomes with fewer follow-up queries.
Well-written support tickets clearly describe:
- what the issue or request is
- where and when it occurs
- who is affected
- why it matters from a business or learner perspective.
Incomplete or unclear tickets can result in:
- delays while information is clarified
- incorrect assumptions and wrong advice
- lower prioritisation of genuinely critical issues.
Providing structured, factual and outcome-focused information helps vendors act efficiently and ensures issues are assessed fairly against other competing demands.
What are the benefits of introducing a systematic approach?
- Resolve bugs and issues more quickly.
- Improve system stability and learner experience.
- Enable enhancements that improve learning design, reporting or administration.
- Reduce rework caused by unclear or incomplete requests.
- Build productive, collaborative relationships with vendors.
Who is this information suitable for?
All staff, particularly learning designers and developers, platform and LMS administrators, product and business owners.
Good support tickets should typically include
| Element | Description |
|---|---|
Request details |
|
Problem or Request description |
|
Time and Frequency |
|
Users affected |
|
Why it matters |
|
Troubleshooting and evidence |
|
Additional context |
|
Priority assessment |
|
General Practices
Clear support tickets help ensure authoring tools and platforms continue to meet evolving learning and business needs.
|
Good Practice |
|---|
A learning administrator logs a bug with exact reproduction steps, screenshots, affected user roles and a clear explanation of how it blocks learner completion. The vendor can reproduce the issue immediately and prioritise it correctly. |
|
Practices to avoid |
|---|
A ticket simply states ‘reports aren’t working’ with no screenshots, module name or user role details. The vendor must request additional information, delaying investigation and resolution. |
Hypothetical Example
| Element | Description |
|---|---|
Request details |
|
What is it? |
(What are we trying to solve)
|
Brief description of the issue or request |
(What is happening or not happening? What problem are you solving?)
|
Why is this important |
(Explain the business, learner or administrative impact)
|
What does success look like? |
(Describe the expected behaviour or outcome)
|
Troubleshooting and evidence |
|
Location in the system |
|
Timing and frequency |
(First occurred, frequency and quantity of known incidents)
|
Affected users |
(Who is affected or supported? Fo example: learners, admins, facilitators, authors, specific teams) Provide names, roles, teams if appropriate. Provide User login/ID if applicable).
|
Troubleshooting and investigation already completed. |
(Actions already undertaken: List steps you or users have already taken, e.g. reset password, cleared cache, impersonation, testing in another browser. Results of actions: What changed or did not change after each action?) Action:
Results of actions:
|
Evidence |
(Screenshots or screen recordings: Attach or link if available. Error messages or logs: Exact error message(s): Error code(s), if any.)
|
Additional context |
(Recent changes or updates: Releases, configuration changes, content updates. Theories or observations: Anything that may help diagnosis)
|
Priority assessment |
(rating and rationale) 4: High impact. Can use an interim measure for the next 24 hours. Manually updating learner records. |