The workday of a Customer Service agent in logistics is a never-ending battle against time. There are calls from clients and drivers on-site, all demanding their issues to be solved now. There's a transport system to manage that alerts of delays and other incidents in transit. There are emails too. On top of that, colleagues from other teams ask for favours or help through slack and over the shoulder. It is a non-stop flood of to-dos.
A significant part of the Customer Service agent's day is spent deciding what to solve next.
When faced with too many options at once, anyone can experience Choice Overload. Would Eddy's decision be correct?
At Ontruck, we often face challenges that imply a drastic change in how an Operations team works. It sometimes turns out thriving, with full adoption of the new technology or process. Other times it becomes just a forgotten and deprecated legacy project that was likely never really used. This is the story of a successful implementation, and what we learned was the key ingredient.
I. How to Define the Right Solution
The volume of business was growing fast and so was the Customer Service Team. The 13 agents of the Spanish team were all doing a similar job but with a different geographical focus. To scale significantly, the amount of work an agent would do needed to almost double. Consequently, the Chief Operating Officer asked the Customer Service team lead to improve performance.
As a sensible designer, always in contact with stakeholders and users, I found a long-awaited opportunity to help them with more than just interfaces. It was time to apply some of the fascinating Service Design methods I've been reading about.
I prepared and facilitated three co-creation workshops. In the first one, we classified several of the team's tasks across relevant variables and then detected some clusters. In the second workshop, we defined the roles we found through clustering tasks in detail, and in the last one, we stress-tested the definitions.
Workshop I: Tasks classification
Scope: Map all existing Customer Service (CS) jobs. Find clusters and patterns.
Preparation: To not waste time remembering what jobs the team does during the workshop, we gathered a list of around 30 jobs and printed each on one paper card. The initial collection also set the tone for the level of detail of a 'job' definition. This selection of jobs was a result of prior observations and vetted by the CS team lead.
Participants: the CS lead, one senior CS agent, one Engineer, one Product Manager, and two Designers (one to facilitate and one to participate)
Duration: 3h
Activities:
- first, we ordered the list of jobs from left to right (the X-axis) on the table, with urgency in mind (most urgent on the right)
- then we added another variable (on the Y-axis): business impact — how relevant is this job for the well-functioning of the business
- we then categorised each job according to its complexity to do, by colour coding (with circular post-its)
- Lastly, we undertook the most challenging task — finding meaningful clusters.
Visualisation of the different tasks of the workshop
Results: Several clusters emerged out of the mapping process:
- Front line duties with high urgency and high business impact, such as dealing with priority clients (Level 1)
- Complex tasks that require follow-up and have a medium urgency, such as solving and preventing in-transit incidents (Level 2)
- Straight-forward tasks agents need to do at specific times in the day, such as closing the day's incidents (Level 3)
- Complex, non-urgent jobs with high business impact. These jobs were already done by one specialised agent, which reinforced that we were on the right track (Level 4)
Workshop II: Defining roles
Scope: Define the details of each role
Preparation: To make the best of the workshop time, we extracted data on the distribution of main activities during a workday, such as how many phone calls a minute we usually receive. We overlapped this with the different shifts of the agents within the team.
Participants: the same as in the first workshop; We decided not to change the team for continuity.
Duration: 3h
Activities:
- Define what jobs each role is responsible for
- Who would do it?
- When should the team cover different roles?
- Where would they be spending the time (in terms of tools)?
- Why does the role exists?
- How can we get everything prepared for that role to start working?
Results: We reached broad definitions of the scope of each role. We agreed that agents would change roles depending on the need, and we clarified when each role should be covered and by how many agents.
Workshop III: Stress testing simulations
Scope: Make sure that the current structure makes sense when we consider complex situations
Participants: one CS agent and the facilitator (designer)
Duration: 2h with three different agents
Activities: Exploring flow maps of different jobs and how a team divided into the new roles would tackle them.
Results: This last polishing touch allowed us to involve more CS agents and refine the initial definitions. We also defined simple escalation and de-escalation rules.
II. How to Get It Approved
The Product team and the CS lead have defined and agreed on the re-org, yet the project is far from being done. Such a change requires time and effort, such as adapting all the tools CS uses (call central, ticketing system, and logistics management tool). It also needed buy-in from upper management, but most of all adoption by the team itself.
Thus, as any self-respecting Service Designer would do, the next thing on the list was a keynote on the results of our work to sell it to upper management. To bring the point home and get everyone excited about it we also gave it a shiny new package: ⚔️ TEAM WARRIORS ⚔️.
The branding worked, and we got not only a highly enthusiastic COO supporter but also help from the marketing team to design logos and t-shirts for the different roles. More importantly, the Customer Service team became enthusiastic about the change to come and fully committed to it.
III. How to Implement It
In Ontruck, being Lean is the way. So a pilot with a few agents during non-peak hours for two weeks was the next logical step for the team. Thematically called The Scouts, this pilot helped us understand what worked and what didn't. We made several minor adjustments in this time and ran training sessions with the rest of the team.
Challenges and their solutions
- Reluctance to change and the effort it takes. What helped was having the team lead as part of the early definition. He became the driving force of the implementation.
- Level 1 (Chivalry) required agents to be almost constantly on the phone, which is highly stressful. What helped was being flexible with changing roles during the day if fatigue ensued.
- Escalation rules between roles was an unfamiliar task; thus, some felt it was easier to do a job than move it to someone else. What helped was being less strict on the boundaries between roles.
IV. Results
Interviewing and observing the team several months into the new model, they admitted that it's much easier to focus and felt more in control of the day-to-day. The CS team kept and iterated by themselves on the levels model for a whole year, with no more support from the Product team. They eventually changed it when the team split in two for strategic reasons. The three-level organisation didn't make sense anymore, without enough overlapping shifts.
Although we expected to see great things in our main KPIs related to CS, there were no noticeable changes when the re-org was fully implemented. My main explanation for it is that the KPIs we looked at were not meaningfully measuring the team's productivity but were more reflections on external factors. But, it could also be that the change increased the team's focus but not necessarily its productivity.
V. Epilogue
The key takeaway for me is going back to the difference between a successful implementation of an extensive process change and a failed one. As designers, we often think we know best how to solve problems through Design Thinking methods that put order into chaos. We often preach about co-creation and involving the user from the get-go. Yet, in reality, we base decisions on user interviews and corporate brainstorming sessions.
In a classic ivory tower approach, the new shiny ✨Team Warriors✨ idea would have stayed an idea. The trick was that it was never my idea in the first place. I only provided the structure for the Customer Service team to design their own internal organisation.