We would like to formalize how notes are kept in tickets, with the goal being to simplify things when a ticket needs follow-up. 

To this end, we would like all of the things you do as you go through a troubleshoot to be recorded in the ticket feed (ie, Actions -> Update), and use the Tech Notes field only for the current status and possible next steps.   

This will mean that if a customer calls back on the ticket, the tech who answers that call can quickly review the Tech Notes field to know where things stand and what might need to be done, without having to scroll through the feed. 

We ask that you update the tech notes when necessary, to detail the current status. Doing this will take a little extra time, but it’s worth it to make things easier for the future. Always create/update tickets with the assumption that the customer will call back on the issue, and that someone other than you will get that call! 

In each ticket, please include the following: 

• Description: The issue as reported by the customer, and (if applicable) which device is involved. Create this, save it, and continue. 
• Done: Add notes to the feed (via the Update button) as you go along, detailing all the steps you have taken. A summary of what has been done should be added to Tech Notes so a tech taking over the ticket can quickly see what has already been tried. 
• Doing: This should be in the Tech Notes, or via Update on simple & straightforward tickets, and should note what is currently happening. Examples:  
• X is installing, customer will test and call back if they have trouble 
• downloading Y, customer will call back when finished  
• tested and working, closing ticket 
• To Do: This should be in the Tech Notes and include anything that may be left to do. Examples: 
• Help customer install X once the download has completed 
• If the issue persists, try Y or Z 
• Have the user log in to make sure everything worked properly 
• I’m not sure what to do if this is not resolved- contact a full-timer for help 

Public vs private comments (via Update): Most of the information in a ticket should be visible to the customer if they log in to TD to look at a ticket. We want customers to be able to look at their ticket to know where things stand and what has been done! The only things that should be private, either by marking an update as private or by putting the info in Tech Notes, are comments intended for other technicians. That might include for example: 

• Instructions to technicians on what to next that might not be relevant to the customer 
• Any notes intended only for other technicians, e.g. “get the password from LAPS” (customers don’t know what LAPS is) 

In general, it’s better to err on the side of making comments visible to the customer. 

Don’t skip tickets: If you are looking through tickets in the between calls, please do not just open a ticket, then close it and move on. Customers can see who has viewed their tickets, and they tend to be justifiably grumpy if multiple techs have looked at a ticket and nothing has been done! If you see a ticket that you don’t know how to handle, please either ask for guidance or note in the ticket that you don’t know what to do to move forward.  

This will help in two ways- first, comments like that in a ticket will help us understand areas we need to train or document better. Second, if a customer sees a note like that it will let them know that the issue may be complex/difficult, and thus may take some time to resolve.  

It is also a good idea to respond to the customer as quickly as possible, even if it is just to say something like “we don’t have documentation on this issue, but are looking into it.” Or if you think the issue will require working with the customer’s computer to resolve – via phone or in person – please tell them so. 

Ticket handling example: 

• Customer calls saying their Outlook has been crashing. 

• Ticket creation details what the customer tells us and which computer is having the problem. 

• First update: Removed unnecessary Outlook plugins.  Ticket is set for scheduled follow-up. 
• Initial tech notes: Outlook plugins removed, seems to be working. Customer will let us know if the issue persists. 

• Customer calls back, still having the problem 

• Second update: Removed and recreated Outlook profile.  Outlook didn’t crash while we were working together. Customer will continue testing and will contact us if it happens again. 
• Update to tech notes: Removed and recreated Outlook profile.  If customer calls back, it might be worth trying to update the Outlook version on the computer. 

• Customer calls back, still having the problem 

• Third update: Customer’s machine has Outlook 2016.  Uninstalled 2016, installed Office365. 
• Update to tech notes: Upgraded Office version to 365.  If they still have trouble, let’s try removing all shared mailboxes and see if the issue continues. 

• Tech Notes now looks like this: 

Telecom will be performing a substantial update to the Avaya phone system the evening of August 17^th.  The most impactful effect of this upgrade for us is that everyone’s phone login code will be changing; your current code will no longer work after the update.  In addition, you will only need to enter #54 and then your login code. For example, if your login code is 40100, to log in to the Service Desk queue you will enter #54 40100.  To sign out, you only need to press #56. I have updated everyone’s information in CX Management as of the evening of the 17^th.

What you need to do:

• Check the CX Management site (https://tools.is.oregonstate.edu/management/) when you start your first shift on or after Thursday, August 18^th to find your newly-assigned Phone Code.
• Please note, this will NOT affect your assigned phone extension- only the code which signs you in to the Service Desk queue.

Additional note for OSU Campus Operators: The updated version of Avaya requires a separate login code to be used for the Operator queue.  CX management does not allow us to enter multiple phone codes for our techs, so I will email each of you directly with your assigned Operator login code, and will additionally add your code in the shift description field in W2W.  I should have enough Operator codes to give each person their own code.

Please contact Max if you have any questions!

Student techs- beginning with next week’s schedule (August 9th-15th), your extensions will now be listed next to your name on your main WhenToWork home screen rather than putting them in your shift description each day. Extensions are assigned to you on a permanent basis and will not need to change. Please let me know if you have questions or concerns!

Max

OSU Cascades IT staff have reinstated the cpads  (print release stations) in Tykeson lab.  Users may be calling with questions on how to use them;  documentation is posted on standing clipboards and lab door for students to follow.  The documentation is also here:

release your print job to the printer

The only issue that is still lingering is that large PDFs printed from Edge are about a 2 minute delay to start printing (and may be slow to print too). If printed outside of Edge (in Adobe, etc) PDFs will print very fast.  Chrome has been set as the default browser so this shouldn’t have too much impact.