PackageX.jpg

PackageX

Case Study

5 minute read

Problem

Worldwide e-commerce retail sales hit an all-time high in 2018, surpassing the former years. Consequently, package delivery has mirrored that trend. Although the numbers are staggering but none of that should surprise anyone, as we live in an increasingly more connected world where many of us can receive a package mere hours after clicking “Buy Now.” It’s not just residential homes that are getting more deliveries – businesses are buying and receiving more goods as well. Businesses have a new bottleneck with which to contend: package inflow. As couriers bring packages into the large buildings, it is taking longer for mailrooms to correctly and efficiently take care of these packages. In our team, we found that this was an issue in both residential and office buildings as a courier like FedEx would notify us that a package has arrived while our internal mailroom was unable to sort the packages in time; often it would take over 24 hours for a package to crawl its way through the clutter of a mailroom into our hands.

Process

Our general product development process at VisionX remains quite consistent for each project. Followed by the identification of a problem, we always begin with researching to understand the market. We then synthesize our results and carve out an action plan. Next, we prototype & design. There are times when everything seems to be clicking right away and we get to the final product quickly but many a time coming up with a solution takes several attempts as we never compromise on the quality and efficiency of our products. Lastly, we evaluate our prototypes with user tests.

Research

We decided that our local co-working space could use an upgrade to the existing package handling solution. We convinced them to allow us to use one building to make a POC. Their current solution was labor intensive and involved manual data entry – which explained the long wait times for our parcels. Leveraging our strengths at VisionX, we knew that if we could automate the manual data entry, we would have a winning formula. Easier said than done? Of course. While our designers would begin learning about the best practices for our MVP product (coworking spaces), our development team would begin creating our algorithms for reading package labels.

Our research was really split into three categories. First, we wanted to look at other competitors on the market. We certainly knew that the product we were making was revolutionary, but we also knew that we would learn from others attempts. Second, we needed to research about the makeup of package labels. If we were going to automate reading them, we needed to know what every single element on that label was for. Lastly, and most important: primary research- we needed to talk to a lot of users. We needed to learn how a package mailroom actually works and what would make an associate’s job easier. What currently works and what could be improved. Moreover, we needed to speak with the members of the co-working space, the end receiver of the packages, and learn about what they needed and wanted. These users were primarily businesses and at least some of the said businesses lived and breathed based on the timely arrival of their packages.

Synthesize

Our development team quickly learned that the barcodes are often proprietary and did not have too much identifying information. We could pull the tracking number from them, but we could not identify the actual person or business on the label. This was an interesting learning experiment for us because we found out that come packages have identifying information buried in the random numbers: for example, Amazon includes the user’s phone number on it. That would be used as identifying information – if we have the customer’s phone number. In addition, different countries and languages have their own standards for package labels and cultural norms for nicknames.

We gathered over 100 unique and critical pieces of information from the mailroom associates and left an open channel. As expected, speed was very important – but not as important as we initially hypothesized. In fact, multitasking was far and way more important. There is no point of scanning in 50 packages, and then stuff them on a shelf and not be able to efficiently retrieve them when the customer comes down. Doubling down on multitasking was crucial as often after a FedEx notification, a customer would rush down to the mailroom to grab their parcels – for them it was understandably mission critical. We needed to allow for packages to be logged and picked up right there on the spot.

The co-working space’s customers also had requests. Many of these were businesses that wanted to understand which packages were actually delivered. Out of the 20 items they were expecting, is this one mission critical or is this Jamie’s personal phone case? Also, it would be great if Jamie was able to grab some of his colleagues’ packages too if he was already down there. Unless the package is ‘Confidential’ a friend or a colleague should be able to pick it up.

We quickly learned that there would be many permutations and combinations – many of which would be unique for each business. This app needed to be flexible and, in time, cater to many use cases in multiple industries. Our MVP was for co-working spaces, but the product’s potential usability in residential communities, schools, etc. were always in mind and we did not want to restrict ourselves to a certain industry.

Prototype & Design

While our designers were busy coming up and testing our designs, we hacked together a quick working prototype.

While a very simple design, our goal was to use this to scan as many packages as possible to check our accuracy for reading the names from the labels. Obviously, this whole process is about iterative improvements which is when we discovered just exactly how many people use nicknames on their packages. Since this was essential to keeping our scan accuracy high, we knew that nickname recognition would be crucial, so we decided to simultaneously deal with custom nicknames behind the scenes.

By the time our algorithms were working with high confidence, our designers had wireframed and tested designs with the mailroom associates, we had created a mobile application that focused on multitasking while also working faster than anything on the market. We also learned from management that auditing was not just nice to have but crucial for their long-term vision and unfortunately not a tool they had before. In order to make the system self-sufficient, we created a backend dashboard that would allow for the management of packages, customers, employees, buildings, and mailrooms. We also designed concise emails that would alert the user about the tracking number and sender details while also sending an image of the package label for instant transparency into their package.

Results

We are happy to admit that the co-working company we tested with was WeWork and now we are live in all of their locations globally. Their per package intake is now down to seconds from scan time to the time a customer receives a notification. Our next challenge was not only to bring PackageX to different customers, but to customers all around the world. We are stoked that PackageX is now available in 57 languages and is used in over 28 countries.

Conclusion

After incubating PackageX, it is not a stand-alone company. As a passionate team, we’ve learned a lot regarding what it’s like to build such a customizable product. Through this journey, we have gained expertise in logistics management and effective analytical backends. Our natural language processing engines are world class and waiting to be applied elsewhere. We also (and obviously) know way too much about the makeup of package labels – for better or for worse.

Previous Post