Service – User Guide
DeepDesk is composed of several modules.
The module to manage the Service Desk (the service offered by the organization) is called Service.
The Service module collects all data of the requests of the users, sorts those records by priority, due date and organizes them by category and working teams assigned to solve them.
The user portal displays the request types that can be sent by the end users to the support service. In the footer area there are also some grids that show the open and closed requests.
To insert a new request, fill the form with data and submit the request.
We will describe the fields that composes the Service form.
Every request of the Service module is called “Operation”; following the ITIL methodology an operation is represented by the actions taken by an organization to provide an efficient and effective service (ITIL is a framework used by IT organizations that can be easily extended to other kind of services).
Main Fields of the Service module
We will list the fields of the Service module below.
Some fields can be hidden, because the system administrator has configured them not to be edited in the user form:
|Title||The title of the operation. A brief description.|
|Category||The category of the operation. It is an important field to manage the assignment to working teams and to catalog correctly the scope of the activity requested.|
|Description||Extended description of the request.|
|Status||It is the status of the operation. It is an important value to manage the lifecycle of the request.|
|Priority||Priority of the operation: the importance from the working team perspective.|
|Urgency||Urgency of the operation: the importance from the requester user perspective.|
|Submit User||The user that has submitted the request (can be different from the Requester User). Si pensi all’esempio di un segretario che immette la richiesta per conto della propria responsabile. In questo caso il Submit User è il segretario, mentre il Requester User è la responsabile.|
|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. DeepDesk 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. DeepDesk 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.|