Tasks: A Paradigm Shift

There comes a time in each company's evolution when the limitations of its internal processes and tools become a substantial barrier to scaling up. This happened in Ontruck when the shipping volume suddenly arose one summer, and it hit us like a tsunami. Angry calls and emails flooded from all sides. Little was under control.

Two years later, the Summer Peak Panic of '19 has become a legend at Ontruck. The processes and tools that the Customer Service team uses to handle issues are a world away from what they used to be. We have achieved radical progress through building a scalable system. To do that, we had to break the day-to-day incremental progress cycle and innovate by exploring unknown territory.

Incremental improvements which stay at the basis of the Lean development methodology are the main drivers of advances within a dominant paradigm. But once in a while, the base that we incrementally upgrade proves to be limited. We need a revolution, a paradigm shift. That is the only one that can bring radical progress.

This is the story of how we have re-invented the traditional in-transit logistics management system. I will explore how we deliberately suspended the lean development cycle to make space for a Vision-led paradigm shift and how we got back on track after it.

How we achieved radical progress and major paradigm shift in 5 steps:

1. 🔍 Understand limitations of the existing system
2. 🧪 Test a hypothesis (with a proof-of-concept working prototype)
3. 🌟 Define the Vision
4. 🛠️ Implement the MVP and measure it
5. 👣 Slide back into the incremental improvements approach

1. 🔍 Understand limitations of the existing system

It doesn't make sense to invest significant time and effort to re-think and re-build from scratch if we can still improve the system's core. Radical progress is costly, and it's the last resort when all else has failed. Thus it is crucial to identify why the current system is not scaling up. Are the barriers truly unsurmountable?

What every other logistics company does

In most logistics companies, the traditional incidents management tool is a list of all in-transit shipments with filters. Customer Service agents are scrolling up and down this list, in search of the most urgent issue to solve next. And for years, we took the shipments list for granted. It was the way. Our main challenges were improving the list, detecting potential incidents, or making the filters more effective.

Shortcomings embedded in the 'shipments list with filters' model

Eventually, the following 4 embedded aspects of the traditional logistics in-transit model (the list) were the hard limits that we couldn't fix through the normal iterations process:

1. Getting distracted by unproblematic shipments. The traditional list shows every shipment in the system, and it is up to the Customer Service (CS) agent to filter out the ones without issues.
   From experiments, we knew that some CS agents felt more in control by keeping an eye on the shipments without issues (i.e. not filtering them out), "just in case". This behaviour created a lack of focus.
2. Identifying the most urgent issue is up to the human. It is straightforward for a CS agent to check all shipments and determine the most critical incident in a shortlist. Yet, it is impossible to assess correctly within a long list of items.
   Applying consistent rules to calculate urgency is a problem naturally solved better by computers. In a classic in-transit system, agents will solve issues in the incorrect urgency order.
3. No required division of labour. Although an ownership process was in place — a specific agent takes care of a set of shipments, the system didn't enforce it.
   An agent had to use a filter to comply with the ownership system, but filtering out made some feel like losing control. Clients and drivers complained that they had to explain the same issue to several people. The consequence became a low service level.
4. Many sources of workload. Besides the list of shipments to monitor, the agents also had four more channels to pay attention to — calls, emails, chats, and requests from colleagues.
   Although a request from a colleague from Sales could have a lower priority than a system alert, the need to answer a friend is stronger. The many sources incentivise biased prioritisation.

The team was asking for more and better filters, more screens, smaller font size to fit more info onto the screen. The users were asking for 'faster horses', not even imagining what a car would work like.

An idea is born

During the volume peak, many of us from Product and Tech rolled up our sleeves and helped our Operations colleagues with their workload. This hands-on experience sparked new ideas on the kind of systems that we could build to support the Customer Service team.

The concept of a task-based system rather than a list of shipments started floating around. It wasn't clear yet what a task would be and how would the system work, but it had to account for the shortcomings of the traditional system. We can't disrupt logistics using the same tools as traditional companies — we must re-invent.

2. 🧑‍🔬 Test a hypothesis

After identifying a direction for the new system, it is time to explore the solutions space. Refactoring and redesigning are expensive, and cheaply validating any high-level hypothesis is critical. There are several alternatives, depending on the type of product. User testing with an interactive prototype is the most common. But when possible, launching a working prototype 'in the wild' is the most effective way to validate its effectiveness.

Gathering empirical evidence

There's no better way to explore a new idea than to 'fake' it with a working Minimum Viable Product (MVP) Test. We could even consider it as the first iteration of the Build-Measure-Learn cycle. Radical progress can still reap the benefits of lean development.

In our case, this first build was, in fact, a working prototype that allowed us to explore the idea. It took about a week to build and release it, and it was in fact the old list, but with a make-over. Each object was still a shipment, but the focus was on its ongoing issue. The list was pre-filtered, excluding non-problematic shipments.

We built this MVP Test to co-exist with the traditional list-based system within the same internal management tool. We didn't aim to replace the old system but to learn and measure.

Would this MVP test bring enough value to our users that they would start using it voluntarily?

We measured the usage of the two alternatives: the original list and the 'tasks'. Navigation data showed increased use of the smoke test and correlating decrease in the list usage. User interviews and observations made it clear that the new 'tasks' system was valuable even with limited functionality — it brought more focus on what needed solving.

3. 🌟 Define the Vision

Any significant undertaking needs a vision — a north star of what it could be. We often overlook the Vision in the product development world to focus on more tactical affairs. But when aiming at radical improvement, advancing in an established direction keeps progress on track. As with any long-term project, it isn't enough to define where you want to be in the far future. Mid-term goals are fundamental to keep us grounded.

We had a vision. The task-based system would be uniquely efficient and easy to learn. It would achieve two goals:

1. Best service levels: By identifying the most relevant issue to solve next, we provide high-grade service and prevent future problems.
2. Real automation: We can automate more effectively by converting the unstructured work CS does into Standard Operating Procedures.

The key idea of the Tasks-based system vision was the transition from a chaotic system to one where atomic tasks make up the workload of the entire CS department. The aim was to reach the level of discreteness where subtasks are automated, and CS agents only spend time in the high-value work that requires a human touch.

Essential parts of the Vision document were the KPIs we needed to measure this project's success. There were KPIs for team productivity such as 'Tasks / Agent / Day' or 'Time to solve a task'. We also defined KPIs that would measure how close we are to achieving the North star, such as 'Workload covered by tasks', 'Shipments with no tasks', and 'Automated tasks/Total tasks'.

4. 🛠️ Implement the MVP and measure it

After all the strategic exploration of the Problem and Solution spaces, it is time to build. The challenge is defining the Minimum Viable Product. At this point, the MVP doesn't need to be the game-changer that the final implementation of the Vision would be; it only needs to display a clear improvement in the main KPIs and be a solid basis for improvement.

Going back to our original anomalies, this is how the new tasks system would address them:

1. The smallest unit is the incident, not the shipment. Therefore no problem-free shipments are ever on the radar of the agent. Addressing this problem in the MVP brought enough value to the user to make the system worth it.
2. A prioritisation system calculates the order of tasks. The algorithm considers the number of tasks a shipment has, the task type, the time the task has waited unattended, etc. The MVP had a simplified version.
3. Task ownership is an integral part of the system. CS Agents can't see their colleague's workload. Removing the permissions in the old system would have created a small uprising, but not including it in the new system was just the 'default' in the MVP.
4. The Tasks System is the primary source of workload. The MVP only included shipment-related tasks, but we built it to integrate other workload sources easily. A task became a vessel for chats, emails, chores from colleagues, incidents reports, etc.

Tasks ended up completely changing the way the Customer Service team worked. At first, the move met some resistance, but the advantages soon outshined change aversion.

Comparing the two systems helped us validate the direction as the correct one. In the beginning, however, we identified some measurement traps. Releasing an MVP meant that as we added more types of tasks, some KPIs that would typically need to decrease to show improvement (e.g. 'Tasks/Shipment') would actually increase as a result of improving the system.

5. 👣 Slide back into the incremental improvements approach

When the paradigm shift is validated as the best direction, it is time to switch to incremental improvements. The next few steps are clear: implementing what was left out of the MVP and the changes that emerged from evaluating the MVP. We slowly but surely get back into business as usual lean development cycles — until the current paradigm breaks.

Over the past year and a half since the first implementation of the tasks system, we have added 9 different types of tasks and several advanced functionalities (such as an availability system to account for user shifts). The Vision document continued to be a beacon and guide us in the right direction.

Establishing New Frontiers

The task-based system has become the new standard at Ontruck. As main KPIs showed, the new system allowed the CS team to keep the service level under control, even during peak volume seasons. It also proved scalable when it effortlessly accommodated a strategic pivot the company did, unlike many older parts of the system, that required extensive refactoring. Moreover, the new system is easier to teach to new employees. The progress was radical.

We couldn't have reached the same results incrementally iterating the old system. Every system has its limits, and it's essential to recognise them and act in time. Paradigm shifts are not effortless endeavours to undertake, but their outcomes can be truly game-changing. Thus, the next time you recognise the opportunity to innovate, make sure you're ready to take the plunge.