Events Queue Procedures
From CSS Wiki
Tickets in the events queue are handled by priority in the order that they are received. Please make sure you are familiar with the established CSS Priority Scale and Response Time. You may also want to refer to the Workstation Setup article so that you can make the most of CSS resources that are available to you.
Contents |
Basic Fields
- Status: Tickets should be changed from new to open as soon as possible. If there is not enough time to send a full response, open and take the ticket, send the "Customer Service: Request Received" response template and then change the owner to nobody while keeping the ticket open. This simple acknowledgment to the customer informs them that their request has not only been received but is currently being processed. All tickets that need work completed should be left open. Once work has been completed on a ticket, change the status to stalled and owner to nobody (Note: A quick way to do this is to set the status to "stalled" and owner to "nobody" while making a reply. That way you don't have to do anything after the reply is sent.).
- Requestor: The event customer should always be listed as the requestor.
- CC: All other individuals associated with an event (eg: an event contact) should be listed as a CC.
- Subject: Only the event title, exactly as it appears in ResDb, should be entered in the subject line (ie: no dates, locations, etc.). This is because the date and/or location of an event is more likely to change than the event title.
- Location: This field should always consist of a three-digit building code and room number (eg: KNE 110) unless the event is taking place in multiple locations in which case the location field should be left blank.
- EventID: Once a booking has been made in the ResDb, please make sure to copy the EventID number and record it in the corresponding ticket. Also, at the same time, it's a good idea to record the ticket number in the ResDb.
- Due Date: The ticket due date should always be the day (or last day) of an event. Be careful when entering due dates on tickets. If you manually enter the date, please note that the format is "YYYY-MM-DD" and NOT "MM-DD-YYYY" as we're all probably used to. To avoid any confusion, I would suggest clicking on "Choose a date" and using the pop-up calendar. Once an event has passed, the ticket will show as overdue and will be given back to the person who completed the Work Order so that they can resolve the ticket. More information on this process can be found in the Resolving Tickets section below.
Response Templates
- Request Received: Response to use when a request has been received and ticket opened
- Confirmation Details: Response to use when gathering details in order to confirm a reservation
- Expired Tentative Reservation: Response to use when a tentative reservation has expired
- Cancelled Tentative Reservation: Response to use when an expired tentative reservation has been cancelled
- Reservation Items Due: Response to use when collecting overdue reservation items
- RUUF Completion Required: Response to use when a RUUF is required for a reservation
- Work Order Confirmation: Response to use after reservation work orders have been completed
- Resolved: Response to use when a reservation request can be closed
On-Going Requests
On-going requests for Amara Simons, CLUE, ROTC early morning sessions, etc. can be resolved as soon as their reservation has been entered into the ResDb and "finalized."
Resolving Tickets
You are responsible for resolving tickets you complete the Work Orders for. When the ticket is due, the events queue manager will open the ticket, assign it to you (if you don't already own it) and comment that the ticket is due. Tickets should be resolved only after the event has occurred either on the same day or the next day. When resolving the ticket, please use the "Events: Resolved" response template.
