When people think of Wayfair, they often think of the slick website, catchy TV ads, and personable customer service. They also obviously think of furniture. What they don’t think about, however, is how that furniture gets to the customer. Many people don’t realize that UPS and FedEx won’t bring a dresser or a dining table to their house. They also don’t realize that Wayfair actually maintains and operates a massive supply chain network of carriers, warehouses, and delivery agents that have to work perfectly in sync in order to get your couch to you by Friday. Superior delivery speed, reliability, and low costs are paramount to Wayfair’s success as a business, and these areas are the main concerns of my team, Transportation Engineering (TRNS).
On the TRNS team we are passionate about moving things and are constantly working on improving the capacity and throughput of our network in order to provide a better customer experience. This passion is what led me and four of my teammates to design and implement a transportation-focused project for this summer’s hackathon, WayfairHacks.
Transportation Scale at Wayfair
We think of scale very differently than a lot of other companies, and even very differently from other teams at Wayfair. While purely technical scaling is indeed important for our ability to function, we tend to care a lot more about the scale of our operations. Wayfair is a rapidly growing business and we need to be able to handle rapidly increasing order volume in our network. This requires constant thought and dedication to properly scaling our supply chain alongside its associated processes, tools, and workflows. If we don’t get this right, the customer experience suffers. A well-scaled supply chain will instead lead to lower costs, shorter delivery times, and better reliability for our customers (sound familiar?).
First Mile Pickups
The need for network scaling is nowhere more pressing than in our supplier pickups space; we call this “first mile” transportation as it is the first step to getting something into the network. About 90% of our “large parcel” (i.e. big and heavy items) volume goes through a process called “pooling”, where items are picked up from their supplier’s facilities and brought to the closest Wayfair facility. It looks something like this:
This process is accomplished across several “pool point” facilities in our network by a dedicated fleet of truck drivers, who pick up items from a large number suppliers. These drivers are managed by dispatchers who spend all day on the phone relaying information back and forth. The drivers need to be told where to go and what to pick up, and the dispatchers need to know what was actually picked up versus what wasn’t. This is actually pretty common in the trucking industry, but the problem becomes very apparent when you look at it through the context of operational scale.
When assessing our projected order volume increases over the next year, combined with the fact that new suppliers are added each day, we estimated that we’d have a more than 100% increase in drivers by the summer of 2019. That’s certainly too many drivers for our current number of dispatchers to manage over constant phone calls. It also worsens the visibility problems we currently experience. While we often intentionally (and valuably) start operations based on phone calls, emails, and Google Sheets so we can learn quickly and pivot when needed, this system becomes unsustainable at our scale and needs a creative, technical solution: Missed and unprioritized parcels would wreak havoc upon our overall network. We knew we had a problem coming, and we wanted to address it before it was too late.
Coming Up With a Solution
My team decided to enter the yearly summer hackathon with what we thought was an obvious solution to this problem: A mobile app for drivers in our fleet. We could use this app to push routes and stops to drivers and allow them to log their successful and unsuccessful pickups. Our immediate goal was for this app to cut out all phone calls related to standard driver workflows. Additionally, we wanted a way for our dispatchers to manage this process. We spent some time brainstorming both use cases and came up with a list of actions that need to be possible for each:
- Drivers need to be able to view their routes for the day
- Drivers need to be able to view information about each stop, including exactly which orders need to be picked up
- Drivers need to be able to mark an order as having been picked or not picked
- Drivers need to be able to mark any extra orders that were picked
- Dispatchers need to be able to view information about any driver, truck, stop, or order that they care about
The solution we came up with was two pronged: A mobile app we called “driveWay”, and an internal management tool. The app would handle everything a driver needed to do, and the internal tool would handle anything a dispatcher needed to do. They would both feed off of the same data and show the same information, in digestible ways, to two different user groups.
In the early phases we decided against a true mobile app and instead pivoted to a mobile website on our existing Extranet platform that is used by various third parties. This allowed us to begin work more rapidly since we were building on our existing Wayfair tech stack: A MSSQL database, PHP backend, and a React/Redux frontend. The dispatcher management tool was built in the same way.
Tenet 1: The User Comes First
A great user experience is extremely important to Wayfair, and we wanted to set this benchmark for our drivers as well. When whiteboarding our design ideas, we spent a great deal of time thinking about usability and intuitiveness.
For driveWay, the speed of usage was our highest priority. Drivers couldn’t take tons of time out of their day to log their data; it had to be something they could do quickly before hitting the road again. Because of this, we designed workflows that would minimize the amount of time they needed to perform the most common actions. Simple things like bulk actions and a flat page structure were two features we decided to implement early on.
For the dispatcher tool, information maximization was the biggest design decision. Dispatchers need to see as much information as possible in one view rather than being forced to click into things to see details. We called this an “at a glance” pattern, meaning dispatchers can understand what’s broadly happening across all drivers at a glance. This required many discussions about what data was most important, as well as the most intuitive ways to display it.
When creating a product or service that addresses a certain problem from scratch, I would highly recommend utilizing a similar whiteboarding system; it was incredibly valuable to have a reference point for everything we were building. It kept us on the same page and allowed us to work on things simultaneously without having to worry about duplicating work or breaking someone else’s code. It also gave us a cohesive direction and plan to work towards, meaning we didn’t have to stop and rethink things throughout the weekend.
Tenet 2: Data Drives Everything
TRNS cares a lot about data integrity and visibility, and our network health team needs to have detailed visibility into the status of each truck in the network. Because of this, we have an entire architecture around the concept of “milestones”. A milestone is exactly what it sounds like: A timestamped event related to a specific truck or stop. We have about 70 existing milestones in TRNS, but few of them are specific to the first mile space.
Data visibility was paramount to this project, so we knew we needed to add more milestones and build a lot of logic around milestone processing. For example, we have a milestone for a truck departing a stop. That’s easy enough on it’s own, but what happens when things don’t go as planned? What happens when a stop is skipped or cancelled? We need to be able to update adjacent and related milestones in these situations. We built a lot of logic into being able to cascade milestones through a given route. All of this allows the dispatcher to view the most accurate information about their trucks at any given time and gives them the data they need to make decisions and better resolve problem scenarios.
Building on top of milestone processing is the concept that current events affect future ones. When a driver marks an order as having not been picked, they must also log a reason why, and one of the possible reasons is “truck is full”. Intuitively, this means that no more orders can be picked up by said truck. To automate this, we built out logic that will automatically cancel future stops on the truck under these circumstances. This will trigger the removal of orders at the cancelled stops from the load that the driver is responsible for, allowing the dispatcher to either proactively reroute another truck to go to the missed locations, or re-prioritize the following day’s pickups to get the missed orders first.
Tenet 3: Data Should Be Easy
Data is cool and all, but it’s worthless unless its digestible. Remember: With our projected scale, this system will manage 200+ drivers within months, and will continue to scale quickly with our volume. Dispatchers don’t have the time to sift through data about that many trucks and 50 times that many orders. This project was set to give dispatchers a lot more data than they currently had access to, so we needed to give them a way to easily view it from a decision-making perspective. To this end, we came up with a custom React progress tracker component for our dispatcher management page:
This component allows our dispatchers to see information, at a glance, and quickly ascertain the status of any truck they are responsible for. Each icon represents one stop on a truck’s route. The icon’s color and the lines connecting the icons are all driven by the milestones I mentioned earlier. What’s more, we built this in a generic way that can apply to any vehicle in our network, not just pickup trucks. Our International Supply Chain team is currently working on a project utilizing this component for ocean vessels.
Flair: Google Maps
One of our early ideas for this project was an integration with Google Maps to give our drivers turn-by-turn directions to supplier locations. We currently only give them the address (many of these drivers are familiar with the area and repeatedly visit the same suppliers daily; paper-based systems are also very common in the industry), so we thought this was an easy way to improve their workflow while they were already in a mobile app. We wanted to incorporate it directly into the app’s workflow, so we placed it on the screen showing a stop’s information with a simple “Route Me Here” button, which opened up directions. We were able to call the Google API in a fairly abstract way, allowing us to reuse this component in various other projects that are currently doing map-based work.
Flair: Machine Learning
In a scaled-up supply chain, ETAs can be hugely powerful. Currently, we utilize the ETAs sent to us by our carriers across the network, but we don’t actually get these for pickups due to how dynamic they are. This is somewhat of a burden on the warehouse staff – they don’t receive any warning that a truck is coming in, ready for unloading. We knew we wanted to incorporate ETAs into this project somehow and figured we could use machine learning to predict them accurately.
We split up our data into three main silos of time: Time to drive between stops, time spent at a stop (but not loading), and time spent loading for each order. We looked at all pool points across the network and crunched the numbers for each of them, then came up with a generic system for looking at a truck and predicting the ETA between two stops (Fun fact: it takes about 27 seconds to load one item onto a truck).
Technically speaking, this involved a simple combination of linear and random forest regression. Given the time limitations it was fairly bare bones, but it certainly gave our project an extra sizzle while also providing huge business value. It’s also something that could easily be abstracted away to its own service, meaning other areas of our codebase could leverage the same predictions.
We utilize this information in a couple different places. First, we update the driver site with the ETA at the next stop, as well as the time estimated to finish their route. Second, we show an “ETA at Pool Point” signal on the dispatcher management page. This gives them the chance to better alert warehouse staff to the incoming volume that day and react accordingly. It also allows for the mitigation of unexpected delays. If a dispatcher sees that a driver’s ETA has jumped up by a few hours, they can potentially re-organize future stops to another truck that may be returning earlier than expected.
Putting It All Together
By the end of the weekend, we had built two tools that we were extremely proud of. First, driveWay: A fully functional mobile website that a driver could use to log their actions. It integrated perfectly into our current ecosystem and was intuitive to use. Second, a portal for dispatchers to manage their drivers that was generic and complete enough to be utilized in production for current truck across the network. We knew we had a strong business case for building these things, and we knew we had nailed it with our final products. The judges must’ve thought the same way; a week later we were named the Best Overall Winner of the WayfairHacks summer hackathon!
Pre-planning can go a long way. We did a ton of design work for this project, and I truly believe it was key to our success. Taking a few hours to talk through everything before writing a single line of code was huge for getting the team on the same page and allowing us to build and iterate rapidly. Know what you’re building, know what it should look like, and know what it should do. It really helps you iron out any issues early on and leads to rapid and clean development. Always have a plan before you write any code.
Constant communication is key. Six people working together on one application under a time crunch can be a stressful exercise. Writing duplicate code, invalidating someone else’s code, or doing the wrong thing could be very costly to the team. We were able to mitigate a lot of these issues by constantly talking to one another. If we split something up between frontend and backend, the two people working on these tasks made sure to talk beforehand and come to an agreement on what shape the data would take, plus what they expected from one another. We logged everything we were doing on a whiteboard with post-it notes using “To Do”, “Doing”, and “Done” columns, allowing everyone to see the status of the project at any given time. We also held a stand-up every few hours to have a more direct way of staying up-to-date with each other’s progress.
Winning is exciting, but we are more excited about getting this project into production. We are actively working on it and are slated to begin a pilot at our Carol Stream, Illinois facility in early 2019. I think this speaks volumes about the engineering culture at Wayfair and how we value ideas that solve real, hard problems. This wasn’t some flashy project that we wanted to just work on for a weekend; it was a project that we were all deeply passionate about and wanted to deploy. We think it can truly impact our business in a powerful way, and we are all delighted to be given the opportunity to run with it and take it as far as we can. We started this project as a way to cut out phone calls, and pretty soon it will be something used by people every day across our network. That’s an incredibly exciting idea, and it’s immensely fulfilling to see your ideas valued, invested in, and brought to life.
To see a full demo of this project, check out our DevPost submission at: https://devpost.com/software/first-mile-driver-app-n3z4y2.