Customer support framework

IT Strategies and Policies Wiki

Public Space · Information Technology Services

Version 1

Customer support framework

Jennifer Kim

Published: 10/5/2021

0 (0votes)

1.1 Purpose and scope

The purpose of this document is to define how ITS serves stakeholders and maintains the systems and services. This framework is used to strike a balance between customer responsiveness and traceability. This document is a “rolling plan” that will be reviewed and updated annually.

1.2 Background

This framework changes ITS’ approach to servicing our stakeholders. The fundamental difference is to encourage collaborative working among ITS staff and with our stakeholders. A service ticket will not be a pre-requisite to addressing issues and requests, but to record the non-operational changes for traceability.

This framework covers all aspects of ITS support including:

Service Categorization
Change tracking
The need for tickets and how tickets are handled
Response SLA
Change planning, communication, and tracking
Change implementation
Managing service outages

1.3 Audience

This document is to be used by the following audiences:

ITS Staff, Managers and Directors

1.4 Procedure inputs

The following are Inputs/Requirements for the ITS customer support framework:

Stakeholder service request (emails, tickets, phone, walk-up)
Internal ITS service request (emails, tickets, phone, walk-up)

1.5 Procedure outputs

The following are Outputs/Results from the ITS customer support framework:

Resolved service request
Updated documentation for tracking (if required)

1.6 Approval(s)

Follows the change management policy

1.7 Referenced documentation(s)

Below are the templates, guides, codes/scripts, forms etc. referenced in this SOP

Document Name	Location
None	None

2 ITS service categorization

The following are descriptions for the definition and classification of the ITS service categorization

Table 1:Definition

Tier	Criticality	Description	Business Criticality Measure	Recovery Time Objective
Tier 0	Foundational	IT infrastructure	Critical systems dependent on infrastructure	4 hours
Tier 1	Mission Critical	Essential to the survival of the organization	Critical student, staff and faculty facing services. No Alternative manual processing capability exists	4 hours
Tier 2	Critical	Critical in accomplishing the work of the organization	Can be performed manually for one to two days	12 to 24 hours
Tier 3	Important	Important in accomplishing the work of the organization	Can be performed manually extended period of time. Viable alternatives exist	Must be restored aligned to business cycle
Tier 4	Non-Critical	No significant impact on business operations	Services will be shut down and be restored as required and/or when resources are available	Best effort

Table 2:Classification

Tier	Criticality	Classification of Service
Tier 0	Foundational	Storage, Servers, Network, Internet, Wireless, Phone System
Tier 1	Mission Critical	Office 365, Seneca Website, Blackboard, Student System, CE Registration, Payroll System, Single Sign On, Middleware, MyApps
Tier 2	Critical	Printing, One Card, Finance System, Eloqua, Academic Clusters
Tier 3	Important	Budget Display, Hyperion Planning, Infosilem Scheduling, Library System
Tier 4	Non-Critical	All other services

3 Managing operational changes

Currently, operational issues are managed using service tickets. Moving forward, service tickets are recommended only for external stakeholder facing requests. (DevOps teams will use the product backlog for tracking outstanding / pending work).

For internal ITS service requests within or across teams, the ITS support staff will:

Promote a collaborative and trusted working environment through discussions either in person, over phone, or skype to get the service fulfilled
Use tickets as the medium for tracking / sequencing work as necessary

Note: Tickets should not be the pre-requisite for servicing internal ITS requests

For external ITS service requests, the ITS support staff will:

Review all service ticket requests received and address until completion
Review all email requests received and address until completion

Note: For traceability purposes, the ITS support staff may create a ticket using the email request received. If the request is urgent, the staff may complete the request first and then create a ticket.

For all assigned requests (emails, tickets, phone, walk-up), the ITS support staff will:

Take full responsibility for servicing the ticket to completion
Retain all requests received and collaborate with other team members to fulfil the request

Table 3:How to handle operational changes for the different service categories

Tier	Traceability	External Requests	Internal Requests	Critical / Emergency Requests
Tier 0	All requests	Ticket	Collaborative, Ticket on completion for tracking purposes	Collaborative & Incident Report for outages
Tier 1	All requests	DevOps / Ticket	Collaborative, Ticket on completion for tracking purposes	Collaborative & Incident Report for outages
Tier 2	Critical	DevOps / Ticket	Collaborative	Collaborative, Incident Report for outages
Tier 3	Critical	Ticket	Collaborative	Collaborative
Tier 4	Consult manager	Collaborative	Collaborative	Collaborative

ITS support staff will track all internal services for Tier 0 and Tier 1

Periodically managers may temporarily introduce tracking mechanisms to aid in resource planning and may schedule additional one on one meetings to discuss workloads

For maintaining SLA for operational requests (applicable to teams outside of DevOps), ITS support staff will:

Connect with stakeholders (both internal and external) regarding their service request
Keep stakeholders updated until the service request is completed

Note: Adherence to SLA directly impacts our KPI

Table 4: Response SLA

Tier	Response SLA
Tier 0	First response should happen within 4 hours of receiving the request. Daily follow up to be done with the stakeholder until request completion.
Tier 1	Same as above
Tier 2	Respond within 1 working day; Once in 2 days follow up with the stakeholder until completion
Tier 3	Respond within 1 working day; once a week follow-up with the stakeholder until completion
Tier 4	Respond within 2 working days; once a week follow-up with the stakeholder until completion

4 Managing planned changes

Currently, we have three types of RFCs - Standard, Planned, and eRFC.

Standard changes are regular operational changes that have been implemented in production. These will be tracked using tickets and seek approval where required.

Note: Standard Change RFCs are no longer required for standard changes.

A list of approved standard changes is attached in Appendix - A. This list will be maintained and updated on an ongoing basis. ITS staff will work with their respective Manager / Director to add/update the standard change list.

All other changes will be tracked using either planned RFCs or eRFCs. There is no change to the planned RFCs and eRFCs procedures.

Table 5: Planning and testing of planned RFCs and eRFCs changes

Tier	Planning for Changes	Change impact testing on other services
Tier 0	3 weeks prior	Mandatory testing of all mission critical applications
Tier 1	3 weeks prior	Mandatory testing of all mission critical applications
Tier 2	2 weeks prior	May be. Depends on the application as determined by the Directors
Tier 3	1 week prior	Not required
Tier 4	1 week prior	Not required

Similarly, the implementation procedure will now allow flexibility to respective operational managers.

For example: If a service has full failover and redundant capability, change to this service can be implemented outside of the maintenance window provided that there is no outage to the service to end users.

When implementing a change for the first time; the ITS support staff will follow the regular RFC process. Once established, it can be updated as a standard change and tracked through a ticket. Details below:

Table 6: Change implementation and communication

Tier	Requires Outage	No Outage
Tier 0	- Only within the maintenance window (unless agreed otherwise with business stakeholders) - Stakeholders should be engaged to determine the appropriate date/time during the planning phase. This communication should be considered a reminder rather that first notification of the planned change - Targeted and personalized communication to each stakeholder 48 hours before the implementation detailing implication to their operation	Collaborative
Tier 1	- Only within the maintenance window (unless agreed otherwise with business stakeholders) - Targeted and personalized communication to each stakeholder 48 hours before the implementation detailing implication to their operation	Collaborative
Tier 2	- Only within the maintenance window (unless agreed otherwise with business stakeholders) - Targeted and personalized communication to each stakeholder 24 hours before the implementation detailing implication to their operation	Collaborative
Tier 3	- Any time - 24 hours advanced notice to affected stakeholders	Any time
Tier 4	- Any time - 24 hours advanced notice to affected stakeholders	Any time

5 Managing service outages

When managing service outages:

ITS service desk provides first level support on a 24x7 basis to all students, staff and faculty
Other ITS support teams will provide 24x7 support only for widespread outage to Tier 0 and Tier 1 services.

The following table provides the details when managing such escalation.

Table 7: Managing service outages

Tier	Outage Support
Tier 0	24 x 7 Immediate support to wide spread outages, escalations from SEC, cyber security breach
Tier 1	24 x 7 Immediate support to wide spread outages, escalations from SEC, cyber security breach
Tier 2	Prioritized support on the following working day
Tier 3	Prioritized support on the following working day
Tier 4	Prioritized support on the following working day

Outage Management:

For widespread outages to Tier-0 and 1 services as defined in Table-7, the following procedure will be adopted.

The director responsible for the service becomes the incident owner. For cyber security incidents, Joseph Lee becomes the incident owner.
If the incident is not resolved within 30 minutes, the incident owner starts the ITS Emergency command center. (A departmental Skype bridge has been setup and available with the Directors)

Note: Please note that this is only the communication bridge. The technical team members will have their own bridge for problem resolution. Each team will use their respective Supervisor / Manager / Director’s Skype bridge)

The incident owner sends an email with the skype bridge details to ITS management team and the college wide emergency response list-serve (TBD) specifying the frequency at which updates will be provided. This include the VPs and the President’s office.
The Skype Bridge will be used as the primary mode of communication with all emergency response team members, ITS management team, Service Desk and ITS client liaison team members. The email also specifies the frequency of communication.
At the defined times, the incident owner provides a detailed update on the current situation, action taken so far and next steps.
The bridge remains open till the incident is resolved.
To the affected stakeholders (students, staff and faculty), targeted emails will be sent on periodic basis

6 Risk mitigation

The approach that is taken to identify and control / prevent any threat and or risk to Seneca’s ITS Services when performing ITS customer support.

(None)

7 Appendix A – approved standard change list

Standard Change	Footprints Template Name	Description
Imaging Labs E-classrooms and Computing Commons	Computer Imaging	Re-Image labs and classrooms
Blocking Malicious IP address/URL	Block IP/Site FW	Block malicious IP address/URL internally from Seneca’s network or externally from Seneca’s network
Allowing Access through an existing firewall rule	Existing FW Rule	Allow a user or network device through the firewall/VPN on an existing rule
Virtual Machine Provisioning	VM Provisioning	Virtual Machine Creation/Provisioning
Resource Change to VMs	VM Resource Change	Allow resources to be changed to existing virtual machines that may be a result of a performance enhancement or new requirement
Replacing failed hard drive in SAN storage systems	SAN Failed Disk	Replace failed disks in various Storage Area Network (SAN) systems (NetAPP, Hitachi, HP etc.)
TrendMicro Client Installation	TrendMicro Client	Trend Micro Deep Security client installation
CommVault Client Installation	CommVault Client	CommVault client installation
Updating Network Licenses for Software	Software Lic. Update	Academic network application license renewal
OpenCMS Content Changes	OpenCMS - CE Website	OpenCMS content changes
Holiday Greeting Scripts for the Main College	UnityHolidayGreeting	Update Holiday Greeting Scripts for college
FCE Hold Message	Unity FCE Hold Msg	Update Continuing Education Studies greeting scripts
Create VPN Account	Create VPN Account	Provide VPN access on the Enterprise or Data Centre VPN appliance (Palo Alto firewall)
Infobox DHCP Change	Infoblox DHCP	Changes or updates to Infoblox DHCP appliance
Add PortGroup	Add PortGroup	Create a new port group on a virtual switch (standard or distributed) for the VMware ESXi
Update an Existing Image	Image Update	Update academic lab/classroom images
Add SCOM Client	SCOM Client	SCOM client installation
SQL updates for PeopleSoft	PS SQL Script	SQL targeted data updates for PeopleSoft in the production environment
Switch Port Change	Switch Port Change	Add or change an existing user access switch-port virtual local area network (VLAN) configuration the specified VLAN ID number
Replace Redundant Power Supply	Network Power Supply	Replace any network device with dual power supply due to failure and/or capacity upgrade
PeopleSoft Query Changes	PS Query	Implement PeopleSoft queries for data extraction for reporting purposes
Java Application Bug Fix	Java App Bugfix	Apply bug fixes to a java application in the production environment
PeopleSoft Bugfix	PS App Bugfix	Apply bug fixes to PeopleSoft code in the production environment
PeopleSoft Security Roles	PS Security Roles	Apply minor changes requested from business teams that requires the PeopleSoft security team to implement the changes in a targeted production environment
FootPrints Roles and Fields	FP Roles and Fields	Configuration change for bugfixes or enhancements to User Roles; Field Maintenance/Dependencies (new service); Status; Priority
FootPrints Email Filters	FP Email Filters	Improve email ticket creation and revoke spam and domains that are not required in FootPrints
VoIP Logo	VoIP Background Logo	Create a temporary VoIP logo for monthly use (i.e.: CyberSecurity) and deploy temp VoIP phone logo and revert back to standard VoIP logo to all IP Phones college wide
My.Seneca Course Removal	BB Course Removal	My.Seneca System will be modified to remove the oldest courses so that the system maintains 4 semesters of data
Call Centre Scripts	Call Centre Scripts	Create and deploy revised call centre scripts and revert back to the original backed up script across all business departments college wide
PeopleSoft Minor Configuration Change - HR	PS-HR Minor Config	Configuration for a bugs or enhancements in PeopleSoft HCM
Sumo Logic log aggregator	Sumo Logic Sources	Configure a Seneca server or service to forward logs to the Sumo Logic log aggregator
Hyperions and BI	BI Artifact Hyperion Artifact	Deploy the changed BI/Hyperion Artifacts (Forms, Reports, Scripts) from BI/Hyperion Test /UAT environment to BI/Hyperion Production environment
Add VLAN to HP VirtualConnect	HP VC Add VLANS	Configure HP VirtualConnect (FlexFabric) internal switch in HP C7000 Chassis to create new VLAN in the switch and add the VLAN to port of the blades
Add LUN to vCenter	Add New LUN vCenter	Add new LUN(s) to storage cluster on vCenter
Create LUN on HPSAN	Create LUN HP SAN	Create new LUN(s) on HPSAN storage and grant access to client systems that requires access to use this new LUN(s)
Create LUN on NetAPP	Create LUN NETAPP	Create new LUN(s) on NetAPP storage and grant access to client systems that require access to use this new LUN(s)
Create Virtual Server /Pool/ Node on {URL-Solution} F5 BigIP	F5 Add VS/Pool/Node	Provide a Public/Internal access to our new solution/URL with load balancing mechanism and SSL Offloading for them and to Add the Nodes/Pool and Virtual Server/SSL to the F5 BigIP Appliance
Adding Services to ADFS	ADFS Configuration	Configure a relying party trusty entry and claims rule within our SSOFS 3rd party Active Directory Federation Services (ADFS) 2.0 infrastructure
Adding Microsoft SQL Instance	MS SQL Instance	MS SQL Instance installation (either cluster or standalone) to be used for new or to be migrated database(s)
Install Hotfix / Service Pack for Data Center Applications	Solarwinds Hotfix/SP Sumologic Hotfix/SP TrendMicro Hotfix/SP CommVault Hotfix/SP SCOM Hotfix/SP	Applying hotfix/update for the following Data Center applications: Trend Micro Deep Security Trend Micro Office Scan Trend Micro Control Manager CommVault Sumologic SCOM Solarwinds
Add VLANs to SCVMM	SCVMM Add VLAN	Add new VLAN(s) on System Center Virtual Machine Manager (SCVMM) for Hyper-V hosts
Windows Updates	Windows Updates	Install the latest updates or hotfixes on Seneca’s Windows servers
Creating and/or deleting VLANs on switches and routers	VLAN Add/Remove	Create and/or delete a virtual local area network (VLAN) configuration on network switches and routers
NAT Add/Remove	NAT Add/Remove	Create a network address translation (NAT) policy on a firewall
Router/Switch Software Updates	Router/Switch Update	Upgrade network router/switch software to provide performance, reliability and security improvements

8 Appendix B – definition of terms

Item / Acronym	Description
RFCs	Request for Change
eRFCs	Emergency Request for Change
SLA	Service Level Agreement
KPI	Key Performance Indicator
SEC	Senior Executive Committee

Note: A downloadable PDF is available: Customer support framework

Customer support framework | IT Strategies and Policies | Seneca Students

Customer support framework

1.1 Purpose and scope

1.2 Background

1.3 Audience

1.4 Procedure inputs

1.5 Procedure outputs

1.6 Approval(s)

1.7 Referenced documentation(s)

2 ITS service categorization

3 Managing operational changes

4 Managing planned changes

5 Managing service outages

6 Risk mitigation

7 Appendix A – approved standard change list

8 Appendix B – definition of terms

Search Wiki

Pages

Customer support framework | IT Strategies and Policies | Seneca Students

Customer support framework

Share

1.1 Purpose and scope

1.2 Background

1.3 Audience

1.4 Procedure inputs

1.5 Procedure outputs

1.6 Approval(s)

1.7 Referenced documentation(s)

2 ITS service categorization

3 Managing operational changes

4 Managing planned changes

5 Managing service outages

6 Risk mitigation

7 Appendix A – approved standard change list

8 Appendix B – definition of terms

Search Wiki

Pages

Loading ...