Services Request Configuration

Home > Service Manager > Services > Request Configuration

Introduction The Service Request Configuration lets you define a number of elements for the different request types that are used for each Service.

Related Articles

Configuration

• Business Processes

It is possible to associate a workflow to each request type. Clicking on the slect box will present you with the available Business Processes that have been configured via Hornbill Administration. Remember, for a Business Process Workflow to be initiated when a request is logged, it must be marked as “Active”. Inactive workflows can be identified and avoided here by looking for the word “inactive” in brackets next to the workflow name.

Associating a Business Process workflow is optional at this stage, and can be done at a later date. This setting can be ignored completely if you configure a Request Catalog for the Service.

Once you are happy with the details you have entered, click “Create” to complete the configuration of your first Service.

You can learn more about designing and building business processes to underpin the Services you provide here: Building Business Processes

• Email Template

It is possible to define for each request type and for each Service which email template will be used when analysts are manually sending emails from the request forms.

This allows Service owners to have control over the signature and other request variables which are defined in email templates, and they would like included in any manual email communication for requests linked to their Service.

• By default the email template specified in the app.email.template.request.sendMessage app setting in Hornbill Administration will be used. It is possible to change which template to use for each request type per service by choosing another available email template from the drop down list.

• Email templates are defined via Hornbill Administration, under Home > System > Email > Templates

• If no default email template exists, or another email template is not chosen a blank plain email template will be used.

• The Email template specified is only used when emails are manually sent from within a request. All automated emails fired by the business process engine, can be configured when designing your business processes for each request type again via the admin console.

• Form Designer

It is possible for you to define custom fields to use against each request type per service. Using the form designer you can edit which default fields will be displayed in the Details section of each request form, as well as add new fields, set field validation, configure mandatory options and using drag and drop to re-order how the required fields will be displayed.

• Portal Head's Up Display (HUD)

When a business process is defined and supporting either the Incident or Service Request request types, it is possible to define what level of visibility you wish to give to your customers of the processes progress through a graphical head's up

display. It is possible to give no visibility, top level or a granular view per request type and per service via either the Service and Customer Portals.

The default option is Off.

• Off - No graphical representation of the supporting business process will be displayed on the request forms on either the Service or Customer Portal
• Stages Only - Top level visibility of each of the defined stages will be displayed at the top of the request forms on the Service and Customer Portals. This will allow the subscribed customers to see the stages which have been completed and those which are still outstanding.
• Stages and Checkpoints - This will show both the process stages and the defined checkpoints for each stage. This will give the subscribed customers the same level of visibility of the requests progress as the analysts see, and will allow them to see which stages and checkpoints have been completed and what is still outstanding to complete.

• Request Actions

Define which actions are available to analysts working on requests raised against the Service. It is possible to configure which Action Icons will appear on the Action Bar on the different request forms for each Service. It is possible to configure different Actions per request type per Service.

An example being you may choose not to enable the 'Escalation' Action against Service Requests if you are not using Priorities for requests of this type for a particular Service. However you have this available for Incidents and Problems where you have chosen to use priorities for those request types.

• The Default position is all Actions Icons are available for all request types
• Enable or Disable an Action by clicking on the Action Icon for each Request type
• Hover over each Action Icon to see a tooltip with the Actions purpose.

• Request Categories

Define which logging and resolution categories are available per request type per service. It is possible to configure which level of the category tree will be the starting level (exposed) when choosing a category on requests against each Service.

• The default position is to use the root of the category tree for all request types against all Services.
• Configure a different starting level per request type for each service by clicking on either the Category Level or Resolution Category Level options and choosing a different starting level.
• Once configured only child levels of the category tree will be presented when adding a category to a request via Progressive Capture or the Request Details forms.

Catalog Items

The Catalog Items are used to create a catalog of defined requests which can be used on the Portals or by Support Staff to raise requests to fulfill a specific requirement for that particular Service. Catalog Items can be added to both Incidents and Service Requests. For each Catalog item you can define the following:

Read more...

Customer Feedback

The Customer Feedback options provides a feature to gather feedback from your customers regarding the level of service they have received for a particular request. This feedback will enable you to identify where excellent service is already being provided, but also highlight any areas where the service to your customers could be improved.

Read more...

Sub-Statuses

The Request Sub-statuses lets you define a number of descriptive states of a request that are related to the request being either Active or On-hold. Using a Sub-status can help control the situations under which a request is put On-hold or made Active again. An example of an On-hold Sub-status might be With Customer which when selected will place the request's status to On-hold and stop any allocated Service Level Target timers.