Browse Prior Art Database

Global Sameday Response Tool

IP.com Disclosure Number: IPCOM000247445D
Publication Date: 2016-Sep-08
Document File: 4 page(s) / 58K

Publishing Venue

The IP.com Prior Art Database

Abstract

Global sameday response tool. A means of prioritizing international work flows to take in to account the various time zones of the participants, the objective being to send a request sufficiently early to allow the final response to be received on the same day.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 27% of the total text.

Page 01 of 4

Global Sameday Response Tool

Today's 24x7 global business environment is facilitated by communication across multiple time zones. This communication is often time-critical with a business at one location suspended pending a required response from another. The Acceptable Response Time ART varies case by case but typically a 'same day' response SR is required. When all the parties in the communication are located in the same time zone and working the same shift pattern there is an inherent understanding of the required timing of the request and response to achieve this. It is clear that in order to allow the respondent sufficient time to undertake the necessary work and formulate a reply the request must be sent before a certain deadline, the Request Deadline RQD. The RQD will vary depending on the complexity of the work requested and the availability of resource at the receiving end to process it, the process time PT, but for a simple request this might be 4 pm.

    However where the parties in the communication are located in different time zones there is no inherent understanding of the necessary timing to achieve a sameday response. If we take the example of a person in the UK communicating

with a person in Bangalore India there is a +5.5 hour time difference, so a request sent at 4 pm UK time would be received at 21:30 pm in Bangalore, allowing little possibility of a sameday response. If the PT is one hour and the respondent is

working a 9-5 shift then the RD would be 10:30 am UK time, but this would only be apparent to those communicating regularly with Bangalore.

In reality the situation is often much more complex, with more than two parties

participating in the communication at several locations around the world. The locations of these parties may not be known to the requester, and the situation is further complicated by individual shift patterns and Daylight Savings Time DST.

    A typical example in a service environment, assuming a 9-5 shift pattern, could be a customer in Moscow (+3 hours) reporting a problem to a Level 1 (L1) support team in Bangalore (+5.5 hours) who require assistance from a Level 2 (L2) support team in the UK. If the L2 support team in the UK ask the customer a simple question about his setup at 12 am UK time they might expect a response the same day. However the query would not be picked up by the L1 team in Bangalore until 5:30 pm their time, after the end of the shift, so would not be processed until 9 am the next morning. The next day the request could be relayed to Moscow who could call the customer and respond before 5 pm Bangalore time, allowing the response to be relayed to the UK before the 5 pm UK time. Had the initial question from the L2 support team been relayed to Bangalore before 10 am then the customer in Moscow

would have been contacted immediately and the reply relayed back to the uk the

same day.

    This multi-timezone communication frequently results in protracted delays, often of several...