James Park

Designing Direct Messaging for Caterers and Customers

Overview
ezCater is the #1 catering marketplace with a 5-star customer service. Catering orders are high-margin but a lot can go wrong. I was on the Fulfillment team, designing experiences and improvements from the moment a customer order is placed, to being dropped off to the customer.

Problem
Customers and caterers love ezCater's customer service, but we also heard feedback that partners would like to avoid the back-and-forth telephone calls that happen when clarifying an order. For example, a customer would use Special Instructions to ask questions, or make custom requests. A caterer would then call an ezCater rep to answer the customer's question. This would create 3-4 calls for our reps, and also take time out of the customer and caterer’s day. It was all around inefficient. So our team began to ask, how might we allow caterers and customers to directly connect with questions that are better suited to be answered by the other party, as opposed to an ezCater representative? 

Duration
3 Months from discovery to hand-off

Team
1 PM 
1 Product Designer 
1 Engineering Manager 
1 Design Researcher 
4 Engineers

Goal
We found that this feature could address over 60% of the customer service requests coming in, so the potential impact of this project was promising. Our goal was to launch a beta of this feature, and understand how caterers and customers would behave when it came to using a direct messaging feature. We were interested if caterers would spam the feature, or try and and drive customers off our platform. On the customer side, we were curious if a messaging feature would be overkill (not another B2B app with a messaging feature…) or if they would find this more convient than talking with a rep. For both the customer and caterer, we were curious if the behavior of  chatting / calling ezCater, would be unlearned and replaced by directly messaging a request or asking a question. 

Approach
We started by needing buy-in from C-suite, after all, our customer service is one of ezCater’s principle value propositions. We started by workshopping the team’s ideas around a North Star that addressed...

1. order modifications
2. late deliveries 
3. general order customization questions

Product managers, platform leads, engineering managers, designers, and researchers all hopped in a Zoom room and rapidly jotted down what our North Star vision would look like.

After some dot voting of everyones ideas, we focused on a few use-cases that were most applicable. I took these use-cases and executed on storyboards that we would then present to the CEO and other stakeholders who would be impacted by this initiative. We conceptualized two parts of this feature 

1. structured communications, that would prompt customers to accept or reject an order request made by the customer
2.  unstructured communications, that would allow a caterer to send a message over open-text (something we were very anxious to release)

Storyboards designed and pitched to the CEO and multiple stakeholders  

I knew we were not the first 2-sided marketplace to initiate a similar service. I began deep-diving into how competitors and other marketplaces were handling this similar feature. Catering is different than single-meal orders because it requires multiple touchpoints between the catering parter and the customer. Customers are often concerned with accommodating eaters, customizing their order, and keeping the bill within a price range. With so many customer touchpoints involved in the process, a hypothesis began to form that a DM feature could be very valuable. 

Ubereats, Amazon, Doordash, Instacart, Airbnb, Shopify, Etsy, and Bookings.com had experiences that solved for similar use cases. 

Some takeaways from these experience audits, included potential approaches to address...

• customizing the support experience based on the user’s need
• allowing unidirectional messaging to start
• integrating an inbox or messaging center on the customer platform
• striking the balance between simplicity and discoverability of this feature
• introducing messaging entry-points 
• differentiating messaging with a caterer partner from messaging with our representatives.  

We started with the B2B app for our caterer partners. I worked closely with a user researcher to get 2 prototype concepts in front of some of our  partners. We tested...

1. feeding messages into an “Action Needed” order management system, while introduce a messaging section on the order details page and 
2. adding a new Message Inbox tab, completely separate from the order management system. 

We found that the messaging functionality fit better into catering partners’ existing workflow as part of the order management system, rather than creating a new entity within ezManage. We also learned caterer partners were concerned customer messages would be missed, so we need to put in extra work to make these clearly stand out. 

At the same time, I ran design requirement workshops as we began to start thinking about what an MVP would look like. We considered things like SMS, Email, and push notifications, masking contact numbers to protect our user’s privacy, and see when an ezCater representative is helping out with an order. From these requirements I made an app flow that documented how our users will interact with our product, when they would receive notifications, and what would happen in the customer service experience if they contacted ezCater and didn’t respond to a message. I worked closely with the engineering manager to align with the workflow management service, which controlled when messages would fire or not. 

I began iterating around the right-sized solution we wanted to release our beta with. I iterated around 3 concepts for the caterer partner app:

1. an order support themed concept where caterers could send messages after answering a few  questions
2. a concept where entry-points into the exact request would exist contextualized in order details, and would bring caterers to a more extensive order request feature
3. a hybrid concept where I separated unstructured comms as a DM feature, and structured comms as an order support feature.

Here’s where design feedback came into play. I believe in rapidly iterating different concepts, and sharing them with my colleagues as soon as possible to put us further along in the design process. In this case, we landed on the hybrid concept #3 with some elements of concept 1, where the messaging entry-point would exist separate from the support feature.

I redesigned the order and delivery details and gave it more hierarchy by simplifying the order labeling, adding hierarchy to information crucial to orders, and by adding action buttons in close proximity to a related section. What this allowed me to do was free up space in the side-panel for the messaging UI. 

At this point in the design process, I focused on validating the structured and unstructured messaging flows, entry-points, and information architecture to fit a caterer partner’s mental model. I knew later down the line, I would invest time to add more detail the UI.

From there I began iterating around different concepts and layouts for the order details page as well as on the message builder interface. There were 5 use cases we wanted to allow caterers to do:

1. requesting a new delivery time
2. replacing an unavailable item
3. modifying an item
4. adding an item
5. clarifying a question with the customer.

A caterer partner would be able to do this through the Message Builder, which required the caterer partner to enter initial information around their request, to initiate a communication with a customer. We wanted to encourage caterers to send customer message for these 5 use-cases to start.  

After endless round of interaction, feedback loops with stakeholders on the caterer success teams, and with caterers themselves, we landed on keeping the messaging window separate from the support experience for now. We created a very structured message creation flow, that caterer partners could complete to start sending self-servicing questions more efficiently. 

On the flip side...

At the same time we were  working on the customer app, defining what exactly we needed to build. I started by creating visual stimuli with a researcher to understand generally how customers would perceive the ideas we had. Ultimately we found that customers didn’t mind caterers directly reaching out to them, as long as this was more efficient than calling an ezCater rep.

These scenarios were presented to customers during generative user interviews, where we sought to understand if customers would be okay with receiving a direct message.

In order to keep our development cycles efficient, I designed a component library that would be used across the B2B, B2C, and internal apps to reduce the time it took to execute on interfaces. By creating components that would make sense for both the customer, caterer, and service representative, we were able to collaborate with teams across different domains in a lower-friction manner.

About 20 React components were created to be used across 3 different products at ezCater

In order to move quickly, and collect feedback from our customers, there were trade-offs that needed to be made, and feature improvements that we descoped for the beta. One of these included building this UI on a completely new page and rendering the order details in a message-centric view, which was feedback we received early on from customers. Because our beta would only be tested with a few caterers and customers to start, we knew we had to hit our release deadline and understand performance before pouring more investment into this feature. I worked closely with the engineering manager and product manager to define what exactly need to be scoped out.

The messaging UI would exist next to order details just for the beta release. For V2 the plan is to separate this experience onto its own screen.

For our post beta release, we plan on creating a new messages page where customers can be quickly dropped into a focused view of caterer requests whether they came from an email, push, or SMS notification. This would allow customer to respond to requests quicker in theory.

In addition to designing for mobile web and desktop, the designs were adapted to iOS, which is one of my favorite part of designing cross-platform. I was responsible for working with our iOS engineers to make this a reality for our iOS-only users.

Last but not least...

One of the last steps were creating the user experience for our service representatives who would be addressing anything that went wrong when our users exchanged messages. There were a few cases to design for...

1. when a customer rejected a caterer request, we wanted a rep to step in and handle this by calling the necessary party
2. when a customer contacts support, reps needed the ability to view and act on any caterer requests.
3. when we needed to involve a rep when no response was given or an open exchange was left unresolved.

I quickly adapted our components to fit into our internal tool used to handle all customer communications with ezCater. 

Results

Our hypothesis that direct messaging would capture for about 60% of service requests made over chat and phone still needs to be tested with our beta release. The plan is to release the beta by working with a handful of high-performing partners, and then roll out the feature in phases to a larger number of partners, learning along the way. We will solicit feedback and implement fast-follow improvements to get us to the V2 vision we set out to pursue. One of my biggest takeaways from designing this feature was how amazing to see the unique designs that came out of business, engineering, and design counterparts collaborating together. 

If I were to re-approach this feature set again, I would remember to… 

1. Communicate my design timelines early and often. You can never be too vocal about it
2. Make design documentation straight-forward and simple, your coworkers will not read it otherwise
3. Design reusable components from the beginning. Component-ize all elements and think in systems
4. Don’t underestimate the power of design and visuals to make a feature launch successful, and when engineering or product counterparts push back, take that as an opportunity to understand and reframe the conversation

Thanks for reading!