The partner dispatch is what service providers see on their dashboard when receiving a service request. Instant booking is a feature that allows office managers to book a service instantly, without having to request quotes and wait 24 hours. Here we wanted to improve the dispatch tool for our partners so that the match is being made faster and to open communication between them and the customers.
Because partners don’t always know the scope or can’t always give a schedule to the customer right away, they are forced to contact the support team. The support team will act as an mediator between customers and partners because they can’t communicate prior to accepting the job . We want to reduce this back and forth and make it easy for partners to schedule a time or to ask scope related questions. We also want overall communication easier and smoother between customers and partners.
The first thing I did was to talk to our internal stakeholders to find out more about how the current instant booking works for them and where they saw areas of improvement. Here’s what I found out:
• Customers value the time to get an estimate as well as getting an accurate price • Customers are usually open to changing their schedule • Partners like the idea of instant booking but it’s difficult since it’s a rigid structure right now (not being able to talk to the client) • Currently, if partner isn’t available they will decline the job because they think the time slots provided are a hard requirement • Scope that requires communication or triage is often an issue (for example, a request that shouldn’t be under “rearranging boxes” but “helper”) • Often customers don’t know that much and we don’t want to overwhelm them with more questions. They want us to tell them what to do and it’s our responsibility to manage the order even if they don’t know what they’re doing because we are positioning ourselves as the experts
Both of these examples show a double confirmation for dispatch: the first one to accept the job and the second to say “I’m on my way”. These helped me understand how dispatch tools work and gave me a better idea on how to dispatch to multilple partners.
Drivers have a timer before accepting the ride, if they don’t accept, it will go to the next closest driver from the person requesting the ride. Once they arrive at the destination, they have to confirm on the app that they’re here, which sends a notification to the rider.
Couriers have the option to “skip” or “accept” a delivery. The location of the delivery is shown with the status of the order if applicable (ready now). Once they accept the delivery, they still have to hit “pickup” which will send a notification to the customer that their delivery is being picked up.
Based on this research, I wrote down assumptions to be validated throughout the project. The chapter "Vision, Framing and Outcomes" of Lean UX gave me a good methodology for this.
• Partners are scared to propose a time that isn’t in the customer’s preferences and decline, therefore allowing partners to accept an instant booking request without having to enter a schedule will increase the fulfillment rate for these requests. • Customers are usually open to changing their schedule, so opening up communication with partners will solve scheduling issues. • Asking the customers in the service request if they have a deadline and if they are flexible will make it easier and faster for partners to accept or decline the job (because they will have a better idea of the customer’s schedule).
• Customers will be matched with providers faster if we dispatch to multiple partners because the fastest to quote wins the job. This will decrease matching time (and customers want to get matched faster).
• Showing the customer’s phone number in product once a match has been made will make it easier and faster for partners to schedule a service and deliver it.
I mapped out the current flow and created an ideal flow to understand where the changes needed to be done and how it might affect users. There’s a tradeoff to almost everything and it’s always good to be aware of it so I also wrote these down.
Trade offs: • Partners can’t message customer before accepting the job • Partners are worried to enter a time different from customer request, so they end up declining
Trade offs: • If the partner can’t do the job, this extends the timeframe of the customer being matched and job getting done • This might make it longer for partners to accept the job (because of the messaging back and forth)
We will focus on what happens once we send the dispatch to partners. Here are the things that we will consider:
• Partners have to decide and notify us on the dashboard whether they can do the job or not • Partners can message the customer for any questions before committing to the job • We will dispatch the job to multiple partners instead of one • Partner will be able to view the customer’s phone number on the dispatch request
After showing the first round of wireframes to stakeholders and engineers, we decided to simplify the changes to reduce the scope with minimal impact on the experience. We added the customer's phone number on the parnter dashboard, we made it optional to enter an arrival window when accepting the request and (not shown here but) we are now dispatching the requests to multiple partners.
Talking to internal stakeholders was very helpful because they use the product everyday and interact with both partners and customers. Therefore they have insight that no one else does.
Forming my own opinion allowed me to move faster and design better. Everyone you talk to always has great ideas but because of limited timelines, we can’t do everything and we have to make choices. Here, I learned how to refine my assumptions that can be validated as we ship and test.