Business hit the global stage decades ago. Markets, customer bases, distribution channels, everything. It’s commerce around the world, around the clock.
At the same time, thanks to the cloud, more and more organizations of all sizes are connecting operations and workers from wherever they are, SMBs as well as Fortune 500s. Such connectedness is essential for customer support, yes, but equally so for things like product engineering, application development, and the continuous flow of ingenuity.
After all, your company keeps promising new products and services to customers, and time to market is imperative.
If your development groups are spaced around the world, there can be no down time between countries or continents. There can be no latency across locations for users working at different times but using the same system. Tasks, coordination and communication must all be in continuous, forward motion —especially when processes like product engineering and application development are under deadline.
Collectively, this puts pressure on thecloud technologies you rely on. Which means the model you use for customer support and technical backing must be stable, reliable, scalable, flexible, affordable, secure and trusted… at virtually all costs.
What customer support model should I use? Good, better, best.
Customer support options for global business and development operations are wide-ranging. While it’s easy to weigh different models as being a right or wrong fit, a more pragmatic approach is to look at them in a good, better, bestscenario. In that order (and in our opinion), here are some of the more recognized support models now in use, including variations of those models.
Tiered support
The tiered support model first took shape in the mid ‘80s and is still the most used practice to resolve technical and customer support issues. By being able to escalate an issue from general service desk up to an expert-level development or vendor team as needed, this method has proven to be a good one for responding to and resolving issues in a timely manner. Of course, support at the developer or vendor plateau (often tier 3) is generally reserved for the most complex issues, since experts at this stage are an expensive resource. But still, they’re a resource, and they’re available as needed.
According to Paul Dooley, a 30-year veteran of planning and managing technology services, the advantages of a tiered support model aremany. As he notes, the modelhas “proven its value” and been adopted globally by organizations of all kinds because it:
• Incorporates most vendor support tools.
• Works well when a large percentage of issues are relatively simple (tier 1).
• Is effective when there’s a low frequency of change and minimal deployment of new releases to the live environment. “When the support environment is relatively stable, with only one or two major releases per year and minor interim functionality releases, the tiered model can resolve most of the issues quickly at tier 1 and with only a small percentage of issues requiring tier 2 or 3 support.”
• Is compatible with the traditional structure of most IT organizations, in which staff are organized into support groups aligned with specific technologies and applications.
• Positions a dedicated function as the single point of contact for customers; for example, “installation” or “no signal.”
• Is well documented and relatively straightforward to implement.
Where the tiered support model falls short
On the downside, as Dooley puts it, “Adopters of the tiered support model face increasing challenges due to the changing landscape (of technology and customer support).” His thinking is that the tiered approach is linear in nature and that it:
• Fails to encourage collaboration and knowledge sharing among support teams, i.e., employees, technicians, engineers, and management.
• Creates a “hero” culture vs. a collaborative environment, the hero often being a tier 3 engineer or expert who’s unwilling to be a good teammate to everyone else.
• Assumes the correct classification of complex issues at tier 1 to scale issues properly. Unfortunately, issues of a complex nature are often underestimated and initially routed to lower support levels rather than higher ones.
• Overly promotes self-service, resulting in a greater percentage of issues becoming more complex than they really are and going unresolved.
• Doesn’t adequately support the trend of deploying new functionality each time it becomes available.
• Is inhibited by support queues, work in progress, and backlog — the infamous support “black hole.”
All things considered, however, tiered support still falls into the “good” category overall. As we said earlier, “this method has proven to be a ‘good one’ for responding to and resolving issues in a timely manner.”
Swarming
In an associated blog post to Dooley’s article, Gregg Gregory introduces the idea of swarming and how it takes a step up from traditional tier-based support.
To begin with, Gregory says, in a tiered situation the tier 1 support technician must usually either research and resolve the issue themselves or escalate the interaction to the next level. If escalated, the tier 2 technician is typically in the same boat of trying to resolve the problem on their own. Escalate to tier 3, same thing.
Translated, the whole tiered process is routinely a linear one-person show, with an expert-level resource joining in to help only when absolutely needed. (Remember, experts are expensive help.)
Conversely, swarming promotes a non-linear team approach throughout the support process. We’ve re-sequenced Gregory’s original list from his post, but the swarming concept still works like so:
1. Realize that every support issue does not require swarming. When a resolution can be reached with one person, excellent.
2. Always remember that swarming success is based on trust. A support technician must be able to know that his colleagues will always be supportive — internally as a group, and externally for the customer. No egos and no “heroes” allowed.
3. The support technician who initially takes an issue owns it through resolution; no matter how high the issue is scaled, they remain the point of contact as other support resources join in to help solve the problem.
4. Don’t overthink the process or the principles behind swarming. It’s teamwork at the most elementary level.
5. When establishing a swarming model, all persons who are involved should have input into designing and building the process. This helps cover all bases when plotting support touch points, establishing communication channels (including with the customer), how to effectively hand off support tasks among different technicians, and so on.
6. Make managers and support team leaders central to the process. Within a support organization, they are typically a new system’s sponsors, the voices to senior management, and often the best implementers, early adopters and coaches.
7. Share swarming team successes with other areas in the organization.
In all, the swarming model is intended to help support groups resolve customer issues more assuredly and more quickly. Although a single technician might well resolve an issue, swarming involves what amounts to tier 1, 2 and 3 technicians from the very beginning and takes escalations out of the support equation. It also helps prevent support issues from falling into a black hole.
So, is swarming better than a tiered support approach? In many ways, it is, and Gregory put the comparison this way. “Candidly, we realize that tier-based support is a pre-defined linear process that was developed around stove pipes and silos. In today’s fast-paced environment, it simply does not meet the expectations of customers (whereas swarming does). This is true for internal as well as external customers.”
“Candidly, we realize that tier-based support is a pre-defined linear process that was developed around stove pipes and silos.”
Two other questions as well. First, is swarming suited for application development and product engineering environments? Yes again. And second, does it work for global around-the-clock operations?
That depends on the support provider and what service schedules they provide.
Follow the sun
Especially for application development, product engineering, software engineering and the like, follow the sun is the best support model to keep global development operations up and running. Erran Carmel and J. Alberto Espinoza of American University and independent researcher Yael Dubinski defined the follow the sun model this way in their 2010 paper published in the Journal of Management Information Systems:
“Follow the sun (FTS), a sub-field of globally distributed software engineering (GDSE), is a type of global knowledge workflow designed to reduce the time to market. The knowledge product is owned and advanced by a production site in one time zone and handed off at the end of their work day to the next production site that is several time zones west to continue that work. Ideally, the workdays in these time zones overlap such that when one site ends their day, the next one starts.
“FTS has the potential to significantly increase the total development time per day (as viewed from the perspective of a single time zone): with two sites the development time can increase to up to 16 hours, or up to 24 hours if there are three sites, reducing the development duration by as much as 67%.”
With two (FTS) sites, the development time can increase to up to 16 hours, or up to 24 hours if there are three sites, reducing the development duration by as much as 67%
In a previous paper, Carmel et al.(2009) noted that, “as FTS is a sub-field of GDSE, the same agile software development methodologies that are found to work well in GDSE work well with FTS.” In particular, the authors say that agile software development methodologies assist the FTS principles because they:
1. Support daily handoffs – The continuous integration and automated integration of source code allows each site to work in their own code bases during their work day, while the integration maintains updated, testable code to be used by the next site.
2. Deal with communication – Agile methodologies emphasize communication. They specifically emphasize face-to-face communication, which can be done within one site. Since FTS aims to reduce inter-site communication, the face-to-face aspect is not a large hindrance to the overall application of agile development methodologies.
3. Elicit cooperation and collaboration – As FTS requires more collaboration and cooperation, this emphasis is especially useful.
For all its benefits and growing adoption globally, though, follow the sun support still has hurdles. Different cultures and communications across those cultures remain persistent issues. And coordination remains a high hurdle because the technology platform you use often comes in to play.
Raul Guerrero of Venga Global discusses the coordination aspect in a July 2018 blog post. Hecalls it “finding times for one team to overlap with another, which often causes delays in responses.”
Or in a word, we call this “latency.”
For any continuous 24/7 development cycle, coordination is all about closing the gaps between teams that are separated by global time zones and locations.
For any continuous 24/7 development cycle, coordination is all about closing the gaps between teams that are separated by global time zones and locations. The “active” pod is during business hours in a specific location. As importantly, coordination requires providing every team member with a clear overview of a specific process, the status of each task, and final outcomes throughout the development spectrum.
If at any point one team needs to work a longer shift or wants to work ahead of a project schedule, handing off tasks and clarifying timetables can be difficult across time zones and continents.
Yet the worst latency nightmare is a platform that can’t fully —or reliably or securely —support your operations and the number of locations in your global development environment.
Google Cloud Platform for follow the sun customer support
If follow the sun is the best support model for global teams and their product engineering and application development processes, is Google Cloud Platform (GCP) the best platform on which to support the FTS model?
Fair question. And to answer it, consider some of the things GCP provides.
Foremost, the private, software defined GCP network delivers fast, reliable and secure connections to users around the world. By the numbers, Google GCP currently reaches 20 global regions, 61 zones, 134 network edge locations, and customers in more than 200 countries and territories. Google is also adding new data centers Seoul, Jakarta, Salt Lake City and Las Vegas.
For collaboration and daily handoffs between time zone and locations, the growing GCP network reduces the latency that can often occur during around-the-clock development cycles.
With the combination of Google data centers worldwide and the public cloud, GCP gives a development organization the ability to improve response times and performance for end users and teams globally. More importantly for collaboration and daily handoffs between time zone and locations, the growing GCP network reduces the latency that can often occur during around-the-clock schedules and development cycles.
Also in late 2020 when Google activates its private Dunant undersea cable connecting the U.S. and France, the cable will transmit 250 Terabits of data per second — “enough to transmit the entire digitized Library of Congress three times every second.” Dunant will be the first cable in the water to use space-division multiplexing (SDM) technology, which increases cable capacity with 12 fiber pairs (rather than six or eight in traditional subsea cables) and power-optimized repeater designs.
And tools? GCP provides ample product engineering and application development toolsets for big data and machine learning, networking, storage and databases, computing, platform management and security.
So yes, Google Cloud Platform is indeed a viable platform for follow the sun support, and in our mind, the best platform.
Stay tuned…
ClearObject already uses GCP for our Engineering Cloud Direct Services to migrate, deploy and manage IBM development tools in the cloud. By freeing up development teams from having to manage the tools they use, they instead focus on critical tasks like product engineering and application development.
With GCP’s impressive performance and security-compliant systems for these Direct Services, can an Engineering Cloud service for follow the sun support be far behind?
Stay tuned. We’ll be making a service announcement closer to Q1 2020.
#productengineering #tieredsupport #applicationdevelopment #customersupport #customerservice
