Layton ServiceDesk - System Overview
System Concepts & Terminology
It is advisable to read and understand the system concepts and terminology before proceeding with the installation and configuration in order to obtain a good understanding of the system terms and functionality. The general system terms can all be renamed, but are referred to in all documentation in their original terminology.
Requests
The core of the system is based around creating, progressing, tracking and reporting Requests (or Incidents using ITIL Terminology). A Request is an End User or Customer submitted call, request or incident which can relate to any area that the End User or Customer requires support or assistance.
A Request can therefore be an incident, a request for information or training, a request for new hardware, software or other services, etc. The types of Requests are categorized or predefined by the Administrator. See the Request Types section.
Requests can be created using any or a combination of the following methods;
- Manually created by the support Analyst
- Entered directly by the End User/Customer
- Created automatically by email
- Notified by email but created by the support Analyst
Problems
Problem Management is a key component of ITIL (IT Infrastructure Library). The purpose of Problem Management is to identify and resolve the root causes of problems in the IT infrastructure and therefore eliminate future incidents relating to this problem.
The Problem & Change Management functions in Layton ServiceDesk are enabled by default, however if your ServiceDesk is not IT based or does not require this function it can be disabled by turning off Enable Problem & Change in Application Settings.
Problems may be created using one of the following methods:
- Manually created by the support Analyst
- A support Analyst can generate a Problem from a Request
- A support Analyst can convert an incoming email into a Problem
Changes
Change Management is another key ITIL component. The main objective of Change Management is to ensure standardized procedures for the handling of changes to the IT infrastructure. This will help to minimize the impact on services and prevent or reduce the impact of related incidents.
Requests for Change may result from Problems that have been identified in the IT infrastructure which requires a Change to resolve the underling root cause or they may arise from initiatives seeking to improve services and efficiencies.
The Problem & Change Management functions in Layton ServiceDesk are enabled by default, however if your service desk is not IT based or does not require this function it can be disabled by turning off Enable Problem & Change in Application Settings.
Changes may be created by using one of the following methods:
- Manually created by the support Analyst
- A support Analyst can generate a Change from a Request
- A support Analyst can generate a Change from a Problem
- A Support Analyst can convert an incoming email into a Change
System Access and Menu Structure
Layton ServiceDesk supports two types of user access, Analyst and End User (see below for definitions). In addition, Analysts have another level of security or system access known as their “Security Group”. There are two “Security Group” options, Administrator and Standard, and depending which level is used determines the Menu structure displayed and functionality available to the Analyst. The Standard level will not provide access to the Administration Menu options. Analysts in the Administrator group can access the Administration menu by clicking the administration icon in the main menu.
The main system processing is conducted on the Main Menu Home Tab, where new Requests, Problems and Changes are created, appropriate actions defined, solutions provided and list views and searches performed. The type of List Views; Requests, Problems, Changes, Actions and Select End User (display and select), can be defined globally for all Analysts using Administration > Global List View > Default List Views . Individual Analysts can also create their own custom list views in Analyst Settings.
The system may be configured to automatically display the required list view or screen required on entry to the system, e.g. Open Requests assigned for the Analyst logged on. The Analyst’s Home Page settings can be accessed in Analyst Settings. Global list views can also be copied down to all Analysts. If needed, you can enforce the list view so individual analysts cannot change the view you create. For more information, see Global List View/Analyst List Views.
End Users
The End User is the person or user of equipment or services who will log or submit a Request to the ServiceDesk. End Users may be given access to log and progress their Requests or alternatively Requests can be logged on their behalf. End Users may also log Requests via email.
If End Users are given access to the ServiceDesk application, then the following will apply:
The End User is given access to ServiceDesk to log and progress their own Requests through screens or pages designed by the ServiceDesk Administrators. End Users have simple Menu options which provide them with the ability to log and progress their own Requests.
End Users may also be given access to the “Self Service” feature where they can search the Solutions Base in order to solve their own problems before submitting a Request. Providing your End Users with access to the “Self Service” feature can help to reduce the number of Requests logged in the system which will reduce the workload of the ServiceDesk staff.
Once an End User logs a Request, it can be recorded in the system as an ”Unassigned Request”, i.e. no Analyst has been assigned to the Request, or it can be automatically assigned to an Analyst or Analyst Group depending on skills and/or work load. If auto assignment is switched off in Auto Assignment Options, then the request will remain unassigned and it will appear in the Unassigned Request drop-down filter in the Main Menu. The number of Unassigned Requests in the system will also be displayed in the Requests Statistics section of the Dashboard.
Any Analyst can then view the Unassigned Requests and take assignment of a Request by selecting the Take Assignment button 
the Assignee column. Otherwise, with the auto assignment option on, the Request will appear in the relevant Analyst list view or Analyst Group Queue.
End User Requests logged by email will follow the same procedure as above in that they can be created as unassigned or automatically assigned depending on work load and skills using key words in the email. Alternatively, Email Requests can be viewed first (in the Incoming Email queue) and created manually by the support Analyst. The Incoming Email queue is accessed by clicking on the envelope icon in the main menu. An Analyst must be given access to the Email Pending queue by enabling Analyst Incoming Mail Access in Administration > Company Structure > Manage Analyst > Settings > Site Access.
Analysts may also be notified by email when new End User Requests have been logged. For information on configuring the connection to a mail server, please see Email Server Settings. Once the Email Server Settings have been configured, the individual email notifications to be sent out of the system may be enabled and customized in Email Settings & Bodies.
End Users can register new user accounts when they access ServiceDesk for the first time. This option is enabled by default and may be disabled using Administration > General Settings > Security > Global End User Security > Allow End User Self Registration. Alternatively, End Users may be initially set up one at time in Manage End User, imported from Active Directory, imported from a CSV file, or added on the fly as Requests are logged..
Analysts
The Analyst is the ServiceDesk technician or engineer who will be processing and responding to Requests as well as logging and resolving Problems and Changes. The Analyst may either have Standard or Administrator system access, defined as a Security Group within Manage Analyst. The Standard Group allows only access to the Main Menu whereas the Administrator Group provides access to the Administration Menu to make changes to the system configuration. Only Administrative users have the ability to change the system configuration and design forms.
All system configurations, settings, screen and reports design are performed through the Administration Menu, however the Main Menu does provide the ability to define Analyst-specific settings and personal list views. A typical ServiceDesk configuration may consist of the first-line ServiceDesk analysts, all of whom may or may not have Administration access, and the support analysts, who would probably not have Administration access.
Analyst can take assignment of a Request by selecting the Take Assignment button the Assignee column in Request List View. Otherwise, with the auto assignment option on, the Request will appear in the relevant Analyst list view or Analyst Group Queue.
Analyst Groups
The system provides the ability to record and assign Requests to Analyst Groups as well as individual Analysts. Therefore, the first level or ServiceDesk Team could be defined as a Group such as “ServiceDesk Group” and additional or second level support areas could have a number of Groups defined, e.g. Hardware Support, Software Support or Networking Team. Analysts may belong to more than one Group and Skills can be allocated to the Analyst Groups so that requests can be auto-assigned based on the Request Type of the request being logged.
Although called Analyst Group, a Group could be defined as an external supplier or Third Party Maintenance Company and calls assigned to them accordingly.
See the Manage Analyst Group section for more information on defining Analyst Groups.
Request Ownership
Request ownership and assignment is very flexible but it is important to understand and define the working method required. A Request is owned by an Analyst, which can be initially defaulted to the logged on ServiceDesk Analyst, and although subsequently the Request can be assigned to another Analyst and/or Group, the ownership can stay with the original ServiceDesk Analyst. This way, the Analyst is in control of the Requests he has received or processed, and he can be the one point of contact for the End User. The Request owners can also be the only person with authority to close Requests, provided the option is switched on using Administration > General Settings > Security > Global Analyst Security > Close By Owner Only.
Alternatively, the ownership of a Request may be transferred to another Analyst, who may or may not be in the ServiceDesk Team, and who may or may not have the Request assigned to them.
Request Assignment
Request Assignment is where a Request is assigned to an Analyst or Analyst Group to resolve or respond. A Request may be assigned to any individual Analyst, whether a member of a Group or not, or assigned to a Group with or without also assigning to a specific Analyst.
If the Request is assigned to a Group without also assigning to a specific Analyst, then the Request will appear in the Analyst Group Queue waiting for an Analyst in the Group to take assignment by clicking the Take Assignment button under the Assignee column in the Request List view.
Requests may be automatically assigned to the Analyst or Group suggested by the system, based on either Skills and/or Load Balancing. The system will auto-assign to either Analysts or Analyst Groups, but not to both at the same time. In addition, Requests may be automatically assigned to particular Analysts depending on individual Skills, which are based on Request Types. These can be Site or Department managers or specified Analysts who are responsible for certain issues which will override any general skills assignment.
Additional Auto Assignment options may be configured using the Business Rules feature which can override other auto assignment options. For example, you may want to create a Business Rule so that if your CFO logs a request, it is automatically assigned to the ServiceDesk manager to be dealt with the highest priority.
Requests submitted by End Users can be automatically assigned as detailed previously in End Users. See Auto Assignment Options for further details on the auto assignment settings.
Comments
Comments are updates or notes that can be appended to a Request, Problem or Change as it progresses through the system. Comments may be added to a Request by both the Analyst and the End User. Analysts may post Comments with a Public or Private status to either allow (Public) or disallow (Private) End Users from seeing the Comment. The Default Comment Status is set in Administration > General Settings > Security > Global Analyst Security.
When an Analyst adds a public Comment to a request, Layton ServiceDesk can send an email notification to the End User including the details of the Comment. Conversely, if the End User adds a Comment, Layton ServiceDesk will send an email to the Analyst that is assigned to the Request.
The Analysts also have an option to add a Comment and select additional Analysts, additional End Users, and external recipients who will be sent an email notification with the details of the Comment. These options are configured in Administration > Libraries > Email Settings & Bodies.
If an End User replies to a Comment from an Analyst via email, Layton ServiceDesk can automatically convert this email into a Comment on the related request. Layton ServiceDesk will then email the Analyst with the details of the End User's Comment and send an acknowledgment to the End User.
Tasks or Actions
Tasks or Actions are activities that are used in order to progress or complete a Request, Problem or Change. Alternatively, Tasks may also be free-standing without any association. Tasks may be assigned to an Analyst and scheduled for completion by a certain date.
Tasks can also be automatically generated as part of a workflow process related to specific Request Types and Change Request Types. This feature is called the Task Template feature, for more details on this feature please see Request Types and Change Request Types.
There is also a Recurring Task facility which will automatically create Tasks on a regular schedule. This is a great feature for routine maintenance tasks. The Recurring Tasks also allow for a task work flow if required. For more information please see Task Types.
Priority and Service Level Agreements
Priorities may be set for Requests and Problems and the priority level will be used to determine the order in which they are resolved, based on their importance or impact on the Company. Priorities belong to a Service Level Agreement (SLA), and although SLA’s may not be required, if Priorities are used then a standard or implied Service Level will exist. Any number of SLA’s may be defined with different Priorities to suit various needs.
Priorities may also be assigned to specific Request Types and they can also be applied to specific Sites. For example, a different SLA could be used for a Request placed on a third party, i.e. PC supplier. A Priority will have a time to resolution and up to three levels of escalation or times when the Request or Problem will escalate. On any escalation level an email may be sent and/or the Request can be reassigned. For more information on defining Priorities and SLA’s see Priority.
Request and Problem Escalation Process
The escalation process is set against the Priority within an SLA and is defined in Administration > Libraries > Priority. A resolve time, or expected time (in hours) that the Request or Problem should be completed by, is defined together with up to three levels of escalation. The three levels define the time (in hours) after the time that the Request or Problem was logged. The escalation process will be initiated when the resolve time or any escalation level is exceeded.
At the point of escalation, an automatic email may be configured to be sent to a specified email address(s) and/or the Request or Problem may be automatically re-assigned to another Analyst. Also, the Request or Problem itself as displayed in the list views may be configured to change the row color. The color settings are defined in Request Settings.
Before setting any Priorities and escalation details, the working hours of the ServiceDesk should be defined in Default Working Hours and Default Closed Periods. Note: When configuring the working hours for Layton ServiceDesk, you may want to consider how the system will run. It is important to know how the working hours will impact the Priority/SLA (escalation process). You can typically ask yourself the following questions to determine how the working hours will affect the Priority/SLA. Will your ServiceDesk run 24 hours a day or only from standard office hours (e.g., 8 AM‐5 PM)? If standard office hours are to be used, then the Priority/SLA’s can be set to count total working hours, as opposed to a 24 hour process. For example, if you run standard office hours (based on 8 AM‐5 PM), and you want a specific Priority to expire within 3 days, then you would only count the total working hours for 3 days, which is 27 hours (would be 72 hours if the Layton ServiceDesk is configured to run 24 hours a day).
Working hours can also be defined on a Company, Site or Department basis in Manage Company, Manage Site, or Manage Department.
Change Advisory Board (CAB)
Change advisory boards (CAB) assist in the assessment, prioritization and approval of Requests for Change (RFC). The CAB group is generally made up of Analysts that are chosen to ensure that the change request is assessed from both technical and business points of view. The type of Change and services or assets affected will dictate the required CAB members. CAB groups should offer the different perspectives necessary to ensure proper decision making. A CAB is an integral part of a defined Change Management process designed to balance the need for change with the need to minimize inherent risks. The Change Management and CAB features can also be used for systems that are not just IT focused as the Change Process can be applied to any system.
The Layton ServiceDesk Change Approval process can involve one or more CAB groups as well as individual Approvers. The approval process can also involve a workflow process which requires the approval of one Analyst before approval is requested by the next Analyst in the workflow. For more information on Change Approval, please see the Change Approval Process.
Request Types
Request Types or Problem types are the method of categorizing Requests and therefore providing statistics and analysis of issues or requirements raised. They are also used as the basis for the Skills profile of Analysts and Analyst Groups (for auto assignment, or suggestion of assignment). In addition, Request Types can define Site or Department managers or specified Analysts who can be responsible for certain issues which will override any general skills assignment rules. Request Types are also used to link directly to the Solutions Base, so for particular Requests or Problems, a Solution can be automatically suggested. Request Types can also be linked to Request Classes, which are used to define multiple Request Forms, so depending on the Request Class or Request Form, only certain Request Types will be displayed. This is achieved when defining the Request Classes. Request Types are user-defined and can either appear as a tree structure with no limit to the number of levels, or as interdependent drop-down lists. Also, when a Request is logged, any Request Type level may be selected or used to categorize the Request, e.g. a Request Type could be specified as PC Hardware Fault, or a specific Request Type within PC Hardware Fault, such as CD Drive Failure. Request Types are defined in Request Types and should be set up before system implementation, although they may be added by Administrators at any time.
The administration of the Request Types tree structure features a simple drag and drop function which allows for simple maintenance and re-arrangement of the Request Type structure. For more information on creating and managing Request Types, please see Request Types.
Note: Once a Request Type has been used in a request, you cannot remove that Request Type until you have purged all requests (opened or closed) that have used that Request Type.
Solutions
A Solutions Base (or Knowledge Base) is provided for the customer to create solutions for particular Requests, so when the same issue arises, a solution can be quickly located. Solutions are associated with the Request Type, so when a Request is logged, the Request Type is automatically used to search the Solutions Base and identify a predefined solution for the Request. Additionally, all Solutions may be viewed or any text string can be used as the search criteria. Solutions may be quickly created as Requests are logged.
End Users may also be given access to the Solutions Base through the Self Service feature. Providing your End Users with the ability to search for Solutions to their problems is a great way to help reduce the number of calls that are logged in the system. Also, when Solutions are created, there is an option which determines whether the End Users will have access to this Solution article via the Self Service feature. This option is called “Self Service” with a Yes/No selection. If the option is set to No, then only Analysts will have access to this Solution article. This allows the Analysts to add technical or other articles to the Solutions base that the End Users will not have access to.
Company
Layton ServiceDesk has the ability to support End Users or Clients from multiple companies. This feature was designed primarily for Managed Service Providers or other ServiceDesk situations where support is being provided to external or third party customers. The Company feature provides you with the ability to produce meaningful reports on a per-company basis.
By default, the Company feature is disabled. It can be enabled by turning on Company Level in Administration > System Settings > Application Settings.
If the Company feature is enabled, you can use the LDAP (Active Directory) End User Import feature to create multiple Active Directory connections and map the connection to a specific Company which will assign the End Users to this Company.
Site
Layton ServiceDesk supports multiple sites. The site is a place where your Layton ServiceDesk services end users. This is generally the case for multiple geographical locations. Multi-site support allows you to create sites at which your Analysts operate. By turning on the Constrain to Site option in the Auto Assignment Options, any auto-assignment or auto-suggestion will take into account the sites that analysts are at. In addition, you may set an End User's Usual Site so that this data is automatically known when a request is logged for an End User.
If you have enabled the Company level as mentioned in the Company section above, then Sites may be assigned to a particular Company.
Asset
The Assets Tab connects to the AuditWizard database to provide a complete inventory of the PC’s and other IT assets on the network. The Assets Tab in Layton ServiceDesk provides a mirror image of the Network View tab in Layton Technology’s AuditWizard Application. The Assets Tab is enabled by default, however, if this feature is not required, particularly for ServiceDesks that are not providing IT based support services, then this can be disabled in Administration > System Settings > AuditWizard > Asset Tab Enabled.
Assets are displayed in a tree structure and can be grouped according to their location through the AuditWizard application interface. Expanding an Asset will allow you to view the asset’s specifications including the OS, network information, hardware specifications and installed software. On the asset’s summary page, you may also view the Requests, Problems and Changes that have been logged against this Asset.
When a Request, Problem or Change is logged, the Asset Name of the equipment or source of the Request may be specified in the Asset field. Once an asset has been associated with an End User, Layton ServiceDesk will remember this association in the future and automatically link this asset to any Requests logged by this End User. Alternatively, the field may be left blank and the End User or Analyst can manually select which asset is the source of request. This setting is configured in Administration > System Settings > AuditWizard > Get Last Asset.
Once an Asset has been linked to a Request, Problem, or Change, the Analyst can quickly view the inventory details of the asset by clicking the “Quick Info on Asset” button next to the asset field. This will launch a pop-up window to display the inventory details.
An Asset Name is not mandatory and may be left blank when creating a request, e.g. User Training would not require an Asset Name.
Whiteboard
The Whiteboard Ticker allows you to publish messages on the system that will scroll across the top of the screen in the banner. This message may be scheduled for a certain date and time with an optional termination date. The message may be displayed for all users including End Users (Public) or just Analysts (Private). Analysts who have been given permission to compose Whiteboard messages can do so from their Main Menu > Home Menu.
The Whiteboard is a very effective way to communicate important information about the current status of services and outages and also to provide details of upcoming scheduled maintenance and other activities. Effective communication can help to reduce unnecessary Requests being logged in the system.
Survey
Surveys may be generated by the system for the End User to complete when their request is closed. There is a list of user-defined questions and responses provided using a pre-determined value rate, e.g. 100, so the user responds with their opinion mark out of 100. The survey can be issued at any frequency, e.g. every closed request or every 10th or whatever is preferred. An email notification and a Whiteboard notice reminder may be sent to End Users for any incomplete surveys. The survey settings may be modified in Surveys and the survey form and questions may be customized in Administration > Form Design > Survey.
