Getting Started with the Service Company
This tutorial describes how to design and build a customer relationship management application that tracks customer service requests using Formspider framework. It covers various starting level Formspider development topics including implementation examples of some fundamental business functionality as well as some more complex and advanced examples, design tips and best practices. Therefore even you are a newly started or an experienced Formspider developer, you will be able to explore new concepts and ideas through this tutorial.
You can also install the application in your local Formspider installation following the installation guide below:
SRDEMO Installation Guide
Before starting development using Formspider, you will analyze the structure, business problems and business goals of the Service Company. This analysis will influence the business solution as well as your Formspider application design.
This chapter contains the following topics:
- Service Company Overview
- Business Problems
- Business Goals
- Business Solution
- Impacts of Business Goals on Formspider Development
- Screens & Application Flow
- Data Model
Service Company Overview
Service Company is a large appliance-servicing company that provides service support for household appliances (dishwashers, washing machines, microwaves, and so on). The company has two main establishments in United States and Italy. In addition to this, the company has future plans to achieve an international growth by expanding its service area and locating new establishments around the world.
Service Company supports a wide variety of appliances and tries to solve most customers issues by providing answers to questions via service requests. In early years the company provided only on-site service upon customer requests received via e-mail or telephone.
In recent years Service Company has found that customers can eventually resolve most issues when they have the correct information related to their problems. Also, this approach has proven to save time and money for both the company and its customers.
A service request generally has the following flow:
- A customer issues a request through e-mail or telephone.
- The company assigns the request to a service technician.
- The service technician answers the request or asks the customer for more information.
- The customer checks the request and either closes it or provides further information.
Service Company has the following business problems:
- Currently the service request process is initiated by telephone or e-mail and requires the services of a clerical staff to log and follow up on a service request. In the first place, the need of such a clerical staff is increasing cost per request for the company. In addition to this, this business model is not scalable and sustainable for the company since as the company grew and the volume of customers increased more clerical staff needs to be hired.
- The need of clerical staff constitutes another obstacle for internalization plans of the company. Even the volume of the service requests remains same, the company has to hire new clerical staff in order to keep providing multilingual support to their customers.
- As volume of the service request has increased, assignments to service technicians are sometimes delayed until clerks can perform data entry of the service requests. It’s difficult for managers to keep track of the work that technicians do to ensure efficient performance.
- Having two diverse channels of communication with the customers (telephone and e-mail) is another problem for the company. It’s hard to maintain and increase investment costs significantly. Furthermore, it’s very expensive to provide a 7/24 support via telephone.
These factors have resulted in declining customer satisfaction and increasing costs per request for the company.
Service Company wants to implement a self-service application so that customers can log and track their own requests and so that managers can better monitor the work of technicians.
Service Company has the following business goals:
- A 7/24 online self-service application with English and Italian multilingual support. This application should be suitable and ready to support other languages in near future without any extra effort.
- Elimination of the need of clerks during the service request process and reduce cost per request.
- Merging two diverse communication channels with the customers to a single and reliable one.
- A customer interface that customers can use to add, update and check the status of their service requests.
- A business interface with which the company can create, update, and manage customer service requests which includes adding service information and assigning requests to the appropriate service technician.
- Various reporting tools to ensure timely resolution of service requests.
- A role based access to specific user interfaces. There are three business roles: customers, technicians and managers. The accesses to specific user interfaces have to be managed and restricted according to these business roles.
Service Company decides to use Formspider framework to create a customer relationship management application. The technical aspects of the application include the following:
- The user interfaces are Web-based to enable deployment of the application both externally to customers and internally to employees.
- The applications UI are designed completely with Formspider IDE.
- The application uses Apache Tomcat as the container to Formspider middle-tier.
- The application uses Oracle Database XE as RDBMS. Only PL/SQL is used as the programming language.
You will start by analyzing the impacts of the business goals on Formspider Development.
Impacts of Business Goals on Formspider Development
Before starting the development phase with Formspider you have to analyze the impacts of the business goals on Formspider development. This analysis assures accurate design and implementation of the user interface and data model.
There are two major impacts of the business goals on Formspider Development:
- For providing role based access to specific user interfaces in Formspider, you have to define additional entities in your business data model holding restricted resources information, different business roles and permission information for each of these roles to the restricted resources. These resources will be called as “security resources” in the rest of this tutorial.
While you are showing or hiding user interfaces or managing application flow (showing a button or a menu option, changing screen and so on) you have to take these security resources on consideration, therefore providing role based access to specific user interfaces has a direct impact on your code and data model.
- For providing multilingual support you should define and use Formspider multilingual keys in user interface labels (button labels, screen titles…) instead of hard coded static values. For this purpose you will create key-value pairs for every multilingual message that will be used in the application.
While designing your user interfaces (panels, alerts…) you will use these keys as label values, therefore providing multilingual support has a direct impact on your user interface design.
Note: In the following chapters you will discover how to implement and use multilingual keys in Formspider in great details.
After completing business goals impact analysis on Formspider development you will determine a list of business functions and screens to be used in the application. The first list shows the functions that are needed. The second is a list of required screens.
The following functionality is required in the application:
- Customer log-in validation
- Service request creation
- Service request maintenance
- Service history creation
- Service history maintenance (with the ability to hide internal notes from customers)
- Service request triage
- Technician skills reporting
- Technician skills maintenance
- Technician performance reporting (by listing service requests that are being worked)
The application consists of the following screens:
- Login screen: Each user is a customer, technician or manager.
- Welcome screen: This is the first screen displayed when the user successfully logged-on. This screen informs user about the functionality and capabilities of the application.
- Service Request Insert screen: Both customers, technicians and managers can use this screen to create new service requests (SRs).
- Service Request List screen (customer-facing): This is the screen that customers use to view existing SRs. This screen shows all of the SRs that the customer has created and the status of each. Customers can click an existing SR and be directed to an edit screen where they can add information to the request (Service Request screen).
- Service Request Edit screen (customer-facing): This is the screen that customers use to create or update SRs. The history may include sensitive information that the company does not want customers to see. These entries can be flagged as “internal only” and will be excluded from customers’ view.
- Triage screen (company-facing): This screen is used by managers and technicians to display all SRs. The screen allows the company staff to search and find specific SRs which can be filtered according multiple criteria including product name, status or problem description of the SRs. Also, the company staff can assign or reassign SRs from this screen.
- Service Request List screen (company-facing): This screen displays all of the SRs assigned to the logged-on technician or manager and the status of each request. The company staff can click an existing SR and be directed to a screen to add information to the request (Service Request Edit screen).
- Service Request Edit screen (technician-facing): This screen is where the technician updates the SR with resolution information. The screen will show the original request along with the full SR history (master-detail).
- Management Reporting screen (manager-facing): This screen is used by managers to display expertise areas of service technicians and list detailed information about SRs that the technicians are being worked.
- Technician Skills screen (manager-facing): This screen is where the managers can update, create or delete skills information belonging to technicians.
- Service Request Edit screen (manager-facing): This screen is where the manage updates the SR with resolution information. The screen will show the original request along with the full SR history (master-detail). Additionally, this screen allows the managers to delete service history records and even the service request itself.
The following graphic provides an overview of the screen flow for the application:
The application flow is as follows:
- Users invoke the application and are presented with the Login screen, where they enter log-in information. Users can be customers or Service Company employees (managers and technicians). If the log-in information is correct, they navigate to Welcome screen from where they will be able to navigate different screens depending on whether they are a customer, a technician or a manager.
- If the user who logs in is a customer, the Welcome screen displays options to view previously logged SRs(SR List) or create a new one(SR Insert).
- If the user who logs in is a technician, the Welcome screen displays options to view assigned SRs(SR List), create a new one(SR Insert) or query for a specific SR or type of SR(Triage).
- If the user who logs in is a manager, in addition to being able to view, create and query SRs, the manager can navigate to screens for displaying management reports(Management Reporting) and editing technician skills(Technician Skills).
- If users choose to create an SR, they navigate to a screen where they enter SR details.
- If users choose to view SRs, they navigate to a screen that lists the applicable SRs. This list contains links that enable them to update their SRs.
- If users choose to update, they navigate to the edit screen depending on their roles(SR Edit Customer, SR Edit Technician, SR Edit Manager) where they can update SR details. Managers and technicians will be able to assign a SR and associate a technician with it.
- If managers or technicians choose to query, they navigate to a screen where they can enter query details and display a restricted record or set of records.
- If managers choose to display management reports, they navigate to a screen(Management Reporting) where they can list expertise areas of service technicians and detailed information about SRs that the technicians are being worked. From this screen, the managers can navigate to an another screen(Technician Skills) where they can update, create or delete skills information belonging to service technicians.
The initial data model has been designed to provide the needs of the business model. The data model consists of nine tables, diagrammed as follows:
The five tables USERS, SERVICE_REQUESTS, SERVICES_HISTORIES, PRODUCTS and EXPERTISE_AREAS represent creating and assigning an SR to a qualified technician.
The remaining four tables SEC_ROLES, SEC_RESOURCES, SEC_ROLERESOURCES and SEC_PROPERTIES represent security resources entities mentioned in the first part of Impacts of Business Goals on Formspider Development section. These tables assure the role based access mechanism to specific business interfaces.
USERS: This table stores all the users who interact with the system, including customers, technicians and managers. Each user has a business role identified by an ID. The e-mail address, first and last name, street address, city, state, postal code, country and system password of each user are stored. An ID uniquely identifies a user.
SERVICE_REQUESTS: This table represents both internal and external requests for activity on a specific product. In all cases, the requests are for a solution to a problem with a product. When an SR is created, the name of the individual who opened it, the product it is for and the date of the request are all recorded, along with a short description of the problem. When the SR is assigned to a technician, the name of the technician and date of assignment are also recorded. An artificial ID uniquely identifies each SR.
SERVICES_HISTORIES: There may be many events recorded for each SR. The date the request was created, the name of the individual who created it, and specific notes about the event are all recorded. Any internal communications related to an SR are also tracked. The SR ID and the service history sequence number uniquely identify each service history record.
PRODUCTS: This table stores all of the products handled by the company. For each product, the name and description are recorded. If an image of the product is available, that too is stored. An artificial ID uniquely identifies each product.
EXPERTISE_AREAS: To better assign technicians to SRs, each technician’s specific areas of expertise are defined.
SEC_ROLES: This table stores the name of the available business roles (customer, technician and manager) in the application. An artificial ID uniquely identifies each role.
SEC_RESOURCES: This table stores artificial names of the restricted resources. For example since deleting a service request is a restricted functionality this resource will be recorded with the name “serviceRequest.delete”. Therefore before showing any screen or component which will cause deletion of a service request the resource named “serviecRequest.delete” will be checked. An artificial ID uniquely identifies each resources.
SEC_ROLERESOURCES: This table represent an association class allowing the pairing of one role with one resource. Since there is a many-to-many relationship between roles and resources this table is necessary. This table will be used while checking if a specific resource is available for a specific role.
SEC_PROPERTIES: This table stores names of the security related properties parameters (for example: maximum failed login attempt allowed) and their values.
This chapter introduced you to Service Company, its business problems and its plan to implement a Web-based customer relationship management application that meets following major requirements:
- Customers can log and update their own service requests.
- Technicians and managers can keep track of and update service requests that are assigned to them. They can also query and assign the service requests.
- Managers can display reports listing technician skills and service requests that technicians are being worked. They can also edit technicians’ skill information.
In this chapter you carried out all of prerequisite design steps that you need to complete before starting to build the application. You performed the following tasks:
- Analyzed business goals and their impacts to Formspider development.
- Determined business functions.
- Determined the screens of the application and its flow.
- Designed the appropriate data model for the system.