Automated Support System Specifications
Incident Management
The new automated support system should include advanced incident management with the ability to log and track incidents from multiple channels (e.g. email, phone, and web) within a centralized database. It should provide web access for all authenticated agents and customers to submit incidents, check status of incidents and update/change incident information.
Agents and customers should be able to create, save and select from multiple ticket templates, and generate a ‘quick incident’ with pre-populated field selection and response information.
Agents should be able to do advanced searching within incidents and define and save their own views. User-defined fields should be capable of validation and the requirement of mandatory completion. The system should include automatic escalation of incidents based on defined business rules.
Customization
The application should be easily configurable and customizable, including the ability to customize the look & feel of the application and customize forms by adding new fields or renaming default fields. Customizations should be maintained when an upgrade occurs and it should be possible to turn on/off or hide functionality that is not required.
Notification and Email Management
The application should have the ability to send automatic notifications to both agents and customers based on defined business rules. These may be targeted audience notifications available through multiple channels, including email, paging, VoIP, web alerts, SMS, etc. For example, these notifications might broadcast messages to targeted audiences of major outages, or other important information. The system should also be able to automatically read an email into the system and generate an incident ticket.
Knowledge Base
The system should have strong knowledge base functionality that is tightly integrated with incident management and end user self-service. Agents should have the ability to easily launch a search with information from an incident and attach solution links to customer responses and incidents. They should also have the ability to send solutions to the knowledge base. Permitted users should be able to set visibility of knowledge base articles and manage content before publishing. The knowledge base should extend itself to self-service so that end-users are encouraged to search the knowledge base before submitting an incident online.
Other beneficial features would include the ability to do a ‘natural language search’ within the knowledge base and perhaps ‘Google’ search. With the rising popularity of Knowledge Centered Support (KCS), and the common sense approach it provides to create content during the workflow, it would be beneficial if the application were KCS verified.
Asset Management
The application should integrate with an asset management module that would have the ability to query/discover and manage assets and might be capable of querying a network port for the instance of a phone, checking port usage statistics and error statistics and perhaps turning ports on/off.
General
The product should adhere to a standard best practice framework, e.g. ITIL. It should integrate with Microsoft Active Directory and/or a non-Microsoft LDAPv3 compliant directory. Contact information for an incident should be populated automatically from the LDAP content once a contact is selected. It should also be possible to use LDAP for Single Sign-On.
It would be beneficial if the product included 'built-in' administration utilities for data maintenance. The application should be scalable to provide service for approximately 20 concurrent agents and expand to more than double this amount. It should support unlimited customers to meet the needs of the University of Guelph supported community.
The vendor should provide accessible published application programming interfaces to allow for integration with other products and services. The application database should allow for exporting and importing of data in standard file formats.
Reporting should include standard canned reports and the ability to create, save, print and export customized reports. Dashboard style reports that might be used by management, which would display real-time information in a graphical format, would be beneficial.
It is a requirement that the system be able to extend itself to other areas on campus. This should include the ability to easily create ‘satellite’ service desks. Access to these ‘satellite’ desks would be restricted based on roles and permissions. It would also be beneficial for specified agents to be able to move incidents from one ‘satellite’ service desk to another.
The product should be accessible to users with disabilities so that they can perceive, understand, navigate, and interact with the software.
The product should also integrate with other 3rd party database systems being used in CCS as well as integrate with in-house developed software. It would be beneficial if the product allowed for a dynamic field link to another database.
The ability to create customer surveys and automate their delivery on a regular basis without sampling customers who have recently responded to a survey is also a requirement.
The product should integrate with University of Guelph web portal. Several factors will make this integration easier, including a module for Single Sign-On for a portal environment, a JSR168 portlet to access the system, an RSS or ATOM feed to look at a list of incidents, and by following web services for remote portlets (WSRP) standards.
Other useful features would include the ability to save and quickly access a library of default (canned) email responses, scheduling or calendaring capabilities, live chatting options, and remote support ability.