Hornbill How To: Two Stage Closure in Service Manager
Many customers like to operate what is known as a “Two Stage Closure” routine after a resolution to a request has been established. This typically involves changing the status of the request to “Resolved” when the initial resolution has been provided to the customer, and closing the request only when either a confirmation of the resolution has been received from the customer, or a certain period has elapsed without action or response, and the request should be automatically closed e.g. 7 days. This can be incorporated into Hornbill Service Manager using the configured Business Processes against your requests and this article explains how to set this up.
Before configuring, its useful to consider the different scenarios when resolving and closing a request. What will be the same for every request is that it will be Resolved (i.e. have its status set to Resolved). This is typically performed by an Analyst entering a resolution within the Hornbill request, which may notify the customer.
At this point there are 3 scenarios that could occur:
1) Resolution Accepted - The customer accepts the resolution, either via the Service portal or the Analyst closing on their behalf. This moves the status of the request to Closed
2) Resolution Rejected – The customer advised the issue is not resolved or the resolution didn’t work, either by actioning this on the Service Portal or informing the Analyst who will reopen on their behalf. This moves the status of the request to Open
3) No Action – There is no response from the customer. Instead of the analysts having to remember to manually close these requests, the system will automatically close any resolved request after “X” number of days. This moves the status of the request to Closed
Business Process Configuration
The first thing to be set up is an Automated Task node – which has a type of “Suspend - Wait for Status Change”. We know that by the time it reaches this node, the status of the request will be “Resolved”. This pauses the process until the status changes to either Closed or back to Open – as per the scenarios above.
Within the configuration of this node, you will also have the option to set an Expiry Period. This is the period that this Suspend node will stay active for, before it automatically moves on to the next node in the process – which is how it possible to set up the automatic closure after a defined number of days. The expiry period is in working hours and will adhere to the hours configured in the "ServiceDeskDefaultCalendar" working time calendar found in Hornbill Administration, Home > System > Working Time Calendars.
After this Suspend Node, in our example we have a Decision Node that has 3 outcomes:
1) Reopened By Customer – this decision criteria is based on if the status has been changed from Resolved to Open
2) Expired - This decision criteria is based on if the status has remained as resolved and Expiry Time we provided has elapsed. The expiry time is in working hours and will adhere to the hours configured in the "ServiceDeskDefaultCalendar" working time calendar found in Hornbill Administration.
3) No Match – This refers to the only other option, which is that the request has been closed – and the criteria is based on if the status has been changed from Resolved to Closed
As per the screenshot, we then have differing actions based on which of the 3 outcomes occurs. Our “Expired” and “No Match” options set the Closed Checkpoint, if it has expired it automatically sets the request status to closed, and the process ends. Our “Reopened” outcome, sets the reopened checkpoint and loops back to the start of the workflow – waiting for the request to be resolved once again after further investigation has taken place.
Incorporation with the Service Portal
If you utilise the Hornbill Service Portal, when a request is in a resolved state, the customer has the option to confirm that resolution was successful, or if there is still a problem by clicking one of two buttons. This simply changes to the status to “Closed” (Successful) or “Open” (Still and Issue). No additional configuration is required to accommodate this – because the Business Process account for both of these outcomes as the decision is based on the request status, however that status is set.