CIS: Ticket Owner’s Check List

For each phase of the issue life cycle, an Owner will complete some or all of the ticket owner’s checklist of action items. The core principle behind each checklist item is “What’s the best way for me to be of help to you?”  Keep this question in mind as an owner and as an assignee and you won’t go wrong.


If you are the first point of contact when someone requests service or information from CIS, then you are the owner of the ticket. Remember, we are trying to make our customer’s lives easier, so technical knowledge of the issue is not the primary guide to ownership. This gives you the opportunity to coordinate a great service interaction that involves helping a customer and helping your CIS colleagues.  “What’s the best way for me to be of help to you?” will be a good guide at every step.

Link to Ticket Life Cycle Slide


Phase 1.  Issue Life Cycle = Request (Ticket status in Footprints = Request or Open)

Phase 2.  Issue Life Cycle = Open (ticket status in footprints = Open, Scheduled, Customer has responded)

Phase 3.  Issue Life Cycle = Finished (Ticket status in Footprints = Closed)

Appendix 1.  Selecting the appropriate service from the drop down list.

Phase 1.  Issue Life Cycle = Request (Ticket status in Footprints = Request or Open)

“Collect Information”. 

This is the crucial first phase of the ticket life-cycle.  If you are the first point of contact, you will normally be the ticket owner. This is your opportunity to shine and for CIS to shine because of your excellent customer service.

Checklist - Depending on the issue, you may need to do some or all of these steps.


Checklist Item



Collect troubleshooting information.

  1. You are the owner if you are the first point of contact for a service request.
  2. Normally, it will be a good idea for you to help by collecting high quality initial troubleshooting information.
  3. Consult any guidance that you have from Tier 2  (we need a link to Tier 2 documents) about this kind of problem and what troubleshooting steps should be taken.  Get answers to as many of the questions as possible.
  4. Let the user know that you’re collecting the information in order to help get the task assigned to the right person.
  5. Make sure to ask if this problem has occurred for this user before.  Also, you should check if the problem is occurring for other users  (look at ticket system, check with co-workers).


Establish when  the user wants or needs the work done. (timeline).

Be as clear as possible.  “as soon as possible” and “whenever you have time” are not clear; “by next Friday”, “before your meeting at 2pm” are clear. If a user says something unclear, try giving them a suggestion such as “would the 16th be acceptable?”.


Tell the user what you are going to do, and establish a time that you’ll get back to them with updates.  

Do not simply assign other staff from CIS to the ticket and say “they will get back to you”.  Instead, say something like, “I believe that this question would be handled by <name>.  Now that I have your timeline, let me get in touch with them and get back to you with a forecast about when we can get the work done”.


Confirm the requested support and next action items.

If you are talking to the user, make sure to repeat back what you have heard from them before you end the call or conversation.  This step will probably not be necessary if you are interacting in writing (email, IM, text, discussion forum...).


Decide who needs to take action next and let them know. Set the “Action Needed By” field.

The next action may need to be taken by you or by someone else.  Either way, make sure you are clear about it.  Don’t confuse ticket ownership and “Action Needed By”.


Select the appropriate Service field from the drop down list in Footprints.

We are using the service field for auto-assignment,for reporting and, in the future, to trigger automated actions (like escalation).  Read the appendix for guidance about selecting the appropriate service.


Decide whether you should continue to be the owner of this ticket.

Reasons to ask someone else to be an owner would be because you are going to be out of the office, have a project that is going to absorb all your time, must attend a lot of meetings that will interrupt the user’s desired timeline etc Technical knowledge of the topic/issue should NOT be the primary guide to ownership. Remember, our process separates the task of customer advocacy (ownership) from the technical request tasks (assignees).  If you think you are not the best one to own this ticket, you will need to ASK someone else to  become the owner.

At the end of Phase 1, you should have answers to at least the following questions: What, exactly, is the service request? By when is it needed?  Who owns the ticket? Who needs to take action next? What service category is this request in?
Phase 2.  Issue Life Cycle = Open (ticket status in footprints = Open, Scheduled, Customer has responded)

Ensure work is done and keep user informed”.

The owner’s task in this phase of the cycle is to ensure that the work is done and keep the user informed.  “What is the best way for me to be of help to you?” may indicate conversations with the customer and with the assignee.

Checklist - Depending on the issue, you may need to do some or all of these steps.


Checklist Item



Keep informed.

Keep an eye on the information you gathered in phase 1:

  • The date and time when the user needed the work completed.
  • Who is working on the ticket (it could be you!).
  • The forecast date for delivery of the work.
  • Whether or not the user wanted an update before the delivery date (i.e. should you inform them of progress?)


Monitor in case changes are needed.

  • Keep in mind that you are helping both the end user and the assignee. You don’t just toss the issue into another person’s court: instead, do what you can to help them.  Monitor whether you need to change the assignee if the original assignee is out of the office, too busy to get the work done within the timeline etc.


Remind and escalate as needed.

  • Sometimes an assignee will need to be reminded. It happens to us all.
  • Sometimes you will need to escalate the issue -- that’s a normal part of operations too. Remember, we are just a team trying to get this done.


Keep an eye on the forecast: keep the user informed.

  • Depending on the complexity of the work, as the forecast delivery date draws closer, you should check in with assignees.  If the forecast needs to be revised, you, the owner should communicate this to the user.
  • If no “by when” agreement in original information gathering, or progress is slower than anticipated, update user every week.


CIS communicates well: keep the user informed.

  • The owner does not always  need to be the middle wo/man for information requests to and from the user.  Your job is just to ensure that the work gets done and the user is kept informed.  For more complex requests, there will often  be communication between the assignee and the user. And for simple requests, the assignee may well complete some of the owner’s tasks, such as updating about the forecast or asserting that the work is done and closing the ticket.


Phase 3.  Issue Life Cycle = Finished (Ticket status in Footprints = Closed)

Our process says: “Check work, let user know, gather feedback”.

Once the work is finished, the owner closes the issue.  You and the assignees get to enjoy one more job well done.

Checklist - Depending on the issue, you may need to do some or all of these steps.


Checklist Item



Quality Assurance: check work

  • Quality assurance is everyone’s responsibility, not just the ticket owner’s, but s/he has a big role to play in QA.
  • Help the assignees by checking the work. There will be a great deal of variety with respect to your ability to check work.  But generally speaking you should pay attention to the following:
  1. As far as you can see, are things working as anticipated?
  2. Is everything in the original request taken care of?
  3. Are there any typos or other errors?
  4. If the request was for an asset to be removed or protected in some way, check that it is gone, or protected.


Let the user know that we think the work is done.  Request confirmation.

  • Once you are satisfied with the work, you should write the user and assert that the work is done.


Close ticket. Request Feedback.

  • If the user responds that the work is done, close the ticket and request feedback or wait
  • Write to the user three times to request their feedback before closing the ticket.
  • Two weeks is a reasonable timeframe in which to close a ticket if you have not heard back from the user and you believe the work is complete. If the user doesn’t respond, wait 2 weeks, then close the ticket and request feedback.

Last updated: 10/15/2014

Last update by: MT during Single Issue Meeting

Appendix 1.  Selecting the appropriate service from the drop down list.



Account Management

Select this service for account creation, account deletion, name changes, updating of accounts.

AudioVisual Setup

Select this service for audiovisual setups for classes, meetings and events. This includes large events like the Board of Trustees meeting, Alumni weekend, etc.

Video Recording

Select this service for scheduling videorecording of classes, events or meetings. Also use this for requests for video production or video editing. Use "Educational Technology" for questions or scheduling of the MediaSite lecture capture system.


Select this service for any request for data from the CX Information System, such as current student, staff, or faculty information. Request for Impromptu set up assistatnce should use the "Other Software" service.


Select this service request for any issue related to copying, printing, scanning, whether hardware or software related.


Select this service for any issues related to the use of Jenzabar CX, such as importing data to CX, modifying menus or CX screens, reports of problems with the system, or requests for confirmation of the accuracy of CX data.


Select this service for issues related to Office365, Google Apps and mailing lists, mail forwarding (mail central), spam.

HMC Websites

Select this service for all issues/requests related to any website that ends in, not already included in another service category (eg. portal or a google site). Includes WordPress, Cascade issues.

Lab Software

Select this service for all issues with computers in Learning Studio, LAC and including departmental labs (chem, bio, engineering) Lab reservations should be done through EMS.


Select this service for all network related issues, wired network, security, VPN issues, DMCA issues, all network related issues here. Put every network related except wireless issues in this category.


Select this service for all OnBase requests except Odyssey RFC (Other software)

JICS Portal

Select this service for all issues or questions concerning the use of the JICS Portal.


Select this service for all Sakai related issues, including authentication issues.

Other Software

Select all issues related to software that is not otherwise singled out in the service field eg Formstack, Ultipro, Odyssey RFC,


Select this service for wireless network issues

Scientific Computing

Select this service for requests and questions about high performance computing, R, mathlab, mathematica

Educational Technology

Select this service for Lecture capture, whiteboards, clickers. Not Sakai. Not basic AV.

Other Issue

Use "Other Issue" when no other service choice seems appropriate. please make sure to give feedback when you find yourself in this situation.

Password and Login issues

Select this service for issues and service requests related to account access, such as password resets and username recollection.