Problem Statement

When you send or receive a parcel, whether you're an individual or a business, you will care about the status of the parcel, since when it leaves the origin until it has reached its destination.

Tracking shipments is naturally an essential feature for Packlink's users. Despite this, Packlink's tracking is quite basic.

tracking on B2C Public tracking on packlink.es
tracking on B2B Tracking on pro.packlink.es

A deficient tracking system

Besides layout, the Packlink tracking system has some inherent issues:

  • it doesn't answer the main question users have - 'Is there anything wrong with my shipment?'
  • it doesn't alert users when they need to take action
  • the wording of statuses is confusing and full of jargon
  • the mapping between carrier statuses and the five Packlink PRO statuses is many times wrong (a shipment in transit could be shown as 'delivered’)

This adds up to one of Packlink's main pain points - if the tracking is unreliable, when the inevitable shipping issues occur, the users are burdened with all the responsibility:

  • they have to actively follow the tracking of each of their shipments - which is especially laborious for merchants with large volumes of packages
  • they have to understand what the statuses mean, even if they contain jargon - for example, one Correos status only says: 'alm regulador'
  • they have to know what action to take in each situation - which means more tickets to the Customer Support department
Escalating Issues

What usually happens is that users are not aware of this responsibility, and when things go wrong, it's too late to fix them, so the issues escalate.The Customer Support (CS) department is flooded with tickets about topics that could be easily fixed by a better system.

Losing Business

This affects the business and company image. After a client encountered her first issue, she starts being disgruntled with Packlink's service. With every new issue, clients become more frustrated, until eventually, the unlucky ones who encountered too many issues stop using the product.

High Expectations

Customers have higher expectations about today's services. Merchants are used to the current offering level from other service providers they use: carriers, marketplaces, e-commerce platforms, hotels, transportation, social media, etc. They know Packlink could do better.

Diving into the mess

No one ever said ‘shipping is easy', and there's a good reason for that. Tracking is the perfect example of how this industry has become the complicated monster it is today. Each carrier has its own tracking system - its own collection of statuses for all possible events.

On average, each carrier Packlink provides has about 220 statuses. Some have over 600, while others have 20. Packlink needs to show the status of a shipment, despite the carrier, but its own tracking system doesn't allow much variation.

Enter Information Architecture

The obvious candidate to solve this mess was Information Architecture methodology. My plan was to build a Packlink Tracking System - a system that would incorporate all the integrated carriers. I had to understand requirements of over 40 tracking systems, from different types of carriers: domestic (Correos, Poste Italiane), international (TNT, UPS, DHL), dropoff-focused (Mondial Relay).

Sketch of how the tracking would work

To design a proper system I had to immerse myself in the subject. As I knew little about tracking, I decided to tap into the vast pool of knowledge from inside the company - more than 30 CS agents that deal on a daily basis with issues, tracking, carriers and merchants.

The Plan

  1. Assess the current state of by defining the base KPIs
  2. Learn from experts (CS agents) about different carrier tracking systems through a card sorting study
  3. Explore different solutions by building an MVP tracking system
  4. Define system architecture with back-end devs
  5. Define a vocabulary for the system, including words 'not to use’
  6. Verify MVP with experts - make changes, rewordings, reclassification
  7. Formulate and translate the statuses into the four languages (with experts from CS)
  8. Test the architecture with real users, with a hybrid card sort online exercise to assess the clarity of the wording and relevance of the statuses
  9. Refine the system based on user and expert input
  10. Prototype the tracking of different shipments inside the platform (use real shipments)
  11. Test the prototype with users in a usability study

As I haven't built a system before, I got inspiration and guidance from following Abby Covert's amazing guide: Easy to read and clear, this book is one of the best primers in IA How to make sense of any mess.

1. Assess the current state of by defining the base KPIs

Early on, this project emerged an immense effort. So to advocate it to management I decided to speak their language - Key Performance Indicators (KPIs). Defining KPIs too late was also a mistake I had done before, with the result that I couldn't assess the state of the product before the change.

Project Goals

  1. Reduce the number of Customer Support tickets related to shipments in transit

    Insight: about 50% of all CS tickets could be positively affected, such as the ones related to collections, deliveries, escalations of issues to carriers, questions about tracking statuses, inquires about damage or loss, and customs.
    KPI: number of CS tickets

  2. Increase customer satisfaction by improving the post-booking shipping experience

    Insight: 'up to date tracking' was the second most requested feature in the NPS survey comments
    KPI: NPS score

  3. Simplify and automate internal processes related to solving shipping issues

    Insight: The process for dealing with issues implies many actors to take responsibility and too many exchanges between them in case of an issue (e.g. carrier → client → CS agent → client → recipient → client → CS agent → carrier)
    KPI: average number of emails needed to solve one issue

  4. Reduce churn

    Insight: according to a survey, around 20% of clients who churned, did it because the software wasn't reliable enough (this includes both tracking and booking issues)
    KPI: churn rate

2. Learn from experts through a card sorting study

To consider the different types of systems the Packlink tracking system would have to accommodate, I planned multiple open card sorting studies. In each study participants would sort all the statuses of one carrier as they see fit.

In the end, I conducted three studies:

  • one with 82 (out of 82) statuses from Correos with 15 Spanish shipping experts
  • one with 120 (out of 570) statuses from Poste Italiane with 9 Italian shipping experts
  • one with 88 (out of 93) statuses from DPD with 5 German shipping experts
tracking on B2C
tracking on B2B

To print the statuses and analyse the data I used the Check out OptimalSort here card orting tool of Optimal Workshop. For the analysis, I followed the recommendations of a Read full paper here paper on Card Sort Analysis Best Practices.

With every participant, I learned something new about the messy world of tracking. It seemed as if carriers themselves never looked back at their statuses, to build a coherent structure. One status could mean multiple things, and multiple statuses could describe the same situation.

It all became very interesting when I realised how many ways there were of categorising these statuses. So, to investigate this further, I categorised the participants's categorisations - what factors did consider important to distinguish one category from another?

Figuring out which types of categoisations were used the most

categorisations

Besides the obvious factors: shipping process, issue or normal status, three variables stood out as highly significant to the user experience, but often missing from tracking systems:

  • if the status requires an action or not
  • if yes, who is supposed to take the action (responsability)
  • relevance to the user (for example, some carrier logistics normal statuses are not very relevant)

That's when I realised that the system didn't have to be, as I initially thought, a strict hierarchy, but should be heterarchical. Each status would be defined by several variables.

3. Explore solutions by building an MVP tracking system

While analysing the first card sorting study, I built a first draft of the system. It took a lot of iteration and definition to come to the first version of what a status should be like.

tracking iteration tracking iteration tracking iteration

This is when I realised the potential impact of this work. It was probably the only classification of tracking statuses that was built to accommodate multiple carriers, with insights from experts, and with Information Architecture methodologies. It would be the only tracking system that:

  • would have clear descriptions, devoid of jargon
  • would clearly indicate the relevance of a status to a sender
  • would give clear instructions on what to do next, and who is responsible

How statuses would be oranised

tracking mvp

Flow of information in case of an incorrect address

tracking mvp
A project involving everyone

It came naturally to involve the Customer Support department in this project. They had been advocating for years for a better tracking system. After participating in the card sorting study, the CS agents gained respect for design methods and were excited about the unfolding of the project. They appreciated that someone took their years of expertise into account, instead of going head-first into building something.

I realised the importance of involving my colleagues in my work, after the Read more about how personas failed to get integrated into the company culture failure of the personas. So I initiated casual corridor chats about what I was working on and blatantly covered my wall with some of my colourful brainstorm materials.

pictures on the wall

4. Define system architecture with back-end devs

As I got more into the definition of the system architecture, it was time to involve another vital department - the developers. I started with informal brain pickings, in which I probed if the structure I was experimenting with would make sense from a technical perspective.

5. Define a vocabulary for the system

The wording was the most vital part of this project. Without proper wording, the tracking system would be the same as any other system. The instructions had to be clear for anyone, be it a shipping expert or a beginner.

To be aware of all the words to use, and especially about which ones we shouldn't use, I made an audit of the interface vocabulary

pictures on the wall

I realised that inconsistencies about vocabulary pestered the entire company, each department had different definitions.

I asked different people in the company how do they name different user types

Product understanding of different types of users Product understanding of different types of users
CS understanding of different types of users CS understanding of different types of users
Sales understanding of different types of users Sales understanding of different types of users

The end.

Unfortunately, this project came to an abrupt end. Even if it had grass-roots support inside the company, the leadership of the company decided to halt it, so they could focus on operations initiatives.

At that time, I was concomitantly working on all the five tasks described above.

Learnings

You would wonder, dear reader, why would I add such an unfinished project in my portfolio?

It is because this is the most massive initiative I've ever taken. It involved an insane amount of work, both done and planned. It has taught me about information architecture, service design, system design, and company internal politics.

I took great pride in my work, and I wanted to see it done, as I could feel it had great potential. But even tho the work was never completed, I have personally learned valuable lessons:

  • how to structure a massive project
  • how to gain grass-roots support inside a company
  • how to involve multiple departments in a project
  • how to own my initiatives
  • how to defend my work and argue for my methods
  • how to deal with losing an enormous amount of work