Exception Handling

Summary

For my first 6 months at Veho I was focused on creating an end-to-end chain of custody program that allowed Veho to properly accept and transport packages between middle mile facilities, all while providing at-a-glance dashboards for quick triaging and information gathering. As a part of the ongoing efforts to modernize Veho’s Internal Ground Operations space, the next step after establishing a full chain of custody program was solving the largest ask from our Ground Ops users; to make triaging and handling package exceptions simpler. The exception handling flow was thought of in order to provide a quick approachable way to triage packages in a tool they all already had access to – the Facility Mobile App.

Problem Solving & Exception Handling

Getting the right data for ourselves and our clients while taking the load off of burdened staff.

About the Project

As part of Veho’s continuous initiative to modernize its Internal Ground Operations area, the focus shifted to addressing the primary request from our Ground Ops users after implementing a comprehensive chain of custody program. The goal was to streamline the process of triaging and managing package exceptions. The design of the exception handling flow aimed to offer a convenient and efficient method for users to quickly address package issues within a tool that was already accessible to all.

The Problem

Exception handling at Veho initially faced challenges due to a manual process reliant on anecdotal information. This approach led to return issues with clients, putting volume at risk. Moreover, the gig-style delivery system resulted in a lot of packages returned without clear reasons, as the consumer-facing app lacked the capability to mark return reasons. Abandoned or damaged packages further complicated matters, with no evident explanation for their condition.

A significant problem arose with misreporting, as the default reason for return in the Facility Mobile App was labeled “Access Issues,” causing a misleading 75% of packages being attributed to access problems when there were none. For example, during peak operations (Black Friday – New Years) Veho hit over 900,000 packages delivered per week, even at 1% abandonded or otherwise returned packages would net us around 9,000 packages that would need a return reason, and over 6,000 of those were getting returned with the reason of “Access Issues”. Obviously something is wrong with the data being presented here. The Exception Handling flow sought to streamline the triaging process by transforming the inconsistent process into an accessible, user-friendly wizard. This tool would guide users through a series of questions based on client SLA’s and package perishability, ensuring the correct application of metadata and providing clear next steps on what to do with the package for ground ops users.

Project data indicated 13 manual package events, each requiring the user to know the specific reason for refusal or return, and some of those 13 events had up to 12 sub-reasons. With this original process, the average time to triage one package stood at approximately 8 minutes, encompassing support notifications, package event application, backend system updates, and package handling, which typically involved discarding or preparing to return the package to the client.

---

The Solution

Intro

Due to limited engineering resources, an incremental delivery approach was adopted. This approach presented challenges, especially considering the diverse avenues for exception handling and the absence of prior experience in implementing complex UI interactions within the Facility Mobile App.

This project was successful thanks to an amazing combined cross-functional team of 1 Designer, 1 Product Manager, and 3 Software Engineers. This solution and all solutions done for the Facilities Mobile App (FMA) were done for Android using React Native Base components on Zebra TC21 & TC22 scanning devices. This is an internal application only available on Veho devices. The following pipeline of programs were used for successful collaboration.

• AppCenter (via Slack) – QA spot-checks of in-flight builds
• Figma – Design tool & asset library
• Figjam – User Journeys & Flows
• Linear – Epics, stories, task tracking, etc
• Notion – Wiki & decision tracking

---

Process

Discovery & Definition

We started with trying to understand the current world for exception handling. This was done through referencing Support conversations, user interviews, and documentation containing SOP’s regarding package exception handling. Then myself and my product manager, along with training staff, created an idealized pipeline based off client SLA’s and those SOP’s that Ground Ops accesses everyday. It ended up looking like this:

Obviously, that’s not a scalable approach if you want to deliver iterative value. So the next question is, “What’s the most important flow that we can start with?” We landed on the Damaged package flow, as we would need to create the flow twice anyways. Once, for a purely damaged package that was found by Ground Ops staff upon client injection or package processing, and another when a driver might return the package because it’s damaged in some way. With this we wanted to create a scalable framework by which we could approach all of the next flows coming down the pipeline.

Personas

Before all of this, as one of my first large projects at Veho I also created personas for all of Veho Ground Operations. Conducting interviews with over 20 different users in 7 different roles across different markets. After combining a couple of the roles and combing data taken from other shadows, usability studies, and interviews, we were able to create 5 lightweight, approachable personas. For this solution, we were mainly focusing on the Supervisor Sam, Larry the Lead, and Alexis the Associate roles.

Now we start designing

Working at a startup means working quickly, and delivering fast. This was going to be the next initiative taken on by engineering team, so that meant a quick turnaround time to get something started. I also had to get my design vetted by my design team, signed off on by stakeholders, and researched with users. All of this in roughly happening over the period of 2 weeks. That means getting something on the canvas for rapid feedback.

Luckily the Veho design team happened to have a great component library in place, so getting started after studying the user flow more was a fairly simple task.

Iterate

Knowing how to structure the data in a clear and concise way is always the challenge. Along with creating a more complex experience than is typically seen in the FMA, there was an opportunity to be more visual and also match towards newer Veho branding. The goal is to always see how we can raise the bar for our experiences and push in those elegant solutions.

Usability Sessions

Once landing on the final version we felt confident in testing with our Ground Ops users. Conducting 6 moderated interviews with a prototype, I asked users to perform a series of tasks regarding exception handling and tell me their thoughts regarding the process and the UI in general. I don’t call myself a researcher, but when you work at a startup on thin margins, you tend to wear a lot of hats.

Users really enjoyed the experience and stated that it would be a great addition to their tooling. Users stated that their current process is slow and manual, and if the app just told them what to do, then that would be a great step int he right direction. The great part about testing is that it surfaces issues. We surfaced some small friction points and captured great feedback and actionable data. Some of it included:

• Package info could be more prominent
• Iconography on top could be toned down
• Button to initiate exception handling was hard to find

Curious about the prototype? Try it out for yourself! Or just get a glimpse from the video below.

Results

• Reduced time to triage a package by 65% (~8 mins down to ~1 min)
• Improved SUS rating from users after release (65-70)
• Created a framework for exception handling for any package event

Next Steps

• Monitor for feedback and issues
• Explore solutions for displaying package info more elegantly
• Build out next largest flow, Returned to Veho (which also contains the Damaged Package flow)
• Observe user interacting with solution in warehouse
• Build out dashboard of Problem Solve containers in the Facility Management Console (Internal Desktop App)
  • Containers are entities that contain packages or other objects. With these different PS Containers, we can build a dashboard that allows visibility into all packages in certain package exception states.