The module “Service” contains all the information necessary pto manage the service requests inserted into the system.
There are 2 key concepts to understand the module:
- Service Types: the request types managed by our service. It is important to define the request types to better organize our daily work.
- Service Operations: the database records that represent the support requests, the failures, the problems or the change requests inserted by operators or by users (or customers) into the system.
Deepser has a default set of standard Service Types, taken from the ITIL methodology:
- Incident: the incident management process is to restore a normal service operation as quickly as possible and to minimize the impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained.
- Request: is the process to manage the service requests, that are minor changes or information requests.
- Problem: the term “problem” refers to the unknown cause of one or more incidents, the control of errors (a problem is an error if its cause is known and there is no workaround), to prevent errors and create workarounds.
- Change: the addition, modification or removal of any authorized, planned, or supported service or service component that could have an effect on the services.
The default standard types don’t bind the configuration of Deepser: we can insert new Service Types to adapt the software to our organization and the services we provide.
To learn more about Service Types and their configuration, please read: Service Configuration.
As said before, the Service Operations are the real records that represent the service requests.
Every Service Operation has one Service Type well defined, so every Operation in Deepser is related to one (and only one) Service Type.
Every Service Operation contains data: the title of the request, the requester user, the due date, priority, urgency, category, etc.
We will see in the next sections how to configure and edit the Service Types and the Service Operations.
Insert a new Service Type
To insert a new Service Type, go to menu System > Service Configuration > Types.
We will see the grid with all the Service Types already in the system:
To add a new Service Type click the button Add Type upper on the right.
We will see the form to create a new type.
We list all the fields and their meaning:
|Name||The name of the Service Type, it will be displayed in the “Service” menu and in the select-boxes of the Service Type.|
|Status||If disabled, the Service Type will not be displayed in the system. If a Service Type previously active is disabled, all the Operations of that type will be archived by the system.|
|Position||The position of the Service Type in the menu Service and in the select-boxes. Using this numeric field we can sort the Service Types.|
|Description||Description of the Service Type. Typically it is used to describe internally the meaning of the Service Type.|
|Icon||Icon that we will see in the grids and in the menus.|
|Groups||User groups that can access the Service Operations with that Service Type.|
Once inserted a new Service Type, the corresponding item will be displayed on the Navigation Menu, under the item Service.
By clicking on the item we will access the grid with all Service Operations of that Type, initially empty.
Insert a Service Operation
Once defined the Service Types, we can start to insert the records of our Service Desk: in Deepser we call them Service Operations (shoten to Operations).
Note: the word Service Operation is common in the ITIL methodology. For ITIL, infact, the Service Operation is the process to manage the service and to guarantee that services are provided in an efficient and effective way. The lifecyle of the Service Operation process includes the fulfillment of users’ requests, the failure resolution, the problem resolution and the completion of the daily tasks.
Operations record can be accessed using the menu Service.
As said before, Deepser creates dynamically the items corresponding to the Service Types, so to see a grid with all the Operations of a certain Service Type click the icon of that Service Type.
An exception is the item Service > All that lists all the Operations in the system, without filtering the Type.
This item is useful when a user (operator) has to solve or monitor different types of requests and needs to understand the records with higher priority or with a forthcoming due date, or to assign all the activities not managed by the working teams, etc.
We can create Service Operations in different ways:
- Manually from the Back-end: we will explore this method in this chapter. The operator that manages the requests can insert all the data from the back-end.
- Manually from the User Portal: customers / end users of our service will access the User Portal and insert their requests.
- By the Email Integration: it is possible to supply a mailbox to open requests. Deepser parses the emails of that mailbox and creates a Service Operation record.
- By the API Integration: Deepser can be integrated using its native REST API. Other systems (monitoring, other service desk tools, CMDB) can create records.
Insert Service Operations from the back-end portal
An agent that receives a call, a member of the facility staff, a call center operator or an HR employee, can insert manually the requests submitted by their users, using the back-end portal.
To insert a new Operation, click the menu Service > All and then upper on the right click the button Add Operation.
In the popup that appears, select the Service Type of the Operation.
We will access the form to insert a new Operation.
Tip: to expand fullscreen the main screen with the form of the Operation, click the blue button upper on the left near the global search textbox.
The structure of the default screen of every Operation is organized like that:
- Buttons to edit the form and to select the template: we will explain that in the advanced Form Templates guide.
- Tabs: using Tabs we can change the main screen of the form. We can see display fields on different tabs.
- Main screen of the Operation: the main screen of the Operation varies depending on the selected Tab and it contains the Fieldsets.
- Fieldsets: a set of fields, included in a frame. All the fields of the Operations are inside Fieldsets.
- Action Buttons: to save, reset the data, etc. The difference between the button Save and the button Apply is that the button Save updates the record and redirects to the Operation grid, while with the Apply button we stay inside the Operation form.
Service Operation Tabs
The default form of the Service Operations is divided into tabs, each containing specific data to help the data inspection and insertion by a back-end operator:
Default tabs has this meaning:
- Main Data: main data of the record like title, description, status, priority, urgency, category.
- Details: details of the record like requester user, assigned group, creation date, etc.
- Closing Info: data important when closing the record like solution or due date.
- Activities: activities and file attachments.
It is possibile to modify entirely the Service Operation form, with the configuration of form templates.
Meaning of the fields in the Service Operation form
We list all the fields of the Operations and their meaning
|Title||The title of the Operation. Usually a brief description.|
|Category||The category of the Operation. It is a very important value to manage the assignment of the requests to working teams and to catalog precisely the scope of the activity.|
|Description||Large description of the request.|
|Status||The status of the Operation. It is an important value to manage the lifecycle of the request.|
|Priority||Priority of the Operation from the operator perspective.|
|Urgency||Urgency of the Operation from the requester user perspective.|
|Submit User||The user that has created the record (he can be different from the Requester User that is the user actually requesting an activity). Think about a secretary that is submitting a request on behalf of his boss. The Submit User is the secretary, while the Requester User is the chief officer.|
|Requester User||User that is actually requesting a service.|
|Requester Company||Company of the requester user.|
|Assigned Group||Working team that is working to solve the request.|
|Assigned To||User that has taken in charge the request. He is typically an Agent or a Key User. Deepser lets you assign also to end users if we decide that they can be part of the resolution process.|
|Created At||Creation date of the record.|
|Updated At||Date of the last update on the system.|
|Closed At||Closing date of the record. If a record changes status from closed to re-opened, the this date is reset to null.|
|Archived||Every Operation can be archived, for example we can archive all closed Operations of the past 5 years to hide them in the standard grids (but we could see them in the Archived grid).|
|Archived At||Archived date of a request.|
|Updated By||The user that has lat updated the request.|
|Deleted||Every Operation can be deleted setting the status to “Deleted” (or other status belonging to the Deleted class). All deleted requests will not be physically deleted from the database, but they will be only marked as deleted (soft delete, so they will be visibile in the Deleted grid). To delete physically use the button “Delete”. The record will not be recoverable anymore.|
|Deleted At||Deleted date of the request.|
|Mailbox||The mailbox that will be used to send notifications regarding the Operation. If empty the default outgoing mailbox will be used (if set).|
|Source||The source of the Operation. It can be the back-end portal, the user portale, the email integration or the API integration.|
|Due Date||The agreed date for the resolution.|
|Version||The version of the request. Deepser stores in its DataBase every version of the Operations. We can always know the changes, the user that made a change and the date.|
|Solution||The solution of a request, that can be emailed to the requester user or exposed on the portal.|
|Attachments||File attachments of the request.|
|Activities||The activities (comments or worklogs) planned or reported. Comments let you communicate with the requester user and can be visibile on the user portal. Worklogs keep track of the time spent to sove a request or to document internal activities.|
Status of the Operation
A very important field of the Service Operations is the status.
The status represents where the processing of the request has arrived.
Statuses are editable accessing the System > Tools > Lists.
We have a system list with all Operations statuses: Service Operation Status. The modification of that list must be done by an expert user or with the help of a Deepser consultant.
Every status can be associated to a class that represents a set of values.
Default classes for status are:
|Open||The statuses belonging to this class mean that the request has not yet been solved.|
|Closed||The statuses belonging to this class mean that the request has been solved and no more actions are needed on it.|
|Deleted||The statuses belonging to this class mean that the request has been soft-deleted, for example if we want to keep track of the insertion errors by the users.|
Default values of the status field have this meaning:
|New||Open||The request has been inserted into the system and no action has been made on it.|
|Work in Progress||Open||A team is currently working on the request.|
|Closed||Closed||The request is solved and closed.|
|Reopened||Open||The request has been solved, but it has been reopened (eg: a non-working solution or a complaint).|
|Stand by||Open||The working team is waiting information or further action to go on processing the request.|
|Deleted||Deleted||The request has been soft deleted.|
Category of the Operations
We have seen at the beginning of this chapter that operations have the first “macro category”, represented by their Service Type.
For example, an incident is used to report a failure, while a request is used to ask information or to request a new service by the user.
Inside every Service Type we usually have the need to identify the scope of every Operation to measure, for example, how many incidents are linked to a certain kind of failure or to assign the request to the most skilled team on that topic.
For that, Deepser uses the Category: an entity associated to every Operation to identify its scope.
We can insert categories using the menu System > Categories
Categories screen is divided into areas:
- Category tree: we can find every category in the system organized in a tree-level structure.
- Header: it displays the name of the category, the numeric ID and the action buttons to Save a Category, Delete a Category or to reset not saved changes (Reset button).
- Tabs: we can change the main screen using the tabs, to see different data.
- Main Screen: it contains the fields of the category.
Insert a category
Categories are organized using levels.
Deepser, contrary to other softwares, doesn’t limit the number of levels.
We advise not to use more than 3 levels in order to avoid an unuseful proliferation of categories, difficult to mantain and with a technical meaning not easily understandable.
At level 0 there is a category (not visibile) used by the system to include all other categories.
Users can insert categories starting from the base level (level 1, called root).
All categories not on the first level are children of the root categories.
To add a new “root” category click the button Add Root Category:
We will see a form on the right with the title “New Root Category”:
Fill in the fields and save with the button “Save Category”.
The fields of this form have the following meaning:
|Name||The name of the category, seen by the users.|
|Description||The description of the category, used internally to describe the meaning.|
|Image||Image used to identify the category. The image appears inside the select-box of the category, for example in the Service Operations module.|
|Status||Status of the category. If disabled, it will be no more visibile on the forms of the system. All records with a previously visibile category will keep that category, until changed manually (or with a massive query).|
Once saved the category, we can see 2 additional tabs:
- Model Visibility: the rules to view the category inside the modules of Deepser. We can set rules to determine for every entity of Deepser the categories that are visibile or not. For example, in the Service module we can decide to show some categories for the Service Type Incident and other for the Request. With Model Visibility we can set all those rules.
- Group Visibility: we can set the rules also to show/hide the categories based on the group membership of a user. That way we can give the right categories to the right working team. For example, we want that the category “Facility” and all its children categories will be visibile only to the group: “Facility Support”, while the category “IT Hardware” will be visibile only to the “IT Support” team. We can do that inside the Group Visibility tab.
To manage the category tree simply drag&drop the icon “folder” of each category.
To move a category in another level or to sort it before another use the mouse and drag&drop it.
That way it is possible to move a child category inside a different root category or edit the order of the root categories.
Thank to this very flexible structure of Deepser all those edits has no huge impact on the system, but must be done after a careful analysis of the service organization.
Inside the modules of Deepser categories are displayed in a field that reflects the tree structure.
To make easy the category valorization, they are displayed in a specific field type called “Category”: a set of select-boxes mutually dependent.
When a request is not inserted in the system it has no category, thus only a select-box with no value is displayed:
When we choose the first level category, if it has children, then the select-box is doubled and in the new list we will find the children categories related to the first we selected.
This behaviour is done recursively for every category level.