DRYiCE Gold BluePrint on Cherwell R6

Scroll

RELEASE DETAILS

Product Name DRYiCE Gold BluePrint (GBP)
Version Number GBP R6 on Cherwell platform
Release Month June , 2021
Release Summary
Overview

In Release R6 of DRYiCE GBP on the Cherwell platform, we have introduced Advanced Survey functionality with configurable surveys on closure of service and incident requests based on organization goals.

Apart from this, release R6 also comprises of enhancements to improve customer experience and overall product performance across various modules.

Advanced Survey

Introduced dynamic survey capability enabling admin users to configure end user surveys based on organizational goals.

  • Configured following surveys on the self-service portal for seeking end user’s feedback basis their experience

    • ‘Post Order Survey’: Survey triggered on successful submission of a service request.
    • ‘Service Fulfilment Survey’: Survey triggered on successful closure of the service request.
    • ‘Incident Closure Survey’: Survey triggered on successful closure of an incident request.
       

    If end users rate the experience as dissatisfied, a mandatory field will be displayed to capture the reason for poor experience.
    The feedback provided by the end users will help to improve service delivery.

     

  • Configured ‘General feedback’ icon on the self-service portal homepage to capture overall service portal experience of end users.

    If end users rate the experience as dissatisfied, a mandatory field will be displayed to capture the reason for rating the experience as poor.

    Customer satisfaction analysts can analyze the responses, identify gaps and suggest improvements in the self-service portal.

  • A new ‘Survey’ related tab has been introduced on the incident and service request details form on the fulfiller portal showing end user’s response to the survey triggered after the fulfilment of an incident or service request ticket.

    This will enable the fulfillers and process owners to view the feedback given by end users from the respective forms itself.

  • When the status of a service request changes to ‘Closed’ a ‘Provide feedback on request fulfilment’ link will become visible on the service request form to enable users to initiate and submit the ‘Request fulfilment survey’ from the form itself.

    This will allow the end users to provide feedback on the ticket and check its status from the same place.

  • When the status of an incident request changes to ‘Closed’ a ‘Provide feedback on incident fulfilment’ link will become visible on the incident request form for users to initiate and submit the ‘Incident closure survey’ from the form itself.

    This will allow the end users to check its status and provide feedback on the ticket subsequently.

  • Now, upon submitting a service request, end users will be redirected to a ‘Post order survey’ form to capture their experience of raising the service request.

    This will help to capture the end user’s feedback on the request submission process that may be used to enhance the existing request submission flow in the future.

  • Now, after raising a service request or closure of an incident or service request, an email notification will be triggered to end users containing a link to the survey page for capturing their feedback.

    The email notifications will act as a reminder to the end user on the pending feedback while allowing them to complete the survey by using the link embedded in the email.

  • A policy has been introduced to automatically close a survey after the expiry of a specified number of days.

    This will reduce the list of pending surveys by removing the expired ones and displaying only the current and open surveys for feedback on ‘My Survey’ page in the self-service portal.

  • Introduced two new tables named ‘My Active Surveys’ and ‘My Closed Surveys’ on ‘My Survey’ page to display all surveys that are pending for feedback and those that have been either ‘Submitted’ or ‘Closed’ due to non-submission within the specified time.

  • Now, if the requester of an incident or service request fails to provide their feedback on pending ‘Post Order Survey’, ‘Service Fulfilment Survey’ and ‘Incident Closure Survey’ within a specified time period, a survey reminder email will be triggered automatically to the requester.

    These notifications will help to improve the survey submission probability.

  • Now, after the creation of every nth service request or closure of an incident or service request by an end user, a pop up can be configured on the survey form prompting requesters to provide their experience on the requested service or service delivery.

    This will improve survey submission ratio without compromising user’s experience as the survey will pop up on the portal only for the nth ticket.

  • A new feedback analysis dashboard has been introduced on the fulfiller portal with the following filters and widgets

     

    Filters:

    •  ‘Time’ filter – to filter surveys based on creation time

    • ‘Survey Type’ filter – to filter surveys based on the survey type namely ‘Generic Survey’, ‘Request Fulfilment Survey’, Incident Closure Survey’ and ‘Post Order Survey’

    • Service filter – to filter surveys based on the service and category of incidents and services.

     

    Following widgets have been added to display relevant KPIs:

    • ‘CSAT Score’ –. overall CSAT score of the users

    • ‘Response Percentage’ – response percentage for the surveys submitted.

    • ‘Surveys Submitted’ – count of surveys submitted.

    • ‘CSAT Score Percentage’ – percentage of satisfied and very satisfied customers.

    • ‘Improvement Areas suggested by End Users’ – list of suggested improvement area and issues.

    • ‘Customer Satisfaction Trend’ – trend of average ratings submitted.

    • ‘Top 5 Categories with Dissatisfied Rating’ – list of top 5 service categories with majority of ratings as dissatisfied or very dissatisfied.

    • ‘Top 5 Categories with Satisfied Rating’ – list of top 5 categories with majority of ratings as satisfied or very satisfied.

    • ‘Overall Customer Satisfaction’ – customer distribution count based on the survey rating.

     

    This will help customer feedback analysts to analyse all the feedback surveys submitted by the customers/end users and suggest appropriate improvement measures accordingly.

Dashboard & Reports

Following new reports and dashboards have been introduced on the fulfiller portal

  • Renamed ‘Global IT Dashboard’ to ‘SMO Dashboard’ displaying the major KPIs from all the different process modules on a single dashboard.

    New KPIs have been added in the SMO dashboard for each of the modules.

    This will allow service managers to have better visibility into the state of operations for each process.

  • Added KPIs in the SMO Dashboard for each of the following modules:

     

    Incident Management:

    • ‘Open P1 Incidents’count of open P1 incidents

    • ‘P1-P2 Ageing Incidents’count of open (not resolved or closed) P1 and P2 incidents which have aged for 5 days.

    • ‘Incidents with Hop Count > 4’count of all incidents which have Hop count greater than 4.

    • ‘Service Disruptions (P1-P2 Incidents Trend)’ monthly trend of P1-P2 incidents being created.

    • ‘Incidents via Portal Vs Other Sources’

    • ‘Customer Satisfaction Trend’trend of surveys getting submitted monthly with each trend line reflecting the survey response (Satisfied/dissatisfied/neutral etc.).

     

    Knowledge Management:

    • ‘Domain Contribution Graph’top 10 categories in which knowledge articles have been created.

    • ‘Article Overall Usage Graph’count of published articles with usage count falling within the tiers - 0, 1-10, 11-20, 21-30, 31-50, 51 and above.

     

    Problem Management:

    • ‘Open P1 Problems’count of open P1 problems.

    • ‘P1-P2 Ageing Problems’count of P1 and P2 problems which are open since 30 days.

    • ‘RCA Overdue Problems’count of problems in ‘Under investigation’ for which RCA deadline has passed.

    • ‘RCA Target Met vs Not Met’ – P1, P2, P3, P4 tickets identified by RCA within the time specified for resolving problem tickets vs those with RCA identified outside the specified time.

     

    Change Management:

    • ‘High Risk Changes’count of all high risk changes.

    • ‘Emergency Changes’count of all emergency changes made.

    • ‘Failed Changes’count of all failed changes.

    • ‘Emergency & Failed Changes Trend’monthly trend of emergency changes implemented and failed changes attempted .

    • Introduced new KPI named ‘Average Resolution Time for Each Team’ displaying the average time taken by each team to resolve an outage during a major incident.

Self Service Portal

Following enhancements have been introduced on the self-service portal

  • Now, while raising an incident ticket on behalf of a third party, requesters will be able to see a help text on the incident form, informing them about the nature of the defect or issue and the need to fill up the ‘Requested for’ field. Further, once their ticket has been processed an automated email will be triggered to the requesters with details of their processed request.

    This will help the requesters to follow the right procedure for raising incident tickets on behalf of others.

  • A new functionality has been introduced on the incident and service request forms to enable requesters to add or delete followers to the incident or service request ticket raised by them.

    This will update the list of fulfillers, having a dependency on the ticket raised, who will be able to get notifications on any updates in status of the tickets, until it is closed.

  • A new functionality has been added in ‘My Waiting Approval’ widget on ‘My Approval’ page of self-service portal to display all tickets that are pending for approval of a user.

    This will allow users to view all pending tickets at one place and approve the ones required.

CMDB

Following new capabilities were introduced in the CMDB module:

  • Now, fulfiller users will be able to create incident, service, change, problem requests directly from action section on the ‘CMDB Class Overview’ form. Once the ticket has been submitted, it will automatically be linked to the CMDB class corresponding to the ‘CMDB Class Overview’ form from where it was raised. This will ensure that the ticket or request is correctly categorized.

  • A new ‘Completeness Value’ field has been introduced on the ‘CMDB Class Overview’ form to show the level of accuracy of a CMDB database based on the availability of all the required CI attributes.

    If all the required attributes have been populated in the CMDB database, the ‘Completeness Value’ will be displayed as ‘1’ denoting status as ‘Completed’, otherwise the value displayed will be ‘0’ denoting status as ‘Incomplete’.

    This information will enable process owners to identify CIs with missing attributes and improve the quality of data in the CMDB.

  • New ‘Related List’ tabs have been introduced in the CMDB class overview page to display all incident, change, problem requests linked to the CMDB class.

    This will enable fulfillers and CMDB owners to find all the related details and records pertaining to a specific class at one location.

  • Now, a link to ‘Maintenance Calendar’ will be displayed on the CI form to enable fulfiller users to schedule CI changes directly from the calendar itself.

Incident Management

Following enhancements have been introduced in the incident management process:

  • Now, service desk members will be able to update location and contact number details of a requestor for existing tickets in the incident and service request overview forms.

    This will ensure that the location and contact number information, available to fulfillers is up to date and accurate.

  • A new widget has been introduced on the incident dashboard of the fulfiller portal to display the percentage-wise distribution of P1, P2, P3 and P4 tickets in GBP.

  • A new ‘Incident Queue Rate’ graph has been introduced on incident dashboard to display the count of tickets logged and resolved within the specified time period.

    This will allow fulfiller users to analyse the rate at which incidents have been resolved in an incident queue.

  • A new KPI named ‘Rate of Major Incidents Rejected’ has been introduced on the major incident dashboard to show ratio of incidents proposed vs. those rejected as major incidents.

    This will indicate the efficiency of existing incident management processes, providing a scope for further improvement.

  • A new editable ‘Location’ field has been introduced in the incident form on the self-service portal to enable users to edit information on their location.

    This will ensure fulfillers always have access to accurate and updated location details while processing a request, improving efficiency of the process.

Change Management

Following enhancements have been introduced in the change management process:

  • A new functionality has been introduced on the change request form to allow requesters to add or delete support users (as followers) to change requests that were raised by them.

    This will update the list of fulfiller users having a dependency on the request who will be able to receive notifications on any update in status of the ticket, until it is closed

  • Now, while creating a change request on the ‘Change Plan and Schedule form’, change implementors will be provided with a drop-down field having value ‘Testing Required?’. If testing is not required, the change implementors can select ‘No’ from the drop down options to omit testing and fast track the change process.

    This will provide the flexibility to add or delete ‘Test task’ as required.

  • Now, on creating a change request or a work item, a notification will be triggered to fulfillers containing a hyperlink to the change request or work item on the approval dashboard.

    This will allow fulfillers to navigate to the change request or work item directly from the notification, improving their user experience.

  • A ‘Team Filter’ has been introduced on the change dashboard to enable change implementers or initiators to select a single team or multiple teams in one go and view their performance related to the change records assigned to them.

Service Request Management

Following enhancements have been introduced in the service request management process:

  • A new widget named ‘Request Pending for Acceptance to SD’ has been introduced on the ‘Service Request’ dashboard on the fulfiller portal to show all requests that are pending to be accepted by service desk users / teams.

    This will provide visibility to service desk users / teams allowing them to approve or reject a request as required.

  • Now, a generic service request will be automatically assigned to the service desk team after raising of the request by the requestor enabling service desk users to validate and take ownership of the ticket. Earlier, service desk users had to assign the ticket to self or another user in order to initiate the fulfilment process. Now, the fulfilment process can be initiated right away without the need to self-assign tickets.

  • Now, requesters will be able to view and edit the information in the ‘Contact’ and ‘Location’ fields while submitting a service request on the ‘Generic SR’ form.

    This will ensure the correctness of the data populated in the ‘Generic SR’ form.

  • Now, on raising a service request on behalf of an another user, a notification will be triggered to both ‘Requester’ and ‘Requested for’ users to inform them about the new service request. Similarly, if the status of the request is updated, a notification will be triggered to both users.

    This will keep both the parties updated on any change in the status of the request.

  • Now, on creating a service request an email notification containing a hyperlink to the new request on the fulfiller portal will be triggered to fulfillers or fulfiller teams.

    This will allow fulfillers to access service requests on the approval dashboard directly from the email.

  • Now, notifications will be triggered to service request owners informing them that the service request tickets assigned to them has passed 50% or 75% of their predefined SLA time.
     

    This will enable ticket owners to prioritize those tickets prior to breach of respective ticket SLAs thereby improving their efficiency.

  • The service request dashboard has been enhanced by the introduction of the following widgets:

    • Number of Generic Request’ - count of generic requests raised within the specified time period

    • Number of Service Request’ - count of service requests raised within the specified time period

    • Percentage of Requests Not Resolved within SLA’ widget - percentage of service requests that have breached the SLA within the specified time period

    • Percentage of Service Request - Status Wise’ - status wise distribution of service requests raised within the specified time period

Problem Management

Following enhancements have been introduced in the problem management process

  • Now, whenever a new problem request is created, an email notification containing a hyperlink to navigate directly to the problem request on the fulfiller portal will be triggered to the selected fulfillers or teams.

    This will enable fulfillers to navigate to problem requests on approval dashboard directly from the email notification.

  • A ‘Problem Queue Rate’ graph has been added on the problem dashboard to display the count of tickets that were logged and resolved within the specified time period.

    This will allow fulfiller users to analyse the time spent on resolving problem tickets in the queue.

  • A new capability has been introduced on the problem request form to enable requesters to add or delete users following a problem request that was raised by them

    This will enable problem requesters to configure alerts for users only if they need to receive those notifications.

  • The service request dashboard has been enhanced with the introduction of the following widgets and graphs:

    • Workaround Available’ - percentage of open problem tickets where workaround has been mentioned in problem details page.

    • Ageing Problem’ - count of open problem tickets that have been segregated on the basis of their age groups i.e. ‘30 to 60 days’, ‘60 to 90 days’ and ‘Over 90 days’

    • Problems Closed with and without Change’ - pie chart showing a distribution of problem tickets closed with and without the implementation of a change request within the specified time period

    • Average time to RCA’ - time taken to complete RCA for each problem ticket

    • Problem Closure by Sub Status’ – count of problem tickets that were closed, grouped according to their ‘Sub Status’

    • Problem by Sources’ - count of problems reported, grouped according to their source

    • RCA Rejection’ - percentage of RCA rejected

Knowledge Management

Following enhancements have been introduced in the knowledge management process:

  • Now, hyperlinks can be configured into the email notifications sent to knowledge users enabling them to click and navigate to the page configured in the link.

    This will improve knowledge users experience as now they will be able to gain access to the resource directly from the notification.

  • The knowledge dashboard on the fulfiller portal has been enhanced with the introduction of the following widgets:

    • User Contribution’ - list of top 10 users who have authored knowledge articles

    • Domain Contribution’ - list of top 10 categories in which knowledge articles have been created

    • Article Publish Trend’ - count of articles published in the specified time period

  • Now, upon clicking on an ‘Open Article Content View’ link on the ‘Action’ section of the knowledge details page, users will be directed to the article configured in the link in a new browser window.

    This will improve user experience.

Support

For sales-related inquiries, please reach us at [email protected]

For Support related queries, please write to [email protected]