Follow-the-sun support with JIRA Service Desk


Posted by
Ajay SRIDHAR

December 2, 2014

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.

Scenario

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:

Americas EMEA APAC
image2014-11-12 14-10-11

  • San Francisco – USA

 

image2014-11-12 14-11-31

  • London – UK
  • Toulouse – France
image2014-11-12 14-13-29

  • Tokyo – Japan

 

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

image2014-11-12 15-34-59

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.

Timezone

Add a screen for ‘internal transfer’ workflow transition for agents to select the target transfer office.

Internal transfer to another 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:

(status in ("Waiting for support") AND (
TimeZone in ("GMT+00:00","GMT+01:00","GMT+02:00","GMT+03:00"))
OR (status = "Internal Transfer" AND "Transfer Office" = "Toulouse/London" ))
OR (priority in (P0,P1) AND status = "Waiting for support")
ORDER BY "Time to resolution" DESC

EMEA queue

Agent queue for APAC

Create and configure APAC agent queue with the following JQL :

(status in ("Waiting for support") AND (
TimeZone in ("GMT+05:00","GMT+06:00","GMT+07:00","GMT+08:00","GMT+09:00",
"GMT+10:00","GMT+11:00","GMT+12:00","GMT+13:00","GMT+14:00","GMT-11:00","GMT-12:00"))
OR (status = "Internal Transfer" AND "Transfer Office" = Tokyo))
OR (priority in (P0,P1) AND status = "Waiting for support")
ORDER BY "Time to resolution" DESC

APAC queue

Agent queue for Americas

Create and configure Americas agent queue with the following JQL:

(status in ("Waiting for support") AND (
TimeZone in (GMT-01:00,GMT-02:00,GMT-03:00,GMT-04:00,
GMT-05:00,GMT-06:00,GMT-07:00,GMT-08:00,GMT-09:00,GMT-10:00))
OR (status = "Internal Transfer" AND "Transfer Office" = "San Francisco" ))
OR (priority in (P0,P1) AND status = "Waiting for support")
ORDER BY "Time to resolution" DESC

Americas queue

Follow-the-Sun workflow in practice

Customer Workflow

Customer chooses a time zone while lodging a ticket, this can also be automated via Valiantys nFeed plugin.

Part 2 of the series will cover advanced JIRA Service Desk configuration including automating user input to decrease customer drag.

 

Timezone

Agent Workflow

Viewing and assigning issues

Depending on the customer location, the issue will show-up on the support center queue(s) of the close agent:

Americas Queue 2

 

P0 and P1 tickets having severe business impact will show-up on agent queues regardless of customer timezone:

Americas Queue 3

EMEA Queue 2

APAC Queue 2

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:

Internal transfer to another 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.

APAC queue 3

Now the agent in Tokyo can work on the ticket and get back to the customer overnight! While the agent in Americas is offline.

Respond to customer

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.

  • Ajay, thank you for the extremely useful and professional article!

    -AM-