Shutl consists of many departments; this article focuses on the engineering and the customer service (CS) teams. Historically, the two teams have always been based in different office locations, which contributed to them remaining quite separated. Recently the CS team moved to an office based within walking distance from the engineering team’s office. We wanted to use this opportunity to try to bring the two teams closer together. In comes Swapping Fridays.
What is Swapping Fridays?
Swapping Fridays is an initiative that involves a single developer and a single CS agent pairing up for the day to swap roles (as far as practical). Here is how it works: on any given Friday, an engineer and a CS agent will be paired up to work together for the day. For the first half of the day, the engineer transforms into a CS agent. They will first sit in a short meeting where all the CS tools are demonstrated and explained. They will then take their position behind a computer and start going through emails and live chats with their assigned CS partner.
Figure 1. A CS agent (left) and Shutl engineer (right) solving customer tickets
This goes on up until lunch time, where the pair gets a little breather apart. Once lunch is done, it’s the CS agent’s turn to step into the engineer’s shoes. Together with the engineer, they go through the process of how an engineer might solve technical customer queries, or if there are none, what an engineer does on a daily basis.
Figure 2. CS agent in the role of an engineer
This continues until the end of the day.
Objectives
As you can imagine, it’s a fairly substantial time investment from both the engineering and CS teams. Let’s take a look at the outcomes we thought the initiative would produce.
Unifying the two teams
As previously stated, the major outcome we hoped to achieve was to help unify the engineering and CS teams. Before the initiative, we found that CS agents did not have a good understanding of how a technical issue was investigated, and the engineers struggled to understand the challenges that the CS agents deal with when solving customer issues. This contributed to a couple of behaviors.
First, the engineers would occasionally be frustrated when a technical issue was raised, and there was not enough information to start an investigation. Second, the CS agents would occasionally get frustrated at the length of time it took engineers to respond to tickets. This was caused by a disconnect of expectations from one team to the other. After the initiative, there was a change in this attitude. We found that the engineers realized the work, effort, and skill that the CS agents required to continuously help customers with issues, and the CS agents realized the time investment for an engineer to properly investigate an issue.
This led to better communication between the teams which, in turn, resulted in better and faster responses to customers. We also saw that the sharing of knowledge when the pair worked together improved the quality of work that the individuals produced. As an example, CS agents often showed ways of getting information that engineers were unaware of, and engineers could show how the CS agent could solve certain issues without having to escalate a ticket to the engineering department.
Bringing engineers closer to the customers
Seeing as it’s the engineers who build the product for customers, but the CS agents who talk to these customers, there are tangible benefits in getting the engineers closer to the end consumer of their work. It’s possible for engineers to occasionally forget that the work they do can drastically affect the customer’s opinion of the product. We hoped that by allowing engineers to talk directly to customers, it would help to instill the impact that the engineers have on the customers on a daily basis.
Outcomes
Reducing the number of escalated tickets
We hoped that with the combination of the above objectives, there would be a decrease in the number of CS tickets that were escalated to the engineering team. The following graph shows that this outcome was achieved.
Figure 3. The number of tickets escalated to the engineering team in 2018
It’s important to note that the Swapping Fridays was not the sole reason for the drop, but it was also a catalyst that enabled people to come up with innovative solutions to improve the processes. For example, one solution was to filter all escalated tickets through the senior members of the CS team before they reached engineering. This was suggested after noticing that some escalated tickets were solvable without the intervention of the engineering team, but not all CS agents possessed that knowledge.
As you can imagine, the engineering time saved from not having to look into as many tickets was substantial. This also had a big impact on response time to customers. An escalated ticket can take anywhere between 30 minutes and 1 week to resolve. As fewer tickets were being escalated, the response times back to the customer improved.
Improvement of internal tools
This was an unexpected but welcome outcome that resulted from the initiative. We found that engineers easily recognized small fixes to the internal tools that would lead to big improvements to the processes the CS agents had to follow. One example of this was normalizing tracking numbers. This meant that CS agents no longer had to capitalize long tracking numbers or remove characters like dashes by hand. Although it was a trivial task for the engineer, it was a major improvement for the CS agents, who were therefore able to save time and provide an improved experience to the customer.
Challenges
I think it is also worth mentioning possible challenges that could be encountered when trying to get the initiative off the ground. One challenge is to ensure that the engineers and CS agents understand the benefits of the initiative. It’s important to keep in mind that you are asking people to do something that they might not feel comfortable doing.
Briefing the pair before the day is vitally important to ensure that when they work together, they both take into account the level of expertise that their partner might have on the relevant topics. Another challenge, depending on team size, is the frequency at which an individual would have a Swapping Friday. If it happens too often, then the time investment starts to yield a lower payoff in terms of benefits gained for time invested. If they are too far apart, then it could become a novel event people forget about after a while. At Shutl, the frequency sits around once every 3 to 4 months for each individual. So far this has worked for us.
Conclusion
Overall, Swapping Fridays has been a success. The benefits that have come from the initiative unquestionably outweigh the time investment required. A special thanks needs to be made to the engineering and CS management for their willingness and encouragement to get the initiative going. It is really great to work with management that openly embraces changes to try to improve the experience for customers. I would encourage any company to give the initiative a go if they are looking to improve engineer/CS relations and improve the experience they are able to provide to the end customer.