TIP Final Report Mba - Tech (IT) 136

TIP Final Report 2013
Cover Page
SVKMs Narsee Monjee Mukesh Patel School of Technology Management and Engineering
A REPORT ON
Developing a Customer Relationship Management System (CRM)
By:
Tejas Shah
MBA (Tech) Information Technology Roll No. : 136 th IX Trimester, Batch of 2015
Based on the Technical Internship undertaken in
Edelweiss Tokio Life Insurance Company Ltd.

I|Page
A REPORT ON
Developing a Customer Relationship Management System (CRM)
By:
Tejas Shah
MBA (Tech) Information Technology Roll No. : 136 IXth Trimester, Batch of 2015
A Project Report submitted in partial fulfillment of the requirements of 5 years integrated MBA Tech Program of Mukesh Patel School of Technology Management and Engineering, NMIMS University.
Distribution List: Mr. Bhavin Shah Senior Manager (WebSales), Edelweiss Tokio Life Insurance Company Ltd. (Industry Mentor) Indrani Sengupta (Faculty Mentor)
II | P a g e

SVKMs NMIMS (Deemed-to-be University) Mukesh Patel School of Technology Management & Engineering Vile Parle (W), Mumbai - 400 056. TECHNICAL INTERNSHIP REPORT IX TRIMESTER MBA (TECH) Submitted in Partial Fulfillment of the requirements for Technical Project/Training for IX Trimester MBA (Tech). Name of the Student : Roll No.: & Batch : Academic Year: Name of the Discipline: Name and Address of the Company:
TIP Completion Certificate
Training Period: From
To
THIS IS TO CERTIFY THAT Mr./Ms._______________________________________________________________________ Exam Seat No. has Satisfactorily Completed his/her Training/Project Work, submitted the training report and appeared for the Presentation & Viva as required.
External Examiner Date: Place: Seal of the University
Internal Examiner
Head of Dept.
Chairperson/Dean
III | P a g e
TIP Final Report 2013 Acknowledgements

TIP at Edelweiss Tokio Life Insurance Company Ltd. (ETLife) was one of the most amazing and worthwhile experience for me. Being my 1st Professional experience at the industry, I used to think it would be quite a tiring task and a boring one to work in a company, but totally proving me wrong the environment in the work area was never so boring. In fact working with so many wonderful people in the organization, it was indeed a smooth journey till the end. First and foremost, I would sincerely like to thank Mr. Bhavin Shah (Sr. Manager) for being an ideal mentor; helpful, motivating and inspirational. He always being there to support technically as well logically coming up with unique ideas to work things around. I would also like to thank Mr. Avadhoot Puranik (Operational Manager) for helping us out logically so we can practically implement new functionalities into our System, Mr. Swapnil More (Project Manager) and Mr. Nelson Dmonte, under whom I got to learn so many new things which I never thought I would be able to do .Helping me to understand what the working of the existing system was and what we wished to implement into our new System. The entire Team of WebSales of which I was a part has helped me grow my skills in every possible ways. The time I spent at the organization was the best Learning Phase of my life and would love to work with such a time if given opportunity in future. I would also like to thank Ms. Indrani Sengupta, my faculty supervisor for her support and encouragement. Finally I would like to thank ETLife for giving me such a wonderful opportunity to work under its WebSales department and making this Internship a memorable one. I am really grateful to have been associated with Edelweiss Tokio Life Insurance Company Ltd.
IV | P a g e
Table of Contents
Cover Page ..................................................................................................................................................... I TIP Completion Certificate ........................................................................................................................... III Acknowledgements...................................................................................................................................... IV List of Illustrations ........................................................................................................................................ VI 1. 2. 3. Abstract ................................................................................................................................................. 1 About Edelweiss Tokio Life Insurance ................................................................................................... 2 Introduction .......................................................................................................................................... 3 3.1 3.2 4. 5. Purpose, Scope and Limitations .................................................................................................... 3 Sources and Methods ................................................................................................................... 4
Industrial Analysis ................................................................................................................................. 5 Pre-Development Analysis .................................................................................................................... 9 5.1 5.2 5.3 Features and Functionality Analysis.............................................................................................. 9 Technical Analysis ....................................................................................................................... 10 System Requirements ................................................................................................................. 11
5.4 Business Analysis............................................................................................................................... 11 6. Developing BOSS CRM System ............................................................................................................ 13 6.1 6.2 6.3 6.4 Login Module .............................................................................................................................. 15 Dashboard Module ..................................................................................................................... 17 Notifications Module .................................................................................................................. 23 New Business Module ................................................................................................................. 26 Download Documents......................................................................................................... 26 Additional Info..................................................................................................................... 27 Email Dashboard ................................................................................................................. 29 Admin Override ................................................................................................................... 32 Customer 360 Degree ......................................................................................................... 33
6.4.1 6.4.2 6.4.3 6.4.4 6.4.5 6.5 6.6
Ticket Module ............................................................................................................................. 39 Feedback Module........................................................................................................................ 45 V|Page

6.7 6.8 User Info Module ........................................................................................................................ 46 Partners Module ......................................................................................................................... 48
7.0 Database Development......................................................................................................................... 52 8.0 Conclusion ............................................................................................................................................. 54 9. References .............................................................................................................................................. 55
VI | P a g e
List of Illustrations
Figure 1 : Rapid Application Development Model ........................................................................................ 4 Figure 2 : Overall Process of Policy Issuance ................................................................................................ 5 Figure 3 : The WebSales Platform ................................................................................................................. 6 Figure 4 : Policy Issuance process at the Company's end ............................................................................. 7 Figure 5 : The Prototype used prior to the new system ............................................................................... 8 Figure 6 : The Online Sales Architecture ....................................................................................................... 8 Figure 7 : The Login Module ....................................................................................................................... 15 Figure 8 : The Login Module with Forgot Password feature ....................................................................... 16 Figure 9 : Dashboard Module with hover on Line Graph............................................................................ 17 Figure 10 : Dashboard Module with hover on Bar Graph and ITD stats below .......................................... 18 Figure 11 : Dashboard Module with Support Summary and To-Do Task feature....................................... 19 Figure 12 : Dashboard Module with edit To-Do Task feature .................................................................... 20 Figure 13 : Dashboard Module with restricted access to user ................................................................... 21 Figure 14 : Dashboard Module with the autocomplete Searchbox ............................................................ 22 Figure 15 : Notification Module Latest Notificaiton view ........................................................................ 23 Figure 16 : Notification Module - All unread view ...................................................................................... 24 Figure 17 : NewBusiness Module - Download Documents ......................................................................... 26 Figure 18 : NewBusiness Module - Additional info Medical view............................................................... 28 Figure 19 : NewBusiness Module - Additional info Non - Medical view ..................................................... 28 Figure 20 : New Business - email dashboard view ...................................................................................... 29 Figure 21 : New Business - Email Dashboard view ..................................................................................... 30 Figure 22 : Prototype - Email Dashboard view ........................................................................................... 31 Figure 23 : New Business - Admin Override................................................................................................ 32 Figure 24 : New Business - Cutomer360 Summary view ......................................................................... 33 Figure 25 : New Business - Customer360 - Contact History view ............................................................... 34 Figure 26 : New Business - Customer360 - Contact history view ............................................................... 35 Figure 27 : New Business - Customer360 - Case History ............................................................................ 35 Figure 28 : New Business - Customer360 - Personal Details view .............................................................. 36 Figure 29 : New Business - Customer360 - Product Details view ............................................................... 37 Figure 30 : New Business - Customer 360 - Policy Service History view..................................................... 38 Figure 31 : New Business - Customer360 - Policy Service Modal window ................................................. 38 Figure 32 : Ticket Module - Manually Add a new Ticket ............................................................................. 39 Figure 33 : Ticket Module - List View .......................................................................................................... 41 Figure 34 : Tickets Module - Tickets List View ............................................................................................ 42 Figure 35 : Tickets Module - Ticket Mail View ............................................................................................ 43 VI | P a g e

Figure 36 : Ticket module - merge ticket feature ....................................................................................... 44 Figure 37 : Feedback Module ...................................................................................................................... 45 Figure 38 : User Info Module ...................................................................................................................... 46 Figure 39 : User Info Module - Add Customer view.................................................................................... 47 Figure 40 : User Info Module - Delete Customer View ............................................................................... 47 Figure 41 : Partners Module ....................................................................................................................... 48 Figure 42 : Partners Module - Edit Partner View ....................................................................................... 49 Figure 43 : Partner's Module - Add Partner View ....................................................................................... 49 Figure 44 : Partner's Module - Products View ............................................................................................ 50 Figure 45 : Partner's Module - Add New Product View .............................................................................. 51 Figure 46 : Oracle SQL developer ................................................................................................................ 52
VII | P a g e
TIP Final Report 2013 1. Abstract

Customer Relationship Management is an important aspect of Business process. A Company would maintain its efficiency and customer loyalty if it has a well-developed Customer Relationship Management System. In todays e-commerce competition it is really difficult to maintain a track of customers which buy the services online. Not only the customers are to be tracked and maintained but also the prospects or the leads who due to some reason may have not purchased the service or products are also to be consulted or it may result into business loss as not all customers are acquainted with the e-commerce way. This project understands the processing of the Insurance Policies at Edelweiss Tokio Life Insurance Company Ltd .We will be focusing on the WebSales Channel of this company which looks after the online business of the company. The Entire process from enquiry by a client to the issuance of policy over the internet is handled by this Channel. The Project Report would explain the Processes involved in issuing a policy online in detail and the various stages it goes through before a complete policy is issued. It also looks after the Policies which are about to mature and need to be Renewed if the customer wishes to. This Report describes about how the Customer Relationship Management (CRM) System named BOSS (Best Online Support System) would serve the purpose of the company to maintain the loyalty and better relationship with the customers. The System refers a prototype which was till now being used to maintain customer records. Using the minimal Functionalities developed in the prototype this system enhances them and also includes more advanced features which reduces the workload on the employees. The System is such developed keeping into mind the Security features which lookup to the confidentiality of the customers. Role Based Access is the approach taken to make the system secure. Using this system the employees would not have to make use of various email client software like outlook as all the mails would directly be synched from the companys mail server directly into this system from where the employee would be able to interact with customers. This report would describe how the system was developed from scratch using various software development tools and scripting languages and how it helped reduce the manual workload that was essential prior to this system, BOSS.
1|Page
TIP Final Report 2013 2. About Edelweiss Tokio Life Insurance

Since its inception in 1996, Edelweiss has seamlessly grown into a large diversified financial services organization offering businesses ranging from Credit, Capital Market, Asset management, Housing Finance and Insurance. Currently, the groups net worth is in excess of INR 2,800 Crores. Present across 308 offices in 140 cities, the group, with over 2800 employees, and services a client base of more than 3,50,000. The Groups core brand philosophy, Ideas Create, Values Protect is translated into an approach that is led by entrepreneurship and creativity, protected by intellectual rigor, research and analysis. Edelweiss has been recognized as a Business Super brand in the year 2011 by Super Brands India, testimony to the reputation enjoyed by the brand. Entering the Insurance Sector by merging with the giant from Japan, Tokio Marine Holdings Inc. One of the oldest and biggest firms in this sector has interests in Life, Non-Life, and Re-Insurance. It has been present in 427 cities across 39 countries around the world. The company has over 130 years of operational history in Non-life Sector while it has been in Life Insurance since 1996. It has a presence in Japan, China, Singapore, Malaysia and Thailand. A highly respected company around the world, Tokio Marine adheres to Japanese high standards of quality and a robust corporate governance and risk management framework.
The Merger of these two companies led to Edelweiss Tokio Life Insurance Company Ltd. Edelweiss Tokio Life Insurance is a new generation Insurance Company, set up with a startup capital of INR 550 Crores, thereby showing our commitment to building a long term sustainable business focused on a consumer centric approach. As a part of the companys corporate philosophy of customer centricity, our products have been developed based on our understanding of Indian customers diverse financial needs and help them through all their life stages.
2|Page
TIP Final Report 2013 3. Introduction

3.1 Purpose, Scope and Limitations
The WebSales Channel of the company had developed a prototype with minimal functionalities that were used to track the customer records which included the premium details, the personal details of the customer and the amount of sum insured and various other product details that was purchased by the customer. However it was very difficult to gather the required information quickly and not all features of a Customer Relationship Management (CRM) system were available to the employees increasing the manual workload like viewing the documents of proof uploaded by the customer, his personal details, the emails to be sent to the customer as a reminder for pending documents or even the renewals of lapse policy were to be taken care of. The purpose of developing the BOSS (Best Online Support System) CRM system was to make all the required information available as quick as possible and to automate the work. The main features of this system include real-time notification about the document uploaded or payments success/failure as well as the necessary questionnaire to be filled before issuance of policy. It also provides daily sales statistics in graphical form as well as till date sales analysis. This system would provide the necessary features that the customer support executives require while interacting with the customers. It would also have advanced features which are only accessible to the senior management employees keeping into mind the confidentiality of the customers. This system would be restricted to intranet LAN network of the company along with the access control through user login and tracking the actions performed by the executives. The scope of the system is that it only covers the customers or the leads (potential customers) over the WebSales channel and limitations of this system is that it requires one of the windows service which is also a part of this project explained later, to be functioning all day long so that it can capture all the mails and display them directly into the BOSS System.
3|Page

3.2 Sources and Methods
The vital sources for this project include the prototype developed which was very helpful in understanding how the current working of the system should be as it concentrated on the minimal n most important requirements. Other important sources used were those available over the internet in form of tutorials and various forums were referred to develop the system of which asp.net forum and stack overflow were the often referred ones. The method followed while developing the system was Rapid Application Development (RAD) due to time restraints on the project and our term as interns in the
Figure 1 : Rapid Application Development Model
company. We split the system into modules so the development would be quick and smooth and then integrate the modules for testing .The idea was to develop an interface in the prior stage as per the requirements and then to combine the interface with the backend (database) development. The method used to develop a User Friendly and smooth interface the 5 Plane approach of User Experience was adopted. This technique helped to create the User Interface more quickly and efficiently in the system. The 5 plane approach included the surface plane, skeletal plane, structure plane, scope plane and strategy plane.
4|Page
TIP Final Report 2013 4. Industrial Analysis

The WebSales channel of Edelweiss Tokio Life Insurance for which this project was developed looks after the online sales of the company. The overall process that is followed for a complete issuance of policy is described as follows:
Figure 2 : Overall Process of Policy Issuance
As the customer browses the web page of the company and wishes buy any product he is redirected to the WebSales landing page where the WebSales platform guides the customer to choose the appropriate amount of policy term and sum to be assured for the appropriate cause from amongst the 3 policy plans that company sells viz. Cashflow Protection Plan, Education plan, Protection plan and SP Endowment plan. The sales platform is developed such that it guides the customer to fill in the personal details, educational details, lifestyle and health details as well as the nominee in case appointed by the customer. In case the customer due to any reasons is unable to complete the application and aborts the procedure he is sent an email of incomplete application with a unique application ID using which he can complete the incomplete application whenever the customer wishes to right from the place where he left it earlier.
Once the Customer is done with the application filling he is then asked to take a print of application form generated by the platform and thereafter he is directed to the payment gateway where the customer completes the payment. On successful payment the
5|Page

customer is sent 2 emails regarding the documents of proof which are pending to be submitted and another welcome mail from the company.
Figure 3 : The WebSales Platform
Thereafter the customer is redirected to fill up a feedback form where he is questioned about the transactional and user guidance experience. The customer can also make any suggestions regarding the products offered by the company.
6|Page

However there is quite a lot more that happens on the companys end that the customer is not aware of i.e. after the customer has made the payment and before the policy is completely issued to the customer. Heres the details description of the process that happens in between these two stages.
Figure 4 : Policy Issuance process at the Company's end
This figure above shows the actual process of the policy issuance that is undertaken once the customer has duly filled up the application form and made a payment towards the same. Edelweiss Tokio Life (ETLife) on receiving the application form verifies the details provided by the customer such as document of proof submitted by the customer and in case the customer hasnt a reminder for the same is sent to him. The Operations Department verifies the Bill Report for realization of payment after which the Bill Receipt for the customer and the uploaded documents are sent for verification and data entry process. In case of any Additional requirements are to be required from the customer or any verification is required before the final issuance of policy it is here when the Support Executives would follow up for the requirements. Under certain circumstances the policy cannot be issued as the customer wished to have in terms of the sum insured or the person to be insured a counter offer is raised to the customer.
7|Page

To manage the customer details and the documents uploaded along with the lead i.e. potential customers who have not completed the application due to any reason are tracked through a prototype of Customer Relationship Management System which was developed with minimal but essential functionality.
Figure 5 : The Prototype used prior to the new system
To improve this prototype and build a more efficient Customer Relationship system was the main purpose of this project. Since this prototype had vital feature and functionalities which were used till now they are also implemented in the BOSS (Best Online Support System) CRM system. This CRM system would turn out to be a part of the WebSales architecture and would be available for the service executives and other employees of the channel.
Landing Page (website) WebSales Platform Customer Relationship Management System.

Figure 6 : The Online Sales Architecture
8|Page
TIP Final Report 2013 5. Pre-Development Analysis

Prior to begin with development of the system it was important to understand the process involved in policy issuance and the current scenario about how the work was carried on before the development of the system and how beneficial it would post the development of the new system. Keeping all this in mind analysis of the features and functionality available in market sold Customer Relationship Management Systems were observed and on basis of that the necessary features for our system were short listed.
5.1 Features and Functionality Analysis

Referring to the market sold Customer Relationship Systems certain features and functionalities that would ease the processing of the WebSales Channel were shortlisted. Along with these factors that were considered included the current shortcomings of the prototype that was being used and the extra manual workload that was imposed on the employees due to lack of a Customer Relationship Management System. The functionalities and features that were shortlisted included:
Features Document Management: Proof Management Other Policy Documents (Application Form) Dashboard Management: Statistical Overview Customer Info : Notifications To-Do Lists Tickets Summary Lead Management : Tickets Tracker Conversation Tracker Personal n Product Details Features Email Management : Reminder Emails Confirmation Emails Leads Management
Tickets System : Lead Callback and follow ups Customer Grievances management
Feedback : Trackers : Feedback reports from the sales platform Renewals: Renewal Follow up & reports
Pre-issuance tracker Policy status tracker Cancellation tracker Renewals tracker Customer/Lead tracker
9|Page

Partners Info : Admin Override: Records of partners and products associated Access to modify details of customer Customer 360 : Complete Customer Details with grievances
5.2 Technical Analysis

To develop such a system and to link it to the WebSales architecture consisting of landing page and the platform both of which were developed on the ASP.NET architecture, it was important to know about the ASP.NET architecture. ASP.NET is a server-side Web application framework designed for Web development to produce dynamic Web pages. It was developed by Microsoft to allow programmers to build dynamic web sites, web applications and web services. It was first released in January 2002 with version 1.0 of the .NET Framework, and is the successor to Microsoft's Active Server Pages (ASP) technology. ASP.NET is built on the Common Language Runtime (CLR), allowing programmers to write ASP.NET code using any supported .NET language. The Version 4.0 ASP.NET Architecture is used to develop the system. The Core Development language used under ASP.NET 4.0 architecture was C#. C# was developed by Microsoft within its .NET initiative. C# is one of the programming languages designed for the Common Language Infrastructure. The most recent version is C# 5.0, which was released on August 15, 2012. To Develop an efficient User Interface scripting languages like JQuery was to be studied before we begin the development. Along with this the backend development (database) was done using ORACLE SQL (Structured Query Language).
10 | P a g e

The Software used to develop the system were Visual Studio 2010 in which the programming of the system was done under ASP.NET 4.0 architecture using C#, HTML, JavaScript, JQuery and AJAX. The backend programming was done using ORACLE SQL Developer which used Oracle SQL as query language.
5.3 System Requirements

BOSS (Boss Online Support System) CRM system is developed using following tools which are its requirements. IIS (Internet Information Service) Manager with Asp.Net 4.0 architecture support SMTP support in IIS Manager. Windows Server 2000 or later. Oracle Database server. Visual Studio Dedicated Windows service developed for load balancing with Ticketing Module of the system
5.4 Business Analysis

Prior to starting the development of the system it is very important to have some business analysis done. The business process is thoroughly analyzed in this phase focusing more on the things required for the development of the system as per the requirements. The primary reason for this is to understand the problems and challenges faced and to find solutions to be implemented in the system so as to overcome those challenges. Certain business terminologies along with the flow of business process were analyzed in this phase.
11 | P a g e

The Analyzing of the business would be only restricted to the WebSales channel in this report. The pre-issuance phase of the policy is where the policy details and the necessary requirements from the company end are checked for and the necessary documents and questionnaire to be filled by the customer in case of NRI or the customer is willing to be travelling abroad has to fill the Foreign Travel Questionnaire. Once the policy has been issued the customer has been granted a free look period whereby the customer can cancel the policy if he does not find it as per his needs or can ask for further more clarification on the policy specifications. The free look period for all other channels in ETLife is 15 days whereas only for the WebSales channel the free look period is granted for 30 days. After these 30 days the customer cannot cancel his policy unless some exceptional circumstances which is decided by the undertaking department. In case the customer fails to pay his second or any premium his policy is under the lapsed status where the policy becomes inactive. In order to revive the policy the customer has to pay the pending premiums along with some penalty fees. Now coming to some statistics that are to be followed while developing the system include the sales figures, and other analysis terms involved in the business like APE, AWPI modal premium, frequency, riders etc. APE Annual Premium Equivalent (total premium * frequency) AWPI Average Weighted Premium Index (Product Weightage * premium) Modal Premium The mode of the premium to be paid Riders the benefits provided with the policy.
12 | P a g e
TIP Final Report 2013 6. Developing BOSS CRM System

The Software Development Model used in the development of BOSS CRM system is the Rapid Application Development Model. This model is suitable due to the time constraint we had while developing the project and it would also make it more suitable for requirement gathering and to perform necessary research and development before programming the module. Once the module would be ready it could be tested while we get the requirements for the next module. Following this model of software development the system was divided into modules namely: Login Module Dashboard Module Notification Module Sales & Leads Module Trackers Module New Business Module Tickets Module Renewals Module Feedback Module Users Info Module Partners Module
This Project Report would be describing the development of certain modules as few of the modules were developed by the team colleague. These modules were developed keeping in mind the smooth and user friendly interface and functionalities of the system. To develop such a system a 5 plane User Interface Design was implemented. Surface Plane: On this plane what we see in the uppermost layer of the system built up of images and text on Web Pages. This Plane is the most important in terms of user experience as it is the only bridge between the user and the system. So design of the System is the Surface Plane which directly interacts with the customer. Skeleton Plane: This is the next Plane right below the Surface Plane. The exact placement of the interactive elements such as buttons or hyperlinks or photos is determined here. The skeleton is designed to optimize the arrangement of these elements for maximum effect and efficiency.
13 | P a g e

Structure Plane: The skeleton is a concrete expression of the more abstract structure of the site. The skeleton might define the placement of the interface elements on our page; the structure would define how users got to that page and where they could go when they were finished there. Scope Plane: The structure defines the way in which the various features and functions of the site fit together. Just what those features and functions are constitutes the scope of the site. For example the Ticketing Feature of the BOSS CRM system goes together with the Dashboard module to give a summary of Ticket module. Strategy Plane: The scope is fundamentally determined by the strategy of the site. This strategy incorporates not only what the people running the site want to get out of it but what the users want to get out of the site as well. In our System the strategic objective is quite obvious to have all the details that are required regarding the customer as well as to make the business process simpler and automate the work.
Using these 5 Plane Methodology for Development of efficient User Experience made the development process more simpler and smooth going. It was easy to develop the surface of the system when a skeleton was already designed keepin in mind all the requirements and functionalities that were essential in all the modules across the system. Once the interface was designed the tools like Google Chromes Inspect Element and FireFoxs Firebug Addons for developers were used to debug the interface across the browsers to make the system cross browser compatible. For low compatible browsers like Internet Explorer which did not have much high end support a back drop of the same system was designed so the user interface remains the same for the low end browsers as well. Several Jquery UI were used in the system such as clock and calender for date and time to make the user interaction with the system more realistic. The System is abstract thereby making the user unaware of the functioning of the system behind the surface level. Keeping all this in mind the confidentiality and Access Control for the system were the prime factors to be considered.Thus all the features and functionality were not to be available to all the users of the system i.e. the company employees and service executives and to restrict the access the access roles were alloted to users based on the designation in the company.
14 | P a g e

6.1 Login Module
Figure 7 : The Login Module
The login module of BOSS system was very simple in the interface but from the functionality point of view one of the most important as this module was responsible for the confidentiality and access control all over the system. All users were alloted a username and password which was associated with the employee role and designation in the organization which determined the users access and authority in the system. Based on the role various features and functionalities were alloted. The roles that were initially set up included Sr.Manager, Manager, Employee and Service Executive. If the role of the user was Sr.Manager or Manager the complete access to all the features of the system were given to them. In case of any other role the features and functionalities are restricted to them. Now technically the thing behind login module is that when a user enters a username and password it is encrypted and send to the database for verification .This is done using a encrypted DLL that is already programmed in the prototype and the same is used in this system as well. The encrypted password that is stored in the database is compared with the password and the username in the database. If both the username and password match then the username and the user role is returned back to the system from the database. This user
15 | P a g e

role is used to grant access to the system and based on the role the access to all features is granted to the user.
Figure 8 : The Login Module with Forgot Password feature
Now along with this there is another feature of the system that is very common in the login module i.e. forgot password or password recovery feature. If the user has forgot the password he may enter the registered mail and the password would be sent to the user. The database connectivity done to send the password to the oracle database is through the C# programmed Oracle Dataclient component which is supported in ASP.NET architecture. The Oracle query which is in the form of stored procedure is mentioned in C# code which sends the data from the interface to the backend and fetches back the user role which is stored in session variable along with the user name for further use in the system. Once the user role and user name is fetched and stored in the session variable it is sent to the next module viz. Dashboard module where the username and user role determines which functionalities and features are to be made accessible.
16 | P a g e

6.2 Dashboard Module
The Dashboard Module provides some of the vital stats about the sales of the company through WebSales channel. It provides graphical analysis of sales for the last 7 days. The graphical analysis includes bar graphs for the sales as well as the line graph charts for the last 7 days. The Bar graph analysis shows the everyday sales done and further classifies the individual product sold on that day. The Line Graph shows the 3 numerical stats of the total policies sold that day which includes the modal premium, the AWPI and APE.
Figure 9 : Dashboard Module with hover on Line Graph
Here as we see the Dashboard has all the features and functionalities as the user who accessed the system was of Sr.Manager role. Now beginning from the top right of the system we see is the name of the user who has accessed the system. Then next to it we have is the notifications bar which gives the list of all the notifications. The notifications module would be explained further in this report however just to summarize it notifications include payment made, documents uploaded, Medical / Non-Medical Questionnaire filled up by the customer. Next to it on the extreme left we have the quick action bar which includes the direct link to add a new ticket and a new conversation. Tickets and the New business modules are explained in detail in the further part of this report but just to brief it Tickets are the customer grievances received through mail and conversation is a part of customer 360 which records the
17 | P a g e

conversation made by the Dedicated Support Executive with the customers regarding various issues related to the policy.
Figure 10 : Dashboard Module with hover on Bar Graph and ITD stats below
Along with the two other graphs there is a provision of a pie chart which shows the percent sales of individual sale of products sold till date. In all of these graphs when hovered over any particular bar or a point in the graphs the detailed description of that point is shown. In the pie chart when a user clicks on any region it shows the percentage of that region in a modal window. Below that we have is the ITD stats i.e. stats of sales till date. The Statistics include the number of sales done till today. The APE, AWPI and modal premium of the sales done till the date in lakhs and along with it the NET AWPI in lakhs which means the AWPI after subtracting the refunds or the policy claims made. The navigation bar on the left is the site master i.e. the master template that is attached to every page of the system making it easier to code the page and no need to copy that part in every page of the system. The navigation bar consist of autocomplete search box which is explained in this section a bit later and the direct links to other modules of the system viz. Dashboard, Sales ,Trackers, New Business ,Tickets, Renewals, Feedback ,User Info and Partners modules.
18 | P a g e
Figure 11 : Dashboard Module with Support Summary and To-Do Task feature
Right after the ITD stats we have the Support Summary which gives a description about the tickets that are received through mail and their status are mentioned in the summary whether the ticket is Overdue ,Open ,Pending , Close or resolved. Clicking on any of these would directly take the user to the tickets with that status. Further more detailed explanation of the Tickets module is done in the later part of this report. Towards the bottom of the Dashboard module is a very personalized feature of the system which is available to every user. The To-Do Task feature of the Dashboard module allows the user to enter the daily To-Dos and make a list of the task for the day or even a future task to be done. To-Do Tasks are very simple to create the only thing to be entered by the user is the date and time of the task and the note associated with the task. For any new task the status associated with is by default of pending category. The different statuses of the To-Do include the pending, overdue and done category. The Date and Time are made realistic by using the JQuery UI of date picker and time picker.
19 | P a g e
Figure 12 : Dashboard Module with edit To-Do Task feature
The To-Do Tasks are visible to the user which he has made and is allowed to edit the To-Do as and when required by the user. The To-Do details which already existed are mentioned and can be edited by the user by just entering the new date and time and the task to be done or in case the status of the task is to be changed. The UI of date picker and time picker make it really easy for the user to add and modify the data and make it more realistic as well. The To-Do task can also be deleted by the user if that task is no more required by just click the corresponding tasks delete button. The Technical happening behind the To-Do Task is that whenever the user enters the task along with the Date Time and the Note, the entire data is sent to database through the Oracle Dataclient as mentioned earlier and a new task id is generated for every task and the status for that task is by default assigned to pending. This new Task is then added to the list of Tasks describing the date time and the note from where the user can modify or delete as necessary. The To-Do Tasks would help the Service Executives make a note of any call back to the customers or any reminder the employees would like to keep on the system. This feature in the system would allow the users to keep all their tasks updated and could easily refer them in quick time.
20 | P a g e
Figure 13 : Dashboard Module with restricted access to user
However in the above figure as we see the dashboard module not all the features are available to the user since the user entered is not of the role authorized to access all the features, due to which the statistical analysis and the graphs are not shown to this users. Not only are the ITD stats not accessible to the user but along with that the Partners module and the User Info module is also not accessible for this user in the navigation menu at the left. This is the approach towards access control in the system based on the role of the user. The UI is remains the same for all the roles that are using this system only the certain features and functionality is kept away from unauthorized people so the user experience remains the same for all the organizational hierarchy. Another important feature available here is the autocomplete search bar in the navigation bar on the left at the top most places. This feature is also available to all users as it is one of the most important one of this system. This autocomplete search box is used to search the customers of the WebSales Channel. The possibilities of finding the customer are through 3 ways that are through the unique application Id that is alloted to each customer or either him first name or last name. Any of these possibilities would lead to customer that is to be searched. The only requirement in this searchbox is that at least 4 characters are essential for it to work that in case of the Application Id the first 4 digits of the application ID are essential similar is the case for the first name or last name.
21 | P a g e
Figure 14 : Dashboard Module with the autocomplete Searchbox
The Autocomplete Searchbox works on AJAX technique and so does not require the browser to reload the page which in turn saves a lot of time for the customer and fetches only the relevant data from the database server rather than fetching all the data that is done while reloading an entire page. Using any of the possibilities mentioned earlier the customer can be found using this feature. Once the customer is found the user clicks on it and the unique application ID is displayed on the search box. After this the user has to click on the search icon next to the text field and subsequently the user would be redirected to the Customer360 part of the system which is In the NewBusiness Module. This saves a lot of time for the user to go to the Customer360 and search there rather the user can search from here when needed quickly.
22 | P a g e

6.3 Notifications Module
The Notifications Module is a special feature of the system which gives real time notifications about various events happening in the system or the WebSales platform. The Notification Bar as shown in the all the images is present on all the pages and thats the reason it was built on the site master which is replicated on all the modules of the system. This notification module was very much inspired from the Facebook notifications that we have.
Figure 15 : Notification Module Latest Notificaiton view
As we see in the above figure on the top right we see the notification bar similar to that of Facebook. The Notification bar shows the latest 5 notification and are not removed from the list until it is read by someone. The numbers of unread notifications are mentioned on the notification icon in red. Once clicked on the icon a list of top 5 notifications which are unread are displayed. The category of notifications include the document upload, Medical/Non-medical Questionnaires filled up by the customer and the payment notifications which may be payment successful or payment failure done on the Sales Platform. Whenever a payment is successfully made on the sales platform a notification is displayed here describing the transaction amount, the application ID, the name of the customer and the plan that he chose.
23 | P a g e

Along with these categories include two more which are the city request and the operator request made by the customer prior to buying a policy online in case of any help needed by the customer for the purchase whereas the city request is only applicable for the protection plan offered by the company in which it is necessary to know whether that is available in the nearby region for the customer. Both these notification describe the customer or the lead name ,their city and the contact number.
Figure 16 : Notification Module - All unread view
In the above figure what we see is the extension of the notification bar. Here all the unread notifications are described along with the ones that are read for the present day. The look here is all the same as the notification bar in the site master. As mentioned earlier the different categories of notifications require to be read by someone to be marked as read. The name of the operator who reads the notification is listed on the extreme right of the list. For marking the notification as read the user has to click on the icon next to it. Each category of notification has different icon .Like the payment notifications have a tick mark whereas the document upload has a outward icon and the Questionnaire filled / Additional Info notification has a read icon which on clicking directly redirects the user to the additional info page of the NewBusiness module where the user may download the Questionnaire filled.
24 | P a g e

The technical thing happening behind the notification module is that from the User Interface point of view the notification bar is placed in a Update Panel which refreshed itself using a partial postback. A partial postback is something in which only the elements inside the update panel are updated due to which only the data inside the update panel is sent over to the server and has to undergo a partial page life cycle. This reduces the amount of data to be refreshed and thus reducing the load time. The update panel is triggered using a timer which can be timed as per the requirements. Now beyond the User Interface the technical thing that works is the data retrieval from the database. The database is called whenever the update panel is triggered using the timer set. The operator request or city request or the documents uploaded are entered into the database .This data is then sent over to the system where it is shown in the Notification bar. Once the user marks the notification as read the particular notification is mark as read even in the database and the name of the user is assigned for the corresponding notification.
25 | P a g e

6.4 New Business Module
The New Business Module is all about the main requirements in the business are available. Like the documents uploaded by the customer or the Additional Info Questionnaire filled by the customer which may either be the Medical or Non-Medical ones. There is also a feature called email dashboard in this module which has the functionality to send various mails to the customer regarding various issues related to the policy. The next feature in the module is access controlled one i.e. Admin Override which is available to the Sr.Manager and Manager role users only. The last part of this module is the most important one for a CRM system i.e. the Customer 360.
6.4.1 Download Documents
Figure 17 : NewBusiness Module - Download Documents
In the above figure we see the Download Documents part of the NewBusiness module. All the documents that are uploaded by the customer are stored in the server, what this system does is gets the access to the server where the documents are stored and downloads it for the user. The category of documents which were taken as proof included the Age proof, ID proof, Income proof, Photo Proof, Permanent Address and Corresponding Address. Along with these documents of proof there were few documents which were issued from the companys end viz. the PDF of application form, SI (Standing Instruction) and BI (Business Illustration).
26 | P a g e

Now the process of downloading has two possibilities since there was a change in the business process and the sales platform. Earlier there was possibility for the user to upload a single document as a proof but then there were situation where the customer had to upload multiple documents as proof ,so to overcome this situation a check is made when the document was uploaded ,if it was prior to the change made in the sales platform then the single document was downloaded and the next check would be if the folder of the particular proof contained more than 1 files in it then the whole folder would be downloaded by zipping the server from the server. The same approach was used for all types of proof documents. The next feature of this part is that is the user wishes to download all the documents for verification then all the categories of the proof documents would be zipped and downloaded for the user. The next feature of this part is the status of the documents whether they have been downloaded earlier or not. This feature was done in such way that whenever the user download any category proof documents then it would mark as a tick towards that category for the status that it has been downloaded earlier. The same can be seen in the figure shown above.
6.4.2 Additional Info

Additional info is the part of New Business Module where the Additional information about a customer can be retrieved. The Additional Info is classified into two type i.e. Medical info and Non-Medical Info. These are certain type of Questionnaire that the user is supposed to fill up prior to the policy being issued to him. The Notification Module gives a notification of this part whenever the customer fills up a questionnaire either medical or non-medical. The user when clicks on the notification to mark it as read, it is here where the user is redirected. Additional Info classified as medical include medicinal Questionnaire about various diseases like hypertension, Diabetes, Chest pain, Deformity, ENT etc. There is 12 such medical questionnaires about all the different disease that the customer has to fill up if required. Similarly the non-medical questionnaire include other occupation related questions or NRI questionnaire or foreign travel questionnaire. At present there are only 3 Non-Medical Questionnaire in the system but inclusion of other non-medical questionnaire can lead to more number of questionnaire in the CRM system as well. In both the cases a PDF file is formed from the data stored in the database using XML and RDLC file creation feature in visual studio.
27 | P a g e
Figure 18 : NewBusiness Module - Additional info Medical view
Figure 19 : NewBusiness Module - Additional info Non - Medical view
28 | P a g e
6.4.3 Email Dashboard

The Email Dashboard is part of NewBusiness module of the system where the user can send emails to the customer. The Emails to be sent from the company include the welcome mail, document upload reminder mails, documents received mail, Additional info required mail policy issuance, policy status and policy renewal reminder. The Email Dashboard was also a part of the prototype that was used prior to development of this system but now is equipped with even more useful features. The new Email Dashboard now has a autocomplete customer search box which helps the user to easily find the customer. The user in the prototype has to remember the application id of the customer from the complete record and then again come to email dashboard and then enter the application Id. However that problem has been resolved thanks to the autocomplete search box.
Figure 20 : New Business - email dashboard view
29 | P a g e

As we see in the above figure the user can easily use the auto complete search box which helps to find the customer using the unique application Id or the first name or the last name just like the one in the navigation bar. There are two more columns in the right of the email dashboard which displays the status and action to be performed. The status describes whether the mails have been sent previously or not. The action column is the command button to
send the particular mail with the required input done by the user.
Figure 21 : New Business - Email Dashboard view
When the user clicks on the customer to whom the mail is to be sent then the email dashboard describes the name of the customer his contact and email id. Along with this the email dashboard also displays the policy status of the customer as to he is regular paying or other various status of the policy. As we see in the above figure the customer has already been sent the reminder on documents to be uploaded mail and also the documents to be received. The User can send the mail once again if required from the action button corresponding to the type of mail to be sent. The Additional Info mails to be sent whether medical or non-medical both have several types of disease and questionnaire pending mails so in order to send such a mail the user has to select which of those option he wishes to send in the next box to the right of both categories.
30 | P a g e

The other mails include the policy renewal, policy status and policy issuance mail , refund mails and feedback mails. All of these mails also have the same functionality as the others. The user just has to enter certain input if required in some categories of mail and click on action button to send it. The Technical aspect that goes through during sending mail is that whenever user clicks on the action button to send the mail the input that user might have entered is stored and the replaced in an pre designed HTML mail that is sent to the customer .The input is replaced wherever required in the mail and then the mail is sent using SMTP protocol. For this sending mail feature the IIS (internet information manager) needs to be have configured with the SMTP protocol. The pre-defined HTML mail that is sent to the customer is the developed the same way any HTML webpage is developed only certain modifications are done so that the user input can be easily replaced with the variables defined in the design of the mail. All these mails are registered in the database as to who sent the mail to whom at what time and what category of the mail was sent. The Operator Name who is currently logged into the system is fetched using the session variable that was stored in the login module and the type of mail is also registered depending upon the button of corresponding category of mail sent.
Figure 22 : Prototype - Email Dashboard view
31 | P a g e

6.4.4 Admin Override
Admin Override is an access controlled feature of the system available to limited users only as it deals with permission to change the information about the customers. Admin Override consist of two functionalities viz. Lock-Unlock and Admin Override.
Figure 23 : New Business - Admin Override
In the above figure we see the lock unlock functionality of the admin override module. The lock-unlock feature is basically to give a certain application the status of complete or incomplete. Complete Application is considered to be given the status of lock status whose payment is done successfully whereas the status of unlock determines that the application is not completed yet and some of the information is not filled or the payment is not made yet. However in due circumstances there may be condition where the application may be completed and has not reflected in the sales platform or due to any technical glitches then the user with the access to this module can change the status of the application by entering the unique application ID and then clicking on the buttons on the extreme right side whether to lock or unlock the application. Lock-Unlock feature was available in the prototype and has been adopted in this system without much of technical modifications only the UI has been designed as per requirements.
32 | P a g e

The other feature of admin override is itself. This feature is also quite important and deals with the customer information. Using this feature the user can change any information of the customer like incase the customer has misspelled his name and wants to change it or any other information. The tab next to lock unlock is that of admin override and due to company privacy the snapshot of this feature is not provided in this report, however the UI design of this feature is very similar to that of lock unlock with a search bar to search the unique application id. When the user clicks onto this application ID he is then redirected to the sales platform where the customer had initially entered his information.
6.4.5 Customer 360 Degree

The Customer 360 degree is one of the most important features of this system. Being a CRM system the Customer Records are vital information. This feature provides all the customer information from personal details to product details and the conversations done with customer regarding any matters by the service executive. Customer 360 degree has several components like summary, Conversation History, Case History, Personal Details, Product Details and PS history.
Figure 24 : New Business - Cutomer360 Summary view
33 | P a g e

The summary component of Customer 360 provides a brief about the customer like the name, email-id, product bought by the customer, Premium details, Policy Term etc. Along with this the summary also gives a list of the latest 5 conversations made by the service executive with the customer. The list gives description about the date on which the conversation was made the channel on which the conversation was made like email or call or system generated one. The direction of the conversation whether is it inbound or outbound and the category of the conversation or the reason of the conversation along with the name of the operator and additional notes mentioned in the conversation.
Figure 25 : New Business - Customer360 - Contact History view
The Contact history component of Customer360 displays the records of the conversations made with the customer same as that in the summary component the only difference in both is that here all the records are displayed whereas in the summary only latest 5 conversations are recorded. The Category of the conversations includes payment call, welcome call, document upload reminder, medicals, query, complaint or refund. There is also an option to enter a new conversation on the top right of the view which opens a new entry in a modal window as well as the quick action bar next to notifications bar. The new entry also has input validation so that there is less error in the entry made by the user. This validation is done using JQuery and a Bvalidator Plugin for validation. The contact history includes the conversation made by the service executive along with the Tickets generated in the Tickets System. The Tickets System would be explained further in the report.
34 | P a g e
Figure 26 : New Business - Customer360 - Contact history view
Figure 27 : New Business - Customer360 - Case History
35 | P a g e

The Case History component of Customer 360 degree is very much similar to that of Contact History the only difference is the certain type of records that is display. The Case History includes all the Contact History records in additional to the system history events like the mails sent from the system such as welcome mail sent by the system on successful payment.
Figure 28 : New Business - Customer360 - Personal Details view
The Personal Details component of Customer 360 degree gives the personal details of the particular customer. Along with this the other details that are provided also include the Address Details, Educational Details, Employment Details, Nominee Details and Documentations provided by the customer as proof of identity and residence. Due to companys privacy all the details cannot be shown in the report due to which only general information are shown here. The Address Details includes the residence address details and correspondence details. The educational details include the educational qualifications of the customer. The Employment Details include the employers name or the business name, the duration of the employment, nature of duty and the annual income earned. The Nominee Details include the nominee name if any, the relation with the nominee and the personal details as well.
36 | P a g e
Figure 29 : New Business - Customer360 - Product Details view
The Product Details component of Customer 360 is where the product specifications of a customer are described in detail. The details include the plan name, cover assured, premium frequency, policy term, maturity age and riders if any. The premium details include the policy sum assured and amount of premium with service tax and without service tax. All the data of the customer and the product details are stored in the database directly from the sales platform. This system just brings all that data from the database and displays in this module so that the user can easily get all the information quickly. The last component in the Customer 360 degree is the Policy Servicing History. All policy related requests like name change or address change or even nominee change request is summed up as policy servicing. The details of the policy service list is type of the service ,the operator who took the request, the date on which the request was received and the date on which it was completed as well as the status of the request are noted and some additional notes that are to be mentioned with the particular service are also mentioned in the list for future references. To add a new policy service entry there is command button on the top right view which opens up a modal window where the new entry can be made. This modal windows has the data entered validated to reduce the error that can be made by the operator.
37 | P a g e
Figure 30 : New Business - Customer 360 - Policy Service History view
Figure 31 : New Business - Customer360 - Policy Service Modal window
38 | P a g e

6.5 Ticket Module
The Ticket module is one of the special features of the BOSS CRM system. The ticketing system has been developed with purpose to integrate the mail system into this system. Ticket module would synchronize the mails received on the email address of the WebSales channel from the customer. This feature would enable the users to directly check the customers mails from the system itself while they would be working on the system and thus the users wont need the email client systems like outlook. A Ticket is basically an issue that has been raised by the customer. The issue can be of any category. When the email is received on the companys exchange server all the mails are synchronized and can be seen directly into BOSS system. An email received from the customer from an email ID is directly given a Unique Ticket ID and this ticket ID can be referred by the user as well as the customer for future interactions regarding the issue. A Ticket can be generated by two ways one being manually entered by the user or the service executive as there is also possibility that the customer might want to register an issue through a phone call. So the user can manually generate a New Ticket.
Figure 32 : Ticket Module - Manually Add a new Ticket
39 | P a g e

The previous figure shows how a new ticket can be created by clicking on the quick links button next to notifications bar. This enables the user to quickly create a new ticket even while interacting with the customer on a call. The data that the user has to enter while manually creating a new ticket is the unique application ID if possible since the customer may not be able to give the Application ID at that instance. Along with that the customer has to give the full name and the email id for further interactions. Each Ticket has a category such as service request, policy service, operator service, Complaint etc. Tickets are assigned a status as to whether they are open or resolved or pending or waiting for some requirements. Each Ticket is also assigned a priority to get the ticket resolved. The Priorities include Urgent, High, Medium and Low. Along with these inputs the user can also enter some extra notes to be associated with the ticket so that in future reference they can be used while interacting with the customer or while resolving the particular ticket. The Tickets that can be created the other way is through the emails received on the email id of the WebSales channel. All the email content and the attachments are directly displayed onto the BOSS system. However if all this was done on the BOSS system then it would have been overloaded and might crash. So to overcome this task and to implement load sharing another small application was developed which would be in sync with the mail server of the company and fetch all the mails and attachments for the CRM. The application developed was the Windows Service which runs all throughout the day on the server where the BOSS CRM system was installed. This Windows Service named Boss Ticket Service was also developed on the Visual Studio Software which has a development module for creating in windows service. A Setup and deployment project was developed in Visual Studio software using which the windows service could be easily installed on the server where the system was installed. The Boss Ticket Service used a free mail server component OpenPop mail client library which was used to access the mail server and fetch the mails from the server. The technical workflow used in the service was to fetch the count of mails on the mail server and then compare it with todays date. If the date matches todays date then it would move ahead to fetch the mail details. Using this would filter the mails to todays mails only. Further on then each mail have a Unique message ID which is checked if it exists in the database. This would prevent the mails which are already synched with the service to be again retrieved reducing the load on the system. The new mails would then be retrieved from the server and their message and attachments if any would be stored on the server.
40 | P a g e

This windows Service was specially developed for load sharing purpose and this would also help in synchronizing the mail server with the CRM system. The Windows service also generates a log on the server in order to keep a check on the mails being synchronized and also in case of any technical glitches the date and time of the error would be noted in the log along with the error message. The Windows Service is run at a time interval of 5 minute and also care is taken for thread concurrency.
Figure 33 : Ticket Module - List View
The above diagram shows the Tickets List view where all the types of tickets are mentioned, whether manually created or generated through emails. As we see the Tickets are displayed in the list. The details about the ticket are mentioned along with it. The Ticket Id, senders name, senders email id, the ticket category and the app id if mentioned. Then there are two options to view or reply to the ticket. The button with the eye icon is used to view the ticket message or rather the email body whereas the pencil icon is used to send a reply to the corresponding ticket. The priorities of the mails are mentioned alongside. Here in the above picture since all the tickets are generated through the windows service the default priority is LOW, to the extreme right is the assign to column where the name of the person is mentioned who would resolve the particular ticket and below it is the ticket created date and modify date with the status.
41 | P a g e

There is also option to delete a particular ticket however this option is also available to the limited users only. Another option is to close the ticket; this is to assign the status of ticket to close. Then other option available to the users is to pick up the ticket to be resolved. The user who is available to resolve any issues can pick up the ticket by reading the ticket details. The last option available is to assign a particular ticket to the service ticket; this function is also available to limited users only. The authorized users can assign a particular ticket to a service executive as the situation may persist.
Figure 34 : Tickets Module - Tickets List View
In the above figure we see there are two tickets in the list which are not highlighted and are different from the ones that were in the figure 33. The difference in the tickets is that the tickets with the envelope icon are generated from the windows service whereas the ones with the operator icon are generated manually by the operators. The last two tickets have the priority set to Urgent which means they have to be resolved quickly and both the tickets have the Assign to field with the name of the operator assigned since it was manually generated. The list of tickets is arranged as per the ticket number. The tickets can also be directly viewed from the database where we had the support summary with the status of the tickets. When the users directly click on the type of tickets from the dashboard they directly get a list of filtered tickets with status like open, overdue, pending, resolved and closed. This quick filter on the dashboard also helps the user to quickly get to the ticket details. The Tickets can be filtered through various other factors like status, Ticket Id, Application Id or email Id.
42 | P a g e
Figure 35 : Tickets Module - Ticket Mail View
When the user clicks on the view ticket mail the user is redirected to where the ticket mail body is displayed. In the figure 35 we see that the name of the sender and the email address is also mentioned in the view. The views of the mails are in thread form where only the latest one is expanded whereas all other are kept collapsed. The mail body is of the form HTML or plain Text. The attachments are also shown in the mail like the embedded images and other attachments are also available to the user for downloading them. If the ticket is not picked up by someone yet then the user may view this mail body and then pick up the ticket by using the edit ticket feature to the extreme right of figure 35. In edit Ticket feature the user can assign the priority and status of the ticket as by default it is assigned as low and open respectively. The assign to feature is also the same that was in the list view, here also is access controlled. This ticket can be assigned to someone by the authorized users and the unique application id can be assigned to the ticket for keeping the track of customer conversations in customer360 module. It is also very important to revert back to the customer regarding the issue. So in order to make this possible through the system, there has been a feature to send a reply to the particular ticket from the ticket mail view. To make this possible a WYSIWYG editor has been implemented to feed the mail body. The user must enter the CC in case any or else the reply is sent to the mail address on which the ticket is issued. The mail is again sent through the SMTP protocol as it was in the Email dashboard component of NewBusiness module.
43 | P a g e
Figure 36 : Ticket module - merge ticket feature
Another important feature of the ticketing module is that often it happens that even though a customer is given a unique Ticket Id for use in further reference of the issue, the customer me revert back using different email id or any other situation which may force the Windows service application to generate a new ticket id for the same mail even though the same issue is being under action in the previously issued ticket id. So in order to overcome such duplication of tickets a feature to merge the new ticket is developed. What this feature does is that the new ticket if is same as the one that already exist then the user can view the mail body and merge the new ticket with the existing old ticket to avoid duplication. The figure 36 shows that this ticket can be merged with an existing ticket. The only criterion for two tickets to be merged is that the two tickets must belong to the same email address or the application id. This feature is really important as there can be numerous scenarios where the issue is already being resolved but then to the customer may have sent another mail which might become a new ticket as the ticket generating mechanism cannot anticipate the possible feed received from the customer and may issue a new ticket. The Entire Ticketing system has been studied over from various markets sold CRM and tried to modify as per the needs of this company. However there are further many scopes to enhance the ticketing system.
44 | P a g e

6.6 Feedback Module
Feedback module in this system is just used to represent the ratings that the customers having given to the WebSales Platform experience and the transactions ease. When the customer makes a successful payment on the WebSales platform he is then redirected to the feedback questionnaire where certain questions regarding the platform User Interface, Product Guidelines, Customer Support, and Product Suggestions etc. are asked. The customer is however allowed only once to enter the feedback.
Figure 37 : Feedback Module
The figure 37 describes the feedback module interface in the BOSS CRM system. This module fetches the data from the database in term of ratings where the data from the WebSales Platform is sent. The Questions range from rating the overall experience, looks of the platform, the information available was relevant and as per requirements, the customer service etc.
45 | P a g e

6.7 User Info Module
User Info Module is the module where the information about the user using this system is mentioned. The Users full name, Operator Code, email id and the user role a re mentioned in this list. The access control for the system can be viewed from here but as this module is to be secure the module has been given access to limited users only.
Figure 38 : User Info Module
This module being very important is accessible to limited users and the features available in this module are also very limited and general. The user can search through the list of all the users with their access roles in the system. There is also the possibility to lock this user, here the context of locking the user is to assign the user to an automated service executive assignment mechanism which is a part of lead management module in this system. Thus the locked users are assigned certain amount of leads and have to follow up with the leads. There is also functionality to add a new user in to the system as well as delete an existing user.
46 | P a g e
Figure 39 : User Info Module - Add Customer view
Figure 40 : User Info Module - Delete Customer View
47 | P a g e

6.8 Partners Module
Partners Module is the last module that is to be discussed in this report. The partners module is also a very confidential data for the company so is given the access control restricted to limited users only. This module was specifically added to the system so as to keep the track of the business partners like marketing partners for the WebSales Channel. The Partner Details that are provided include the partner/broker ID, whether the partner is a broker or not, the plans that the partners are associated with and the partner source code.
Figure 41 : Partners Module
The Partners module in the list view also provides the functionality to edit the partner details like the product the partner is associated with is to be changed from the previous on, or the partner is no longer a broker etc. Figure 42 illustrates how the edit partner functionality is visible in a modal window. There is also the functionality to add a new partner to the system by just moving on to the next tab. The details to be entered include the partner name, whether he is a broker or not, partner id, and the products with which it will be associated and a source code for the partner.
48 | P a g e
Figure 42 : Partners Module - Edit Partner View
Figure 43 : Partner's Module - Add Partner View
49 | P a g e

Along with Partners details there is also the feature to maintain a track of the products that the channel is currently selling online. The Product information just includes the product name and its ID. The new products can also be entered by just moving onto the next tab to enter the name of the new product and its product code. Figure 44 illustrates the view of the products lists and Figure 45 illustrates the view of how to add new products.
Figure 44 : Partner's Module - Products View
These Partner and Product Details available here are like the master records of the data, any changes that are done here can be reflected throughout the entire system especially in the lead managements module and tracker management module. The Products however have not been given the functionality to be deleted or modified as there might be situation where accidently the product might be deleted so the deletion or the modification of the data must be done directly from the database.
50 | P a g e
Figure 45 : Partner's Module - Add New Product View
51 | P a g e
TIP Final Report 2013 7.0 Database Development
CRM System Frontend Business Access Layer (BAL) Data Access Layer (DAL) Oracle Database
The Database that was used in the system was the Oracle Database and the software tool used to code programs in the database was the Oracle SQL developer. The Database Connection to the system was done through the Oracle DataAccess Client which is the client library with C# support. The entire connection to the database was developed in layered architecture.
Figure 46 : Oracle SQL developer
52 | P a g e

The architecture used to establish the connection with the database is as the above flow chart. The several layers of the architecture include the CRM system Frontend, Business Access Layer (BAL), Data Access Layer (DAL) and last layer is the database. The Business Access layer is the link between the Data Access layers where the functions to the connection to the database is established. The data from the front-end is send over to the Business Access Layer (BAL) through the functions programmed in C# and then the data is passed over to the Data Access Layer (DAL) through the functions where the database connection is made using the Data Access Client of Oracle. The data stored in tables are extracted using various database elements like packages, stored procedures, triggers, sequence, cursor etc. The Tables are the simple structure tables where the data is stored in. To extract the data we have programmed various packages and procedures. The stored procedures are the functions in database which are called when needed. The functions are series of code called from the DAL to extract the necessary information. The multiple procedures grouped together form a Package. To avoid much of the mess in the database and for easy referencing the packages were developed for every module. Other important database elements used are the sequences and triggers. Sequences are used to auto increment the numbers in the data table like the Ticket ID or the notification ID. These sequences are coded to start from a number and the last number is also mentioned in it and how much number to be incremented every time a new record is entered in the table a new sequence number is generated. To implement the new sequence number in the data table a triggering event is to be implemented every time the new record is entered into the table. The trigger can be activated in two conditions, before the record is inserted or after it is inserted. There is also an option to activate the trigger if there is any update before or after an update is made. Triggers are like dependencies on the table for every record inserted or updated. Several triggers and sequences are used to alter the data entered or updated in the tables along with the functions programmed in the stored procedures or the packages. When an collection of data is to be retrieved it is done with the cursor feature of oracle database which can get back a data table of records which is then stored in the dataset in the Data Access layer and the sent back to the Front end via the Business Access layer in form of Datasets carrying the data. The data is then altered as per requirements in C# code.
53 | P a g e
TIP Final Report 2013 8.0 Conclusion

The internship period at Edelweiss Tokio Life insurance Company was the best learning phase wherein I got to learn many new things. It being my first time in developing an application in the ASP.NET framework was quite new but due to the help and support of my colleagues the successful development of the system was possible. The exposure to new coding language like C# under asp.net 4.0 framework was something interesting that I could learn. Moreover getting to know the business process of an Insurance Domain was also a great learning experience. The TIP tenure also helped me boost my experience as a developer as it was the first time having got to work on a professional level. Developing this system has not only helped me learn many things but also has simplified the business process of the company in maintaining a good relation with the customer. Although there are several improvements that can be done into the system to make it more efficient and with more exciting and useful features, however due to the time constraints were not possible to be implemented. The main aim of this TIP to develop an efficient CRM which would be highly beneficial to the company has been successfully achieved.
54 | P a g e
TIP Final Report 2013 9. References

Tutorials references: www.asp.net www.codeproject.com www.w3schools.com http://dotnetzip.codeplex.com/SourceControl/latest#Readme.txt http://hpop.sourceforge.net/documentation/index.html
Forums referred: http://forums.asp.net/ http://stackoverflow.com/
Theory References: https://en.wikipedia.org/wiki/ASP.NET The Elements of User Experience by Jesse James Garrett
55 | P a g e

TIP Final Report Mba - Tech (IT) 136

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

TIP Final Report Mba - Tech (IT) 136

Diunggah oleh

Hak Cipta:

Format Tersedia

TIP Final Report 2013

Developing a Customer Relationship Management System (CRM)

Based on the Technical Internship undertaken in

Edelweiss Tokio Life Insurance Company Ltd.

TIP Final Report 2013

TIP Final Report 2013

TIP Completion Certificate

Training Period: From

External Examiner Date: Place: Seal of the University

TIP Final Report 2013 Acknowledgements

TIP Final Report 2013

6.4.1 6.4.2 6.4.3 6.4.4 6.4.5 6.5 6.6

Ticket Module ............................................................................................................................. 39 Feedback Module........................................................................................................................ 45 V|Page

TIP Final Report 2013

TIP Final Report 2013

TIP Final Report 2013

TIP Final Report 2013 1. Abstract

TIP Final Report 2013 2. About Edelweiss Tokio Life Insurance

TIP Final Report 2013 3. Introduction

TIP Final Report 2013

Figure 1 : Rapid Application Development Model

TIP Final Report 2013 4. Industrial Analysis

Figure 2 : Overall Process of Policy Issuance

TIP Final Report 2013

Figure 3 : The WebSales Platform

TIP Final Report 2013

Figure 4 : Policy Issuance process at the Company's end

TIP Final Report 2013

Figure 5 : The Prototype used prior to the new system

Landing Page (website) WebSales Platform Customer Relationship Management System.

TIP Final Report 2013 5. Pre-Development Analysis

5.1 Features and Functionality Analysis

TIP Final Report 2013

5.2 Technical Analysis

TIP Final Report 2013

5.3 System Requirements

5.4 Business Analysis

TIP Final Report 2013

TIP Final Report 2013 6. Developing BOSS CRM System

TIP Final Report 2013

TIP Final Report 2013

Figure 7 : The Login Module

TIP Final Report 2013

Figure 8 : The Login Module with Forgot Password feature

TIP Final Report 2013

Figure 9 : Dashboard Module with hover on Line Graph

TIP Final Report 2013

TIP Final Report 2013

TIP Final Report 2013

Figure 12 : Dashboard Module with edit To-Do Task feature

TIP Final Report 2013

Figure 13 : Dashboard Module with restricted access to user

TIP Final Report 2013

Figure 14 : Dashboard Module with the autocomplete Searchbox

TIP Final Report 2013

Figure 15 : Notification Module Latest Notificaiton view

TIP Final Report 2013

Figure 16 : Notification Module - All unread view

TIP Final Report 2013

TIP Final Report 2013

6.4.1 Download Documents

Figure 17 : NewBusiness Module - Download Documents

TIP Final Report 2013