Follow the sun workflow
JIRA Service Desk is a very versatile tool, it can be used for small IT teams to do inhouse IT support for internal support to large multinationals who have complex business workflows and have a large service team spread across the world.
Follow-the-sun support model is a very common paradigm for enterprise support companies wanting to deliver round the clock critical support for business critical applications.
Follow-the-sun paradigm background reading
Bugs and production problems are almost a certainty, this means companies need to organise resources and build capability to deliver support to a global customer base. Follow-the-sun support model enables tasks to be passed between support centers that could be located around the world. In addition to servicing local clientele the support centers will take on additional tasks to reduce customer downtime and increase support responsiveness.
For instance, an agent in San Francisco who might be dealing with a critical customer ticket can pass his work to an agent in the next time zone (in this case APAC – Tokyo) to continue servicing the customer at the end of his or her work day.
The following use case is for a company with offices (and service agents) in EMEA, APAC and Americas to service a truly global customer base:
Configuring JIRA Service Desk
The best aspect of the configuration below is that all the complexity is hidden away from the customer. And the customer experience isn’t impacted with the JIRA Service Desk configuration and it lets your organisation to scale implement follow-the-sun workflow.
This is a 3-step process:
Step1: Configure JIRA Service Desk Workflow
Add a new workflow status ‘internal transfer’ for agents to transfer tickets internally to other support centers.
Tickets must be able to transition to this status from any open ticket status (waiting for support and waiting for customer).
Any service request in this status will require attention from external support center.
Associate the ‘internal transfer’ screen created above for the service agent to choose which support center the ticket needs help from.
Step2: Configure agent screens and custom fields
Add 2 custom fields:
Transfer Office : The first is a Select List used to store list of support centers.
This will be used by the agent on the internal transfer screen (created below), when transferring issues between offices.
TimeZone : The second is a Select List to record which time zone the customer ticket belongs to.
This will be set by the customer in the create issue screen, when the issue is created.
Add a screen for ‘internal transfer’ workflow transition for agents to select the target transfer office.
Step3: Configure agent queues to conform to the new workflow
The agent views are configured on the assumption that agent in a given time zone will only service customers in that time zone. The agent will work on tickets from other time zones only when they need her/his attention or the issue is high priority (P0 or P1).
Create agent views for agents in EMEA, Americas and APAC regions to view tickets from their support centers, in addition to the transferred ticket from other support centers.
Agent queue for EMEA
Create and configure EMEA agent queue with the following JQL:
Agent queue for APAC
Create and configure APAC agent queue with the following JQL :
Agent queue for Americas
Create and configure Americas agent queue with the following JQL:
Follow-the-Sun workflow in practice
Customer chooses a time zone while lodging a ticket, this can also be automated via Valiantys nFeed plugin.
Viewing and assigning issues
Depending on the customer location, the issue will show-up on the support center queue(s) of the close agent:
P0 and P1 tickets having severe business impact will show-up on agent queues regardless of customer timezone:
Inter-office ticket transfer
In this instance, if the agent in Americas wants to transfer a ticket to the next time zone support center – so that the ticket can be worked on in other time zones. The agent executes the transfer office workflow transition and selects the target office:
And voila! When an agent in Tokyo office logs in and looks at his agent queue, he’ll find the transferred ticket from Americas.
Now the agent in Tokyo can work on the ticket and get back to the customer overnight! While the agent in Americas is offline.
When the customer updates the ticket, the pre-configured JIRA Service Desk workflow will apply and the team in Americas will take over the investigation of the ticket the following day.
To be continued…
Follow-the-sun support model is quite common for enterprise support companies and ensures a continuous support for high priority issues. JIRA Service Desk is a very versatile tool and can be used to deliver smooth support services by a support team across several countries. You now know how to configure JIRA Service Desk for such a support model and can enjoy fully the adaptability of this tool.
In the next instalment, I’ll show more advanced configuration settings and automation using our own nFeed add-on.