Norwegian
version of this page
Contact TSD
How to write good support requests
Writing descriptive and specific support requests helps the support team understand your request quicker. Below is a list of good practices.
Create a ticket
Send an email to tsd-drift@usit.uio.no to create a support ticket. Tickets are tracked and have higher visibility. Everyone in the support team can see the tickets and respond appropriately.
Create a ticket for each issue
Creating a ticket for separate issues ensures that each issue is given the appropriate priority and can be tracked easily. Adding a new issue to a resolved or unrelated issue diminishes its visibility.
Give descriptive and specific subject line
The subject line should be descriptive and specific to the issue. 鈥淧roblem in TSD鈥 is not descriptive enough and does not differentiate itself from other issues.
Specify the environment and intent
Describe the system environment. A suggested template to start out with:
Project number: (eg: pXXX)
Username: (eg: pXXX-<username>)
Operating system of the virtual TSD-machine: (eg: Windows or Linux)
Login protocol: (eg: Omnissa HTML Access, or Omnissa Horizon Client)
First time login? (yes/no)
Description of issue:
Telephone number:
Any extra information like describing software involved, specifying filenames and paths, attaching screenshots will mostly be very helpful to the support personnel working on your ticket.
Tell us what actually worked so far and what was attempted to solve the issue. Often we get requests of the type 鈥淚 cannot get X to work鈥. The request does not mention whether it has ever worked or if this was the first attempt.
Be descriptive and give us enough information to understand what you are trying to achieve.
Describe the original problem and intent (The XY problem)
Often we know the solution but we don鈥檛 know the problem. Please read which happens when a user鈥檚 original issue is masked by a different problem.
In short (quoting from ):
-
User wants to do X.
-
User doesn鈥檛 know how to do X, but thinks they can fumble their way to a solution if they can just manage to do Y.
-
User doesn鈥檛 know how to do Y either.
-
User asks for help with Y.
-
Others try to help user with Y, but are confused because Y seems like a strange problem to want to solve.
-
After much interaction and wasted time, it finally becomes clear that the user really wants help with X, and that Y wasn鈥檛 even a suitable solution for X.
To avoid the XY problem, if you struggle with Y but really what you are after is X, please also tell us about X. Tell us what you really want to achieve. Solving Y can take a long time. We have had cases where after enormous effort on Y we realized that the user wanted X and that Y was not the best way to achieve X.