Vision Document CUSTOMER RELATION MANAGEMENT SYSTEM Version 1.0 Submitted in partial fulfillment of the requirements of the degree of Master of Software Engineering CIS 895 MSE Project Kansas State University Committee Members Major Professor: - Dr. Dan Andresen Dr. Torben Amtoft Dr. Mitchell L. Neilsen 1
TABLE OF CONTENTS 1. Introduction...4 1.1. Purpose & Motivation.4 1.2. Definitions, Acronyms and Abbreviations.5 1.3. References..6 2. Project Overview...7 3. Overall Description...7 3.1. Product Perspective...7 3.2. Product Functions...8 3.3. User Characteristics...9 3.4. Constraints...10 3.5. Assumptions and Dependencies...10 4. Specific Requirements.10 4.1. External Interface Requirements..10 4.1.1. User Interfaces...10 4.1.2. Hardware Interfaces...11 4.1.3. Software Interfaces...11 4.1.4. Communication Interfaces.11 4.2. Functional Requirements..11 4.2.1. Managing Registration Process..11 4.2.2. Managing Login Process 12 4.2.3. Assigning User Roles.12 4.2.4. Query Creation/Ticket Creation.13 4.2.5. Status Check..13 4.2.6. Assigning Tickets to Tech Users 14 4.2.7. Change Ticket Status..14 4.2.8. Send Email Response.15 4.2.9. Search Ticket..15 4.2.10. Create a Ticket Sub-Category...16 4.2.11. Sign Off.16 2
4.3. Design Constraints 16 4.4. Software System Attributes..16 4.5. Performance Requirements...17 4.6. Other Requirements..17 3
1. Introduction 1.1. Purpose & Motivation The purpose of this document is to provide a complete description of all the critical requirements, available recourses, functionality constraints and specifications of the CRMS. It also provides a detailed overview of the product, its parameters and goals. Many changes are expected in this document before the completion of the project. Any changes will be recorded and reported to the supervisory committee for their approval. Preparing this document is to create a layout of the project by recording the various constraints and requirements essential for the project. My motivation for CRMS has come from my very experience with a poor customer service at a company. Many people will be familiar with these experiences. They will frequently tell you that someone will call you back within $ time which of course they never do. Every company that gives lip service to customer service but doesn t really deliver it opens up opportunities for those few companies that actually do practice extraordinary customer service. We all know that a central goal of every business is to serve its customers. Success or failure has hinged on this simple rule. Customer Relationship Management System (CRMS) is a way of using technology to do just that. Customer relationship management system can be used by companies for maintaining a good and timely relationship with their customers. It helps them to learn more about the needs and behavior of the customers, hence helping companies in maintaining a stronger tie-ups by dealing with their customers efficiently and effectively. CRMS provides on time reports and information about their prospective customers and this helps companies to actuate the timely action for that customer. This in turn creates a good and productive relationship with them. Due to Data Centralization at one place, Companies can quickly generate different user reports, user histories, user activities, user queries, user emails. In this world of fast communication where everyone is busy in his own work, requires the medium through which his problems are solved without much of time wastages and physical 4
efforts. Companies prefer to have a Web Based Complaint Management System (Query Management) installed at their end which accepts the query's and requests online onto their websites from the customers and provide the Online Solution to it through relevant information and/or patches. On time solution of customer s complaints and feedback is what differentiates companies in their work process. CRMS helps organizations manage, assemble and analyze customer complaints and feedbacks to improve customer service. CRMS allows any front-office staff to analyze client history and respond to any customer queries in short time. Also, a manager can track how well the query management is functioning. Support staff can be anywhere in the world. CRMS provides a hassle free way of managing customer queries. 1.2. Definitions, Acronyms and Abbreviations Helpdesk User A user who speaks with the customers and distinguishes between a Query / Complaint / Request and creates a Ticket. He can also check the status of a Ticket. Supervisor A Supervisor is a privileged user responsible for managing users and Ticket sub- categories. He is also responsible for assigning pending Tickets to Tech Users depending upon their skills. Tech User A Tech User who is assigned a Ticket, works to resolve the issue with this Ticket. He can update his work progress. Customer A Customer is a user who has a Query / Complaint / Request. He can either create a Ticket by himself or can call the Helpdesk User to create one. UID UID is a unique id which a user requires to have. As part of the login process in CRMS, user will be asked to provide his User ID (UID) and password, which the user has created during the time of registration. 5
Ticket Support requests sent in via email, through the web or over the phone to Helpdesk User can be identified with a help of a Ticket. This is a unique Number assigned to each Complaint / Query / Request. Complaint Complaints are generated if there is any product malfunction. Understanding the main types of customer complaints is a key to handle them correctly. Many problems are "location dependant". Including the exact location of the problem speeds most troubleshooting tremendously. Query Questions like how to upload a file, how to create an account, how to use any software, Information about backups and file recovery etc Request Request for new software s, password requests etc. Sub-Categories Sub-Categories are used to organize the entire project. As series of pages are difficult to navigate, we sub categorize them under Query / Complaint / Request which organizes categories by topic. 1.3. References UML Diagrams: http://www.visual-paradigm.com/product/vpuml/. CIS 748 Course Lectures by Dr. Scott Deloach. IEEE Recommended Practice for Software Requirements Specifications. http://www.wikipedia.org/. 6
2. Project Overview CRMS is a web application developed to provide a platform where an Organization can comprehensively manage complaints, Queries and Request from Customers. The real-time visibility provided by the CRMS enables an Organization to track each complaint, Query, Request through its lifecycle from recording and initiation to investigation, reporting, and closure. The reporting capability of the CRMS helps the Organization to perform trend analysis and spot recurring problems. Based on a complaint, one can trigger corrective and preventive action. Using the CRMS system increases Customer satisfaction and retention through improved responsiveness. The important feature of this application is that summary report can be viewed using the reporting services. Also complaints, Queries or request remainder mails can be sent. The purpose of this document is to lay down the various processes that need to be adopted at the time of registering any query or complaint with a company. Section 3 of this document gives a general overview of the system. Section 4 gives more specific requirements for functions offered. 3. Overall Description 3.1. Product Perspective The product is a totally independent and self-contained running Windows 7 and IIS (Internet Information Server). 7
3.2. Product Functions CRMS software provides (number) types of functions. Functions available for Customers: Create a Query / Complaint / Request with the help of his unique id. Check Ticket Status using Ticket number or with the help of his UID. Functions available for Helpdesk User: Create a Query / Complaint / Request for anybody who has an UID. Check Ticket Status using Ticket number or with the help of Customer s UID. Functions available for Tech User: Check Ticket Status of Tickets assigned to him or can also view Customer s history using the Customer s UID. Functions available for Supervisor: Create a Query / Complaint / Request. Check Ticket Status using Ticket number or Customer s UID or Tech User s UID. Manage Users. Manage Ticket sub-categories. 8
USE CASE DIAGRAM 3.3. User Characteristics The system supports different types of users: Customers - Non-privileged users are Customers. They will use the system to create a Query / Complaint / Request and view specified reports i.e. reports of their Tickets. 9
Helpdesk User - They will use the system to create a Query / Complaint / Request and view all reports. Tech User - They will use the system to create a Query / Complaint / Request and view reports of Tickets created by them and also view reports of all Tickets assigned to him. Supervisor - Privileged user is the Supervisor. In addition to using the above functions, they will use the system to modify Ticket sub-categories and create and remove users. All users would need minimal training before using the application. 3.4. Constraints The CRMS must be implemented to work with any browser. CRMS should be user friendly. CRMS must be responsive and efficient enough not to irritate Customers (refer section Performance requirements). 3.5. Assumptions and Dependencies The system on which the software product is hosted should have reasonable storage capabilities. 4. Specific Requirements 4.1. External Interface Requirements 4.1.1. User Interfaces The user interface will be a Graphical User Interface (GUI). Basic screen formats may consist of drop down menus, push buttons and data entry fields. Details about the user interface will be further defined in the design document. 10
4.1.2. Hardware Interfaces Not applicable. 4.1.3. Software Interfaces The system will be created to be used with a Windows 7 / Windows 2000. 4.1.4. Communicational Interfaces The system runs on a Windows 7 / Windows 2000 workstations communicating over a Local Area Network (LAN). The workstations are connected to the server through a LAN. Thus, the interface is unimportant to the scope of this project. 4.2. Functional Requirements 4.2.1. Managing Registration Process Purpose: The purpose of this part of the application is registration of a new User which would allow a new User to become a member of the CRM system. Input: The User enters registration information. E.g. Name, Address, Email, Contact Number, User Name, Password. The User Name is nothing but the UID. Processing: System checks user name to see if it is valid. If the user name already exists, the user needs to choose a new user name. Otherwise, the customer information is saved to the database. Output: For correctness, the customer inputs will be validated. If the customer inputs violate any input format, the appropriate error message will be displayed. If the customer inputs are valid, then a confirmation is shown. 11
4.2.2. Managing Login Process Purpose: The purpose of this part of the application is to provide user authentication. A valid user account must be used if you are an existing User and a new User can register. Inputs: The user enters a user name and a password. Processing: The user inputs will be validated and authenticated by checking the user name and password to see if they match the data stored in the database. Outputs: If the user name or password is not valid, the appropriate error message will be displayed and the user needs to re-enter user name and password. If the user inputs are valid the user would be given access to the System. 4.2.3. Assigning User Roles Purpose: In this part of the application Supervisor assigns User Roles or update the User Role. Input: The Supervisor selects a User and a User Role to be assigned to the User. Processing: The Supervisor selection will be validated and accordingly the action is being performed against the user s account at the server. Profile is then updated accordingly at the server. Output: The request will be validated and upon successful validation, the Users account is updated and a confirmation is displayed. Otherwise an appropriate error message is displayed. 12
4.2.4. Query Creation/Ticket Creation Purpose: The purpose of this part of the application is to add a new Query / Complaint / Request. Input: User: UID Ticket Category: Request, Query or Complaint. Sub Category: Different issues pertaining to the issue category. Priority: Low, Normal or High. Subject: Issue Subject line. Problem Description and Remarks: Detailed explanation about the issue. Attachments: If any attachments required/relate to the issue. Processing: The input is validated and upon successful validation the information is saved to the database and a new Ticket is created. Based on the information filled in, details are added to database for further processing. Output: Upon successful validation a new ticket is created and a confirmation is displayed. Otherwise an appropriate error message is displayed. 4.2.5. Check Status / View Status Purpose: The purpose of this part of the system is to check the status of the Ticket. Inputs: Ticket Number. Processing: The System validates the Ticket Number and retrieves the ticket Status. Output: The Ticket Status will be displayed if it is a Valid Ticket; else an appropriate error message is displayed. 13
4.2.6. Assigning Tickets to Tech Users Purpose: Supervisor views and assigns the generated unassigned ticket to a Tech Users based on their skill set. Inputs: Unassigned Ticket Number and Tech User s UID. Processing: Based on the assignment process, details are added to database for further processing. Output: Related Status will be displayed. 4.2.7. Change Ticket Status Purpose: The system must help the Tech User find the Ticket and change its status according to the progress of the Ticket. Input: The Tech User fills in UID, Ticket Number and the Ticket Status to which the ticket has to be changed. Processing: The inputs are used as search criteria for searching the database and details are added to database for further processing. Output: A list of all enquiries matching the search criteria is displayed. The list will include all the details of that ticket. Against each record, there will be a provision to modify the status. 4.2.8. Send Email Response Purpose: The system must allow the Supervisor to add feedback information or send a response for a particular Ticket. The feedback or response is in a form of an email. 14
Input: The Input required is Ticket Info, Feedback By, Feedback On, Feedback Text, Remarks, and Mode of feedback. Processing: The input is used to create a new response. Output: When processing completes, it sends an email to the Ticket holder or an error will be returned if one occurs. 4.2.9. Search/ Modify Ticket Information Purpose: The system must allow the login user to search the database for respective Ticket and also modify Ticket Information. Input: The function requires as Input Ticket Number and the changes to be made. Processing: The system searches the database based on the search criteria. The resultant list includes Ticket, UID and Name. The system should allow the user to modify information. Output: When processing completes, an error will be returned if one occurs. 4.2.10. Create a Ticket Sub-Category Purpose: The part of the application is used by a supervisor to create a Sub-Category. Input: Name of the Sub-Category to be added and the Category under which it has to be added. 15
Processing: Adds a Sub-Category to the Specified Category (Complaint / Query / Request). Output: New Sub-Category added without change in design. 4.2.11. Sign-Off Ticket Purpose: After the Tech User updates the Task with the action taken. Supervisor will check the resolution and sign off the case. Supervisor signs off and closes the ticket. Input: Supervisor Checks for status change (complete) by the Tech User. Processing: Supervisor after he finds it signs off and closes the ticket. Output: Ticket closed. 4.3. Design Constraints Software Limitations The system is implemented in.aspx and C#. The platform for the system shall be Windows 7. 4.4. Software System Attributes Security The functions described in section 4.2 are restricted to users described above who are considered as CRMS users. Each authorized user will be assigned a login id and a password. 16
4.5. Performance Requirements The responses of the CRMS must be fast enough not to irritate the Customers. The system must handle Query / Complaint / Request per day and generates type of reports as many times per day. With this maximum load, 90% of the requests should be answered in less than 1 second and 9% of the requests should be answered in less than 10 seconds. Situations in which a login user request takes more than 1 minute should be less than 1%. 4.6. Other Requirements Requirements Backup strategy has to be developed. 17