University of Central Florida
Information Technology (UCF IT)
1
Title:
Effective: 10/26/2018
UCF IT Service Request Fulfillment Policy & Procedure
Revised: 02/03/2022
Approved By: Matthew Hall, VP of IT and CIO
Page 1 of 12
Revision History
Revision (Rev)
Date of Rev
Owner
Section III; UCF IT
03/21/2019
Scott Baron
Section III; UCF IT
11/12/2019
Scott Baron
Section VI. B
11/12/2019
Scott Baron
Section VI. B
11/12/2019
Scott Baron
Section VIII. Appendix; A.
04/01/2020
Scott Baron
All sections requiring updates
02/03/2022
Scott Baron
I. DOCUMENT CONTROL AND APPROVALS ......................................................... 1
II. OBJECTIVES ........................................................................................................... 2
III. DEFINITIONS .......................................................................................................... 2
IV. SCOPE ...................................................................................................................... 3
V. POLICY .................................................................................................................... 4
VI. PROCEDURES......................................................................................................... 4
A. Service Desk Ticket Registration ........................................................................ 4
B. States – Requested Item and Task State Codes/Stopping the SLA Clock .......... 5
C. Requested Item Cancelation – Task Pending Code of Awaiting Requester Info 9
VII. ADDITIONAL CONSIDERATIONS .................................................................... 10
VIII. APPENDIX ......................................................................................................... 10
A. UCF IT Service Offerings* - Service and Operational Level Targets .............. 10
I. DOCUMENT CONTROL AND APPROVALS
This document is authored, managed and governed by UCF IT Strategy and Planning. Final
published versions have been approved by the VP of IT & CIO and ITSM Governance
Committee members. No other parties have the authority to modify or distribute a modified
copy of this document. For any questions related to the content of this document, please
contact the UCF IT Performance and Service Management department.
2
II. OBJECTIVES
This document is intended to define and describe a consistent service request fulfillment
process that aims to improve UCF IT service quality. The service request fulfillment
process provides a channel for UCF IT consumers to request and receive active UCF IT
services. The process needed to fulfill a service request will vary depending upon what is
being requested. The request fulfillment processes and procedures will enable IT staff to
monitor and fulfill service requests quickly, consistently and efficiently.
The objectives of the UCF IT Service Request Fulfillment process are to:
• Provide a simple means for the university to receive standard services for which a
pre-defined approval and workflow process exists
• Provide customers with a single source of information regarding the UCF IT
services available and how to obtain them
III. DEFINITIONS
Service Request: Request (defined as a Class Name = “Requested Item” within
ServiceNow) from a customer for creating, modifying, adding, moving, or removing some
or all service functionality, access, or infrastructure components. Referred to as a “catalog
item” within ServiceNow.
Service Catalog: The service catalog is part of the service portfolio and contains
information about two types of IT service: customer-facing services that are visible to the
university; and supporting services required by the service provider to deliver customer-
facing services.
Service Level Agreement (SLA): An agreement between an IT service provider and a
customer. A service level agreement describes the IT service, documents service level
targets (SLTs), and specifies the responsibilities of the IT service provider and the
customer.
Service Level Target (SLT): A commitment that is documented in a service level
agreement. Service level targets are based on service level requirements and are needed to
ensure that the IT service is able to meet business objectives. They should be SMART
(Specific, Measurable, Attainable, Realistic and Time Bound) and are usually based on
key performance indicators (KPIs).
Operational Level Agreement (OLA): An agreement between an IT service provider
and another part of the same organization. It supports the IT service provider’s delivery of
IT services to customers and defines the good or services to be provided and the
responsibilities of both parties.
3
Interaction: A customer contact recorded by the UCF IT Service Desk. If the contact is
an incident or service request, then the agent transfers the information by creating another
record to the applicable incident or requested item table.
Ad-hoc Task: A manual (stand-alone) task created on the service request that is not tied
to the predefined catalog task workflow. NOTE: Setting an ad-hoc task to one of the
cancel request states will not affect the requested item state. Only catalog tasks driven off
the workflow can cancel a requested item.
Catalog Task: A task generated by predefined workflow activity.
Requested For: The field within ServiceNow that identifies the individual requesting
assistance. This is the customer of the service request.
Opened By: The field within ServiceNow that identifies the individual that actually
creates (submits) the ticket.
Work Notes: A field within ServiceNow used to document activities associated with the
service request. This field is internally facing to ServiceNow fulfillers.
Activity Log: A field within ServiceNow that is systematically logged which captures all
activities of a ticket such as email notifications sent, work notes updates, additional
comments added or changes to any fields.
IT Service Management (ITSM) application: This is the application (ServiceNow) used
by UCF IT to record incidents, problems, service requests and changes.
Information Technology Infrastructure Library (ITIL): A set of best practice
publications for IT service management. Owned by the Cabinet Office (part of HM
Government), ITIL gives guidance on the provision of quality IT services and the
processes, functions and other capabilities needed to support them.
IV. SCOPE
The process of handling each type of service request can be broken down into a set of well-
defined activities and can be documented as a process flow (known as workflows). The
workflows are all built and stored within the ServiceNow catalog item repository.
When defining service request workflows, the service provider should consider the
following points:
• Who will handle the request? - Defines individuals or teams who are
responsible for the request fulfillment.
• How is the service delivered? - Defines the process of service delivery.
4
• How quickly will the service request be fulfilled? - Reflects the defined SLA or
time window (SLT). Reference Appendix A. for UCF IT Service and Operational
Level Targets per each active UCF IT service offering.
The UCF IT Service Request Fulfillment Process WILL cover:
• Service requests associated with active UCF IT services in the service catalog
• Service Level Agreements/Targets and Operational Level Agreements/Targets
▪ Continuing to baseline average times to fulfillment across active UCF IT
service offerings. Service and Operational Level Targets can be modified
and will be added and documented within Appendix A.
The UCF IT Service Request Fulfillment Process WILL NOT cover (at this time):
• Non-UCF IT service offerings
• Systematically prioritizing service requests (e.g. Incident Management VIP’s)
• Change requests addressed by the UCF IT Change Management process
• Knowledge requests addressed by the UCF IT Knowledge Management process
V. POLICY
UCF IT staff members will record and document within the ITSM application
(ServiceNow) ALL customer requests for assistance in regard to service requests. UCF
IT staff members will follow the UCF IT Service Request Fulfillment procedures to
review, follow-up and fulfill these ticket types in a timely manner. The work notes should
be updated routinely (when applicable). All in-scope activity will follow the process
defined by this document.
The UCF IT Support Center is the primary point of contact for all customers and will be
available by multiple methods, including Web, Email or Telephone to facilitate incident
or service request submissions.
• Web – via self-service portal page: https://ucf.service-now.com/ucfit
• Email – [email protected]
• Telephone – 407-823-5117
Requests for service fulfillment will be recorded as requested items in the ITSM
application (ServiceNow) and will be subject to measurement and reporting.
VI. PROCEDURES
A. Service Desk Ticket Registration
There are currently three ways for a customer to contact the UCF IT Support Center
and request assistance:
5
• Web (Self-Service Portal Page)
A UCF IT Support Center agent creates and triages (if applicable) the
web request (either an incident or service request) from the interaction
queue
OR
The customer directly submits a service request through the service
catalog, which is systematically triaged to the service owner
• Email – A UCF IT Support Center agent converts the email request (if
applicable) into a ServiceNow ticket (either an incident or service request)
• Telephone – A UCF IT Support Center agent captures all required information
and creates (if applicable) a ServiceNow ticket (either an incident or service
request)
The customer is sent an automated acknowledgement email when the ticket is
created within ServiceNow.
B. States – Requested Item and Task State Codes/Stopping the SLA Clock
There are six requested item state codes that are/may be reflected during the lifecycle
of a service request (from create to fulfillment). The requested item state codes are
driven off the related workflow tasks and their represented/selected states.
NOTE: The requested item states are read-only fields within ServiceNow.
The state codes for both requested items and tasks are defined below and reflect
when the “SLA” clock is running or stopped.
NOTE: The current service and operational level targets determined by UCF IT
service providers are identified within Appendix A. The UCF IT service
providers have agreed to fulfill the active service offering(s) on an average basis
against the targets identified. These targets are variable and are subject to
change. The targets identified in Appendix A. are business days and account for
total time elapsed when the SLA clock is running.
6
Requested Item States:
State
Status
Open
Logged (start the clock). Work to fulfill
request has not begun
Work In Progress
A related task has begun/In progress
(SLA clock running)
Pending
ALL related opened tasks are pending
(stops the clock)
Awaiting Requester Confirmation
Final workflow task completed (stops the
clock). Customer able to reopen within
three business days
Closed Complete
Auto-close/Process owner involvement
Canceled
Unable to reach customer, service
request no longer required per
confirmation from customer, remove
duplicate ticket(s) or incorrect catalog
item that needs to be resubmitted or
converted to an incident
• Open - The requested item is created within ServiceNow and the approval
process has started (if applicable). Work to fulfill the request has not begun.
o The SLA clock starts.
• Work In Progress – Work to fulfill the requested item has begun or is in progress.
All approvals have been completed (outside of mid-workflow approvals) and at
least one related task has been set to a “Work In Progress” State.
o The SLA clock IS running.
• Pending – The requested item is awaiting a pending action outside of UCF IT’s
control, a change freeze is in effect or per University/UCF IT directive, normal
operations conclude earlier than normal business hours due to planned or
unplanned events. The pending state will systematically set when one (if sole
related task) or ALL related tasks are in a pending state.
o The SLA clock is paused and IS NOT running.
• Awaiting Requester Confirmation – Following the last task of the requested item
workflow being completed, the requested item state will systematically set to
“Awaiting Requester Confirmation”. The customer will have the option to reopen
their request through email or the self-service portal (a systematic email with a
Reopen Ticket! button is sent when the requested item state changes to
“Awaiting Requester Confirmation” or a Reopen Ticket! button appears within
the self-service portal when the requested item state changes to “Awaiting
Requester Confirmation).
o The SLA clock is paused and IS NOT running.
NOTE: If an ad-hoc task has been created on the requested item and is not
closed before the last task of the requested item workflow, then the ad-hoc task
will systematically close to prevent tasks from remaining opened after the
requested item is deemed complete. This ServiceNow system action takes place
before the requested item state changes to “Awaiting Requester Confirmation”.
7
An ad-hoc task cannot be created after the state of the requested item changes
to “Awaiting Requester Confirmation”.
• Closed Complete – The requested item has been fulfilled to customer
satisfaction.
o The closed complete state is systematically set following these two scenarios:
▪ Scenario 1: The requested item auto-closes in three business days.
▪ Scenario 2: The customer indicates their service request was not
fulfilled to their satisfaction by choosing to reopen their request
through email or the self-service portal (a systematic email with a
Reopen Ticket! button is sent when the requested item state changes
to “Awaiting Requester Confirmation” or a Reopen Ticket! button
appears within the self-service portal when the requested item state
changes to “Awaiting Requester Confirmation).
Following the customer confirmed reopen, the process owner of the
catalog item will be notified and assigned a task indicating that
customer action is required. The newly assigned task will set to an
Open state and the SLA clock will start again (requested item state
will set back to Work In Progress).
Once the process owner ensures the request has been fulfilled to
customer satisfaction, they will close complete the task, which will
close complete the requested item.
• Canceled – The requested item is no longer required. The assignee of one of the
opened requested item related task(s) concludes the request is no longer required
to be fulfilled (either unable to contact customer for more information, customer
indicates they no longer require the service, cancel a duplicate ticket(s) or cancel
an incorrect catalog item that needs to be resubmitted or converted to an
incident).
Task States
There are seven task state codes. Only six task state codes can be selected during the
lifecycle of a service request. When a task is spawned from the requested item, the
state defaults to Open.
State
Status
Open (defaults – cannot be selected)
Work to fulfill the task has not begun
Work In Progress
Work to fulfill the task has begun
Pending
Pending action outside of UCF IT
control, change freeze in effect or
applicable Admin Time
(see Pending Code definitions below)
Closed Complete
Task fulfilled/completed
Closed Skipped
Task no longer required or applicable
Cancel Request - No Response
Service request no longer required due to
not being able to reach customer
8
Cancel Request - Customer
Service request no longer required per
confirmation from customer, remove
duplicate ticket(s) or incorrect catalog
item that needs to be
resubmitted/converted to an incident
• Open - Work to fulfill the task has not begun. Once a task assignee moves a task
into “Work In Progress”, the task state of Open will no longer be able to be
selected.
• Work In Progress – Work to fulfill the task has begun.
• Pending – A task can ONLY be put into a pending state if one of the six pending
codes below are applicable.
NOTE: The task assignee will be required to complete a pending code
selection and reason on why the task is in a pending state.
Pending Codes:
▪ Awaiting Requester Info – If the task assignee requires additional
information from the customer to proceed with the task. Once the
required information is received from the customer, the task should be
placed back into a “Work In Progress” state (if applicable) by the task
assignee.
▪ Awaiting Business Decision Outside of UCF IT Control – If a
decision to move forward and complete the task is pending a business
decision to be made that is outside of UCF IT’s control. Once the
decision is made, the task should be placed back into a “Work In
Progress” state (if applicable) by the task assignee.
▪ Awaiting Vendor – If a task is dependent on third-party vendor
action. Once the vendor takes action, then the task should be placed
back into a “Work In Progress” state (if applicable) by the task
assignee.
▪ Awaiting Requester Fulfillment Date – If the requested item has been
created proactively and work cannot start on a task until a future date
approaches. Once the future fulfillment date arrives, the task assignee
should place the task into a “Work In Progress” state (if applicable).
▪ Awaiting Administrative Time – Per University or UCF IT directive,
normal operations conclude earlier than normal business hours due to
planned or unplanned events (i.e., weekday home football game, UCF
IT department wide events (picnics, sporting events), unplanned
campus closure, etc.) If the task assignee is impacted and is unable to
work on the task, the task should be changed to a State of “Awaiting
Administrative Time” when the event time approaches. The following
business day, the task assignee is responsible to put the task back in
its previous State.
9
▪ Change Freeze – At certain critical times of the year (semester start),
UCF IT imposes a change freeze period. During this time, it is the
discretion of each UCF IT department to authorize or prohibit
continued work to fulfill a service request. The UCF IT department is
permitted to use the “Change Freeze” Pending Code during the
change freeze window. Following the change freeze window end, the
task should be placed back into a “Work in Progress” state (if
applicable) by the task assignee.
• Closed Complete – Task fulfilled/completed
• Closed Skipped – Task no longer required or applicable. Next task of the
workflow will be spawned (if applicable) and the service request is still required
to be fulfilled
• Cancel Request - No Response – Service request no longer required. Unable to
reach customer for additional information after three attempts (See Section C. for
this process). This selection will cancel the catalog item and the requested item
state will change to Canceled.
• Cancel Request - Customer – Customer confirmed the service request is no
longer required.
NOTE: This task state should also be used if the service request is being
canceled due to being a duplicate ticket or if the request was incorrectly
submitted using the wrong catalog item/request needs to be converted to
an incident. The customer should be informed that their request will be
canceled to ensure there is no confusion when the applicable cancel
notification is spawned. This selection will cancel the catalog item and
the requested item state will change to Canceled. The task assignee will
be required to complete a reason for canceling.
If the service request is being canceled due to an incorrectly submitted
catalog item/conversion to an incident, it is mandatory the task assignee
(who is canceling the service request) work with the customer to have
the correct catalog item/incident submitted.
C. Requested Item Cancelation – Task Pending Code of Awaiting Requester
Info
If a task assignee cannot proceed with fulfilling the task due to needing additional
information from the customer, the task assignee should change the state of the task
to “Pending” and select the pending code of “Awaiting Requester Info”.
Following the task being moved to “Awaiting Requester Info”, the task assignee is
responsible to reach out to the customer to obtain the information needed to proceed
with the task fulfillment. If the task assignee is unable to speak with the customer
upon the first contact, the task assignee should leave a voicemail message (if
available) for the customer containing their name, phone number and the ticket
number.
10
The assignee of the task must make two more attempts using one other method of
communication (ex. email or instant message) on two subsequent business days,
preferably at different hours each day (e.g., do not attempt all three contacts at 9 AM
in case your customer will never be available at that time of the day). If an out of
office (OOO) email is received, the assignee of the task must wait until the customer
returns to contact a third time. The work notes must be updated with each contact
attempt.
After three attempts of trying to contact the customer with no success, the task
assignee IS permitted to cancel the service request by selecting the “Cancel Request
– No Response” task state. Changing the task state to “Cancel Request – No
Response” will cancel the requested item and prompt the task assignee to complete a
reason for canceling the service request.
VII. ADDITIONAL CONSIDERATIONS
• All existing and new staff members of UCF IT are expected to be familiar with
the intent and the contents of the service request fulfillment policy and
procedure.
• All violations to the service request fulfillment policy will be monitored, staff
members of UCF IT will be coached by the respective management and repeat
offences could lead to additional disciplinary action.
VIII. APPENDIX
A. UCF IT Service Offerings* - Service and Operational Level Targets
UCF IT Service Offerings
Target (Business Days)
Absolute Data and Device Security Asset Management
4
Access to Terminated Email Account
2
Active Directory Change
5
Active Directory Provision/De-Provision
4
Add a Windows server to the manual update group
30
Add, Remove, or Reset Admin Account
4
Airwatch Mobile Device Management
7
Amazon Web Services (AWS) Work
15
Application User Access
4
AppSense
5
Azure Work
5
Backup Restore VM API (Granular)
5
Backup Services
5
Call Block Request
5
Cloud Consultation
15
Configuration Manager Shared Services
5
CrashPlan Endpoint Backup
7
Data File Exchange Support via SFTP
12
Deprovision Email Account
2
11
DHCP Scope Provisioning and Maintenance
7
DHCP Tool User Maintenance
4
Distributions Group Change
2
DocuSign Onboarding
7
DocuSign Security & Organization Changes
7
Door & Traka Box Access
2
Dropbox Advanced
5
Dynamic Forms Onboarding
7
Dynamic Forms User & Organization Management
3
Endpoint User Access
3
F5 Application Delivery
4
Federated Identity SSO Request
30
General Request
6
Hardware Request
10
Information Security Consulting Request
10
Internal Firewall Request
10
IPAM Request
5
ISO Application Access Request
2
IT Consultation
5
Knights Email Address Change
2
Linux Services Support
6
Linux SFTP/SSH (Port 22) Access
6
Listserv Broadcast Emails
2
Listserv Create, Change, or Remove
5
Listserv General Requests
5
Listserv Owner Training Course Access
4
Loaner Equipment
2
Microsoft SQL Database Support
7
Microsoft Teams
2
Microsoft Teams External Application Connector
13
ISO Vendor Risk Management Review (OLA)
10
MySQL Database
5
NAS/NSF, Physical SAN
3
Network Consulting Services
20
New Shared Folder
10
New Titanium User Access
4
NID Account Access De-provision Request
30
Non-internet Facing DNS
5
NSX Network Request
7
Offensive Security Services
30
Office 365 Shared Mailbox
7
Oracle Database Support
8
Phonebook Assistance
3
Physical Server Hosting
30
Pinnacle Request
2
Project Management Services
30
Protect Your Application or Service with Multi-factor
Authentication
30
12
*Active services offered within the UCF IT Service Catalog. Targets are subject to change.
Protect Your Enterprise Microsoft M365 with Multi-factor
Authentication
30
Protect Your myUCF account with Multi-factor
Authentication
3
Public Firewall/DNS Request
8
Public Records Request
30
Q Drive Request
10
Qualtrics Survey Platform Assistance
4
Request for Microsoft Team Name Change
3
RMA (Return Merchandise Authorization) Equipment
45
Roles and Resources
2
Secret Server Request
7
Security Awareness and Education
10
Security Operations Center (SOC)
30
Security Risk Assessment
3
SecurityCenter Report Management
3
Server Software Change
10
ServiceNow Report or Homepage Request
2
ServiceNow Request Management
5
ServiceNow User & Group Management
2
Shared Services Consultation
3
SharePoint Access
4
Sharepoint Site Migrations
5
Software Packaging and Deployment
5
Software Request
5
Sponsored Account Application Support
30
SSL Certificate
2
Sudo Access for Oracle DB
2
Sudo Access for RedHat Linux
4
UCF Apps
30
UCF Connect Event Support
8
UCF IT FourWinds Request
10
Vendor Risk Management (VRM)
20
Virtual Machine Change
6
Virtual Machine Create
14
Virtual Machine Decommission
25
Virtual Machine Snapshot
4
VLAN Management
15
Vulnerability Disclosure
10
Windows Server Access
5
Zoom App Marketplace Request
30