Package Research Tool
Pitney Bowes
Overview
The package research tool provides a central place for the customer support team to track packages and get a complete view of a package's details.
Results
- Decreased response times for customer support inquires
- Unified 5 tools into 1
- Streamlined repetitive tasks
Problems
- “Where is my package?” is the number one support request from clients.
- The team had 5+ systems for finding various tracking information that were painfully slow and difficult to use.
- Many requests are for anywhere from 1 to 100,000 packages at a time.
- The customer support team has to be careful about how much information can be revealed to clients, because they use two levels of tracking detail and the extra information can often confuse clients.
User Needs
- A centralized place to track packages.
- Ability to track packages up and down the container hierarchy (BOL > container > package).
- Summary of large data sets containing tracking results.
- Simplified method to share results with client.
- A view of the information clients are seeing and the extra details available to internal teams.
Working Through Each Design Challenge
Viewing tracking events and their details
The latest tracking status is the most important information, but it's not always trustworthy. Clients are often asking about the package because the current status is different than their expectation. As a result the support team often has to look into past events and cross-reference multiple sources to determine if the latest event is trustworthy.
To fully understand the problem users often ask themselves the following questions:
- When did the event happen?
- Where was the package?
- Who had custody of the package at the time?
- Is the event a problem? If so, what kind of problem?
- How was the event triggered? Was it a physical scan of the package?
- What container was the package in at the time?
That's a lot of data to distill into one view, and it wasn't immediately clear how important some of it was. In times of uncertainty the best thing to do is ask the users. I created a few different concepts and presented them to users to help choose a direction. After talking to the users I better understood their hierarchy of needs, which the timeline concept best addressed.
(Winner for data density and hierarchy)
Tracking THOUSANDS of packages at once
Often times clients would send lists of packages where only 10% of them had any issues. Most of the time they were just looking for a status update. The customer support team needed a tool to help them weed though the noise and track down problems. Their previous methods used Excel to filter and create pivot tables. Our goal was to automate as much as possible.
Bulk tracking results
- Summary counts of the search results.
- Comprehensive filters to find any problem indicators.
- Counts next to filters to act as pivot table totals.
- Quick filters to detect common types of issues with one click.
- Simple export for sharing with clients.
Getting the full picture
Identifying problems with tracking was the most important thing for users. This can come in many forms and often requires cross-referencing several data points. The package details page was designed to make issues obvious at a glance.
Package details page
- Map view to check if a package is going in circles and compare the actual path of a package to the ideal path.
- The latest tracking status from two systems to help cross-reference and check for accuracy.
- Tracking events from multiple systems and at multiple levels of detail.
- Package attributes and the latest information on the right.
Results
The customer support team highly valued the end result, which significantly reduced the amount of time they spent researching packages.
