DRYiCE Gold BluePrint on Cherwell R7

In Release 7 of DRYiCE GBP on the Cherwell platform, we have introduced features like Article Quality Index, which will enable knowledge users and managers to rate knowledge articles, and a new change management workflow called ‘Latent Change’ as per the ITIL guidelines. Apart from this, release R7 also introduces enhancements to improve customer experience and overall product performance across various modules.

Communication Manager

The following SMS notifications have been configured for incident and change management modules:

• Whenever normal change processes have to be expedited due to a newly identified critical vulnerability, SMS notifications will be triggered to all change approvers thus enabling them to act swiftly;
• Upon submission of emergency change requests for approval, SMS notifications will be triggered to E-CAB members, enabling them to follow-up on the requests swiftly;
• Upon moving emergency change requests to ‘Cancelled’ state, SMS notifications will be triggered notifying the task assignment group;
• Whenever major incidents submitted by requesters are withdrawn, SMS notifications will be triggered alerting users in ‘MIM team’, ‘Owned by Team’, and ‘Service Desk Team’;
• Whenever Priority 1 or Priority 2 incidents are assigned, SMS notifications will be sent to all users in the assigned team enabling them to start work on the tickets;
• Whenever incident tickets get proposed as major incidents, SMS notifications will be triggered to all members of the ‘MIM’ team enabling them to act on the tickets;
• Upon closure of Priority 1 or Priority 2 incident tickets raised by end users, SMS notifications will be triggered to requesters for providing their feedback;
• Upon fulfilment of Priority 1 and Priority 2 incident tickets raised by end users, SMS notifications containing incident fulfilment survey will be triggered to requesters for taking their feedback;
• Whenever incidents are raised on behalf of end users SMS notifications will be triggered to requesters as well as end users to keep them updated;

The intent of integrating SMS notifications is increasing the efficiency and productivity of the team by reducing the wait time or the response time for the ticket.

Advanced Survey

• A new graph named ‘Post Order Issues Raised’ has been introduced in the ‘Feedback Analysis’ dashboard to show the count of issues which were selected as ‘True’ by customers in ‘Post Order Survey’.

• Now, upon failure to respond to incidents, requests and post order surveys within the stipulated time, the following communications will be sent to users. Email notifications to be sent on the 7th and 15th day after the initiation of ‘Incident and Request Closure’ survey to remind consumers of the pending survey. Email notifications to be sent on the 3rd and 7th day after initiating the ‘Post Order’ survey. These email notifications will increase the survey submission ratio by drawing users attention to pending surveys.   

• Now, upon successful submission of incident and service request surveys by users, the details   submitted under different   survey categories and subcategories will become visible to fulfillers in the related list of corresponding requests. This will collate all the survey responses provided by end-users, making them available for fulfillers in one place, thus saving their time and effort in compiling them individually.       

Walk-Up Support

• Now, upon submission of service requests through walk-up kiosks users will be displayed the fulfilment ‘Wait Time’ in hours and minutes on the Service Request form. This will make it more convenient for end users as they will no longer have to reach out to the walk up support to ascertain the wait time after the queue number has been allotted to them.

Dashboard & Reports

• The ‘Incident created via Portal vs Incidents by Other Sources’ graph has now been renamed to ‘Incident created via Portal vs Incidents by Chat & Phone’.

• Now, the ‘Date’ filter in the ‘Volumetric’ tab on change and CAB change dashboards will be displayed as ‘Implementation Date’ and the filter values will be expanded to include future duration options also.

• The ‘Incident Queue Rate’ has been divided into two sections. Incident Opened: This will show Opened/Created Incidents for the selected time period. Incident Resolved: This will display the list of resolved incidents for the selected time period.

• The 'Mean time to Recover' widget on the incident dashboard has been renamed to 'Mean time to Repair'.

• The incident management dashboard has been modified as follows. Now, the ‘Closed on 1st Call’ message will not be displayed on requests that have fulfilled the criteria for FCR. Now the ‘% of First Call Resolution’ pie chart present on the incident-performance dashboard will only show tickets that have been closed on 1st call by service desk users

• A new ‘Stale Knowledge Article’ widget has been introduced on the ‘Knowledge Article’ dashboard to show all published articles that have not been updated in the last 6 months.

• A new ‘Flagged Article Authored By Me' widget has been introduced on the ‘Knowledge Article’ dashboard to enable fulfillers to view all articles authored by them that have been flagged by users. enabling fulfillers to find all articles that need attention.

• A new ‘Changes Queue Rate Trend’ monthly trend graph has been introduced on the change performance dashboard for displaying the following information. ‘Changes Submitted’ - month wise count of changes submitted (based on the submitted date/time). Changes Implemented’ - month wise count of changes implemented (based on the actual end date. This will help to assess the efficiency of the change implementation mechanism.

• Now, only the RCA records that are in ‘Draft’ or ’Review’ state will be displayed on the RCA review dashboard.

• A monthly trend graph, ‘Problem Queue Rate Trend’, has been introduced on the ‘Problem Performance’ dashboard for displaying the following information. ‘Problem Opened’ - month wise count of problem records submitted based on the submission date/time. ‘Problem Closed’ - month wise count of problem records closed based on ‘Actual End’ date of the resolution and closure of problem tickets. This will help in assessing the efficiency of the problem management process.

• A monthly trend graph, ‘Service Request Queue Rate Trend’, has been introduced on the ‘Service Request Performance’ dashboard displaying the following information. ‘Tickets Opened’ - month wise count of SR tickets submitted every month based on the submission date/time. ‘Tickets Closed’ - month wise count of SR tickets closed every month based on the ‘Actual End’ date. This will help in assessing the efficiency of the service request process.

Self Service Portal

• The ’Deadline’ field has been removed from the approval form as the information provided did not offer any value to users;
• The ‘Details’ field on the SR approval form has been converted into a non-editable field.
• Now, the name of the approval team has been hidden from end users for service requests and made visible for fulfillers on change tickets thereby removing any unnecessary information
• Now, end users will be able to add and remove followers to the incident and service request tickets raised by them  

Problem Management

• A ‘Create Incident’ link has been introduced in the ‘Actions’ section on the ‘Problem form’ for fulfiller users which will auto populate the details of the problem ticket and logged-in user into incident forms. This will save time and effort expended on manually creating incident tickets from scratch.  
• Now, upon closure of problem tickets, the status of all associated incidents will be automatically updated, and email notifications triggered to assigned team owners informing them of the ticket’s closure.
• A ‘Create a Change Record’ link has been introduced in the ‘Actions’ section on the problem form for problem managers and PIT team members which will auto populate the details of a problem ticket and fulfillers into change records. This will save time and effort expended on manually creating change tickets from scratch. 
• Now, the ‘Problem ID’, ‘Problem Priority’ and ‘PIT Lead’ fields will be visible on both ‘Five Whys’ and ‘5W1H’ RCA forms as labels.
• These will be read-only values for reference to the user, filling the RCA form.
• Now, the ‘Perform RCA’ link will be displayed as activated on all problem records or forms, which have been chosen for RCA or for which the existing RCA has been rejected. The link will inform problem managers to take necessary action on pending RCAs.   
• A link named ‘Refer 5W1H Example’ has been configured on the 5W1H page to enable users to click on the link for launching a new browser window containing an explainer video on how to fill the 5W1H RCA form.
• Now, the deadline for completing RCA will be displayed on the quick info banner on the problem overview page, informing problem managers and fulfiller users about the timeline for closing RCA, enabling them to complete the process within the stipulated time.
• Now, upon choosing ‘Recurring Incident’ or ‘Unresolved Incident’ in the ‘Source of Problem’ field, it will become mandatory for the problem initiators to link at least one incident record in the incidents-related tab of the problem form to complete the submission process. This will ensure that the root cause of the incident is identified and fixed. 

Service Request Management

• An ‘Add New Approver’ button has been introduced on the service request approval form on the fulfiller portal to enable fulfiller users to add ad-hoc approvers to service requests.
• This will enable fulfillers to add additional approvers outside the existing approval workflow, if required, thus improving the efficiency of the process.
• Now, approvers will be able to approve ‘Add/Remove SR’ requests from the fulfiller portal.
• Now, fulfiller users will be able to add new ad-hoc tasks to generic service request tickets.
• The timer for resolution SLAs has been modified with the introduction of the following changes -
• Now, upon changing the status of service requests to ‘Assigned’ state, resolution SLAs will be automatically opened against the requests;
• Now, the timer for resolution SLAs will be paused upon moving the status of requests to ‘Pending’ or ‘Resolved’ state. Upon moving the status from the ‘Pending’ status to ‘Assigned’, the computation will be resumed
• Similarly, once ‘Resolved’ requests are moved to ‘Reopened’ state with sub-status as ‘Assigned’ the timer for associated resolution SLAs will automatically resume;
• The resolution time will be calculated till the status of the request moves to ‘Closed’;
• The increased accuracy in reporting SLAs will help in improving the efficiency of service request management process.
• Now, in order to move a task status to ‘Pending - Part Replacement’ state, fulfillers will have to enter the reason for the part replacement in the ‘Notes’ section which will also get displayed as a journal entry. Once the ‘Notes’ section has been filled, the status will automatically change to ‘Pending’ with reason as ‘Part Replacement’. The introduction of mandatory notes will document the process for use in future auditing purposes. 
• Now, in order to move a task status to the ‘Pending - Vendor Action’ state, fulfillers will have to complete the mandatory step of updating the vendor ticket number inside the ‘Vendor Ticket’ tab that gets activated upon moving the task to ‘Vendor Action’. This will enable fulfillers to raise vendor tickets against service requests for separating vendor and fulfiller SLAs.       
• Now, in order to move a task status of service requests to the ‘Pending - Change Scheduled’ state, task assignees will have to associate them with the relevant change tickets for the step to be completed. Upon closure of associated change tickets, the task assignees will have to manually update SR tickets as they will not be closed synchronously.
• Now, in order to move a task status of service requests to the 'Pending - Appointment Scheduled' state, task assignees will have to enter details related to the activity in the ‘Notes’ section which will be displayed in the journals. The mandatory notes will help in auditing the activity at a later date.  
• Now, upon moving tasks to the ‘Pending - Customer Action’ state, task assignees will have to provide the reason for putting tasks on hold in the ‘Notes’ section which will be captured as journal entries. Once requesters have provided their comments on the self-service portal, the task status will change to ‘New’ and comments will become visible under the ‘Portal Comments’ tab on the fulfiller portal. If requesters fail to respond within 5 days, requests will auto close and notifications will be triggered to end users and assigned teams informing them about the closure.
• Email notifications to be sent to requesters when requests have been set to ‘Pending-Customer Action’ informing them about further information required to be provided;
• Email notifications to be sent out to task assignee/owners once requesters have submitted the information being sought;
• Email notifications to be triggered to requesters in intervals of 2, 4 and 6 days, reminding them to respond with the information being sought.
• Email notifications informing requesters about the scheduled appointment;
• Email notifications informing requesters about the updated date and time of scheduled appointment;
• Email notifications ten minutes prior to the appointment reminding requesters to join the meeting;
• Email notifications informing requesters about their failure to  join the scheduled appointment.
• These email notifications will keep requesters updated about the appointments that have been scheduled for them.

​​​​​​​​​​​​​​Incident Management

• Now, incidents that have been logged through the ‘Report a New Issue’ tab on the portal will be automatically created in the ‘Assigned’ state and directly assigned to the service desk team.
• Any user in the major incident management team can now change the major incident manager for a ticket. Updates for the same will be logged in the Journal logs.
• Now, upon cancellation of incidents, the corresponding SLAs and associated ‘Responded by’ and ‘Resolved by’ SLA parameters on the task status bar will also be removed.
• Now, support users will be able to create new incident templates based on criteria such as ‘Category’, ‘Sub Category’, ‘Team to Assign’ etc, on the ‘New Incident Template’ form.
• This will provide an additional option to use pre-existing templates with pre-populated fields while raising incidents, saving time on creating incidents from scratch and maintaining uniformity across teams.
• Now, support users will have the capability to update or modify existing incident templates from the template page. This will provide the flexibility to create incidents dynamically according to new requirements.  
• Now, support users will be able to search the saved incident templates using the ‘Searches’ section in the incident detail form. This will enable support users to find the relevant template and quickly create new incidents.
• Now, support users will be able to create incidents from the ‘Incident Template’ form using the ‘Create incident button’ on the template page. This will save time and effort needed to create incidents from scratch.
• A link named ‘Create a Problem ticket’ has been introduced on the incident form in the fulfiller portal enabling fulfiller users to directly create problems from the incident page. If the incident is saved, then it will automatically get linked to the newly created problem record. This will enable fulfillers to quickly raise problems, if necessary, from incidents.  
• Now, incidents promoted to major incidents category will be flagged on the portal, alerting requesters on the change.
• Now, the search results for knowledge articles will display the article's title and its body text trimmed to the first 2 sentences, helping users quickly find the right content with only a cursory glance. This will improve knowledge users experience while browsing for the right knowledge.  
• Now, upon closing the ‘Publish Broadcast’ task without publishing the announcement, service desk users will be displayed an error message as follows: ‘Kindly publish an announcement before closing this task’.

​​​​​​​​​​​​​​Change Management

• Introduction of ‘Latent’ changes as per the ITIL4 guidelines will now enable change initiators to retrospectively approve and document any unapproved changes carried out during ‘Normal’ or ‘Emergency’ change flow.
• Now, change managers will be able to add ad-hoc approvals to Emergency and Normal change requests.
• This will allow change managers to manage and update approvals on demand.
• Now, upon sending ‘Emergency’ change requests without mandatory linkages to incidents, change initiators will be displayed an error message as follows: ‘Please link the incident(s), for which this emergency change is being raised’.   
• This will limit the use of ‘Emergency’ changes only to resolve incidents, limiting the risk of causing more incidents due to hasty implementation of change.  
• Now, upon ‘Refer Back’ of ‘Normal’ or ‘Emergency’ change requests, change initiators will be provided with an option to update the following fields: ‘Service’, ‘Category’, ‘Primary CI’, ‘CMDB Update Required’, ‘Reason for Change’, ‘Short Description’, ‘Description and Details of CMDB Update’.
• This will ensure further qualification of change requests and also enable change initiators to quickly make the necessary changes in the required fields and submit requests for review.
• Now, upon ‘Refer Back’ of change requests, a link will be activated on the status section of the quick info banner to enable change initiators to click and quickly resubmit requests with the necessary corrections.

​​​​​​​​​​​​​​Knowledge Management

• Now, upon submission of knowledge articles for review, a section called ‘AQI Checkpoints’ will be activated in the related list tab defining the various parameters and their corresponding weightage for assessing the article. The ‘Review’ team assigned to the knowledge article, as part of existing knowledge article process, will be able edit the AQI checkpoint record by mapping it objectively to the article under review. The edited record will have to be saved in the AQI Checkpoints section before publishing it as associated AQI score. The AQI helps maintain consistent quality of knowledge articles attached to a knowledge base where articles are written by various authors.
• Now, ‘Inactive’ authors of knowledge articles can be changed by any member of a technical review team. This will help to  direct  the flow of notifications to appropriate authors in case of flagging of the article by any of the users.
• Now, the ‘Most liked Knowledge Article’ and ‘Most Used Knowledge Article’ tabs in the knowledge dashboard on the fulfiller portal will only show knowledge articles in the ‘Published’ state. This will ensure that articles in the ‘Review’ or ‘Draft’ state are not displayed under the tabs.     
• Now, upon unticking the ‘Flagged’ checkbox at the bottom of knowledge articles flagged by knowledge users for improvement, notifications will be triggered to appropriate knowledge management team and authors. The notifications will save time and effort spent on monitoring flagged articles manually in absence of automatic notifications.
• The introduction of 'User View’ and ‘Technician View' fields on the knowledge article page in the fulfiller portal will enable fulfillers to view the number of times a technician has opened the article. This segregation will help to assess a technician’s level of knowledge as well as relevance of knowledge articles. 
• The introduction of ‘Dislike’ and ‘Add to Favourite’ buttons on knowledge articles on the fulfiller page will enable fulfillers to quickly express their disapproval or endorsement of an article.   
• Now, whenever knowledge articles are flagged for incorrect content, notifications will be sent to the knowledge management team and author to inform them of the activity. This will enable them to update the article.

• Now, service desk users will be able to add and remove followers to  incidents, service requests, change requests, problems and knowledge article drafts.
• Now, support users will be able to search for tickets that have been closed through the quick search option on the fulfiller portal. This will help them to search and refer to old tickets, if required.

The following changes have been introduced in the task status workflow on the GBP fulfiller portal:

• Now, the transition of tasks across all modules will be in the order of ‘New’, ‘In Progress’ and ‘Closed’;
• The field ‘Acknowledgement Status’ and associated link have been removed from the task form across all modules;
• The ‘On Hold’ status will be replaced by ‘Pending’ status across all the modules;

For Support related queries, please log onto support.dryice.ai@hcl.com