DoorDash

My Role: Research toward a Repeatable Recruiting Strategy, Best Practices

Challenge:

Self-identified as a logistics company, this company’s products currently focus on food delivery. Roughly summarized, their user ecosystem consists of Partners (restaurateurs using proprietary tablet and app), delivery Dashers (app), and at-home Diners (website/app).

The product team had sent their Partners hundreds of emails in the previous year and had very little response from the users they hoped to engage. They were unsure why they had been unable to effectively reach this group of end-users.

I was hired to identify the best way to secure responses from, and subsequently schedule onsite visits with, one of the end-user groups (Partners) in a complex B2B2C user ecosystem. The immediate product goal was to launch in-house photography as a feature and to provide it to merchants during a site visit.

Objective:

The initial purpose of my role was to experiment with and track responses to different communication approaches in terms of medium (phone v/s email) and content (how and when did I introduce information), in hopes of creating a repeatable strategy for similar efforts as the company expanded into other markets nationally.

I was also asked to help coordinate/schedule site visits.

Within a few days of beginning this project it became clear that there was an opportunity to gather rich emergent data. My role was expanded to include encouraging and tracking user feedback in field notes and Asana, and distilling insights for future research and development efforts.

Process:

Intention up Front— not-being-hung-up-on is a measurable result:

In the initial days of the project, my purpose of my calls was framed as a follow up to emails that had not received responses. I had received a loosely suggested script, in which I began the conversation by asking to speak to ‘a manager.’ During the first day, I noticed that I was frequently told that the manager was “not in,” and was often unable to secure any concrete information about their identity or hours. I was often asked to call “later,” and occasionally hung up on. If not-being-hung-up-on was the first measure of success, something needed shifting.

I began to modify my approach, starting the call by identifying myself and providing a one-sentence statement of intent, and substituting “manager” with “someone I can talk to about that.” I was working off my own knowledge of the service industry, where a caller’s request for a manager often precedes a complaint or sales request, as well as what I knew (and learned) about the ambient pace and differing hierarchical structures of restaurants. These modifications seemed to garner more conversations, and I was no longer hung up on for the duration of the project.

Here are some of the insights that informed my ‘scripting’ approach:

• Flexibility was critical in responding to all the different communication styles, language differences, and time limits encountered when calling busy restaurants. For this reason, and to avoid sounding rehearsed or ‘salesey,’ I did not develop a script. I did keep an outline with key points in front of me.

• Stating the purpose of the call as quickly and simply as possible was most successful— as measured by willingness to engage in a discussion about scheduling a site visit or willingness to provide actionable information that would facilitate next steps, such as a decision-maker’s direct contact information.

• The merchants wanted to know what was being asked of their time. It was important to clarify that I was not making a sales call and to communicate the inherent value of research in improving the product and their experience.

You can’t answer email from the oven— Kitchen Brigade v/s My Son Deals With That:

Since it became clear that certain merchants had a lot of rich information to share about the product in the initial conversation, it was decided (by the product manager and research lead) that I would listen and note any feedback that came up in an initial or follow up call. I began recording field notes on paper, as well as coding searchable themes.

One thing I observed fairly early on was the variety in the types of restaurants using the tool. These “Partners” were entities whose business/organizational structures varied from corporate chain to family run. Smaller operations could be run in their entirety by as few as two family members. As the result, decision making could fall to a corporate team in a different city, or a family or team member with initiative. In almost all cases the person answering the phone was, or held the key to accessing, the decision maker. Therefore, we needed an approach that could initiate conversation by communicating value to the individuals— anyone answering the phone— encompassing the range of roles that represented Partners as a user group.

We needed an approach that could initiate conversation by communicating value to the individuals— anyone answering the phone— encompassing the range of roles that represented Partners as a user group.

Larger fine dining restaurants and even certain fast food chains follow a Kitchen Brigade model— a military-based system with a clear hierarchy. The chef may be a partner and interested in decisions, but she or he is unlikely to answer the phone when running the kitchen. In the Brigade model, some business communication is delegated to the “front of the house.” Conversely, in a small family-run business, these roles may be less rigid and often overlap. Mom might be the chef and financial officer and her son might be the host and public relations manager.

Both situations required different communication strategies/approaches to listening. The larger and chain restaurants did often request a follow up email and ultimately respond to it. What was consistently successful (as measured by response/follow up) was approaching with language that avoided assigning roles (Manager). This decision measurably opened up access to the decision makers regardless of structure.

Persistence is key:

I found that scheduling actual site visits could take up to three calls. This was due to multiple factors, but the single biggest obstacle was in accessing the appropriate point of contact. Often the first calls I made were about identifying the decision making contact, while the second and third involved reaching them at the appropriate time in order to schedule the visit.

Tracking notes in Asana:

Because the scope of this project grew as the opportunity unfolded, I made use of the tools at hand for tracking and documentation. Not surprisingly, I found Asana really useful for updating contact information as it was collected, scheduling site visits, and tracking requested call times. I was also pleased to discover I could track themes that emerged in conversations, where I might otherwise have relied entirely on handwritten notes.

I did this by making key information searchable to the right of the name of the restaurant in [brackets]. It was then possible to make practical lists of call-back times, but also to search, view, and aggregate lists of repeated themes— for example, expressed concerns about scalability.

• [a.m.] and [p.m.] callback times to reach points of contact within the appropriate time blocks

• [corporate contact]

• [customer service concern]

• [scalability]

• [food runner conflict]

• [in house dining/delivery]

• [use case conflict]

findings, Deliverables and insights:

Because of the way this project grew, there are three different project goals, and three different outcomes that I will summarize below as:

1) The quantified goal of scheduling site visits

2) Best practice recommendations as a deliverable

3) Thematic observations/findings about Partners’ experiences with the tool as it interacts with their business.

SITE VISITS

In terms of the concrete goal of scheduling site visits, the project had a quantifiable result. With the investment of about 70hrs of phone calls, 330 site visits were scheduled within the first month (on a rolling 2mo basis). This represented a dramatic increase in response over previous efforts in which emails had been sent to over 300 Partners, which resulted in 80 site visits.

BEST PRACTICE RECOMMENDATIONS

The resources were not available to measure anything but a strong correlation between my approach and the results. There was no AB test of different scripts or Chi-square analysis. However, the increased engagement was attributed by the team to my approach. I was asked to make strategic recommendations for future communication outreach to Partners, which can be roughly summarized as:

• take a phone-first approach (results in increased response and an ability to locate decision-makers within differing business structures)

• respond to requests for email (results in responses where delegation, scheduling, and coordination involves multiple collaborators)

• identify (your) role and communicating intent simply and early (results in less cognitive load for answering Partner and allows the proper direction of communication. short unambiguous words help in noisy environments and possible language barriers)

• anticipate/respond to differences in business structure and chain of command (results in a better understanding of diverse Partner roles and an improved chance of reaching decision-makers)

• respond to timed communication requests, requests for more information, or a desire to share insights and requests (responding to Partner schedules results in increased response. It also demonstrates an understanding of business concerns, communicates respect, and builds trust.)

• listen when users have rich information to share (results in actionable feedback for teams. Though the ability to record everything may be limited, recurrent themes can be noted/shared and specific concerns can sometimes be redirected and resolved by other teams)

Limitations

I’d like to address some of the limitations of this project. The first was the obvious time constraint caused by the product goal/deadline. The second was that several goals/projects were bundled into the parameters of the original goal. As a junior researcher, I was thrilled to have the opportunity to do more but was limited by the constraints of working alone and with very little in terms of tools.

Ideally, I would have more carefully recorded and measured the evolution of my calling ‘script’ (or more accurately, approach) and longitudinal tracking of responses. I likely would have done some statistical analysis of the recruiting results to exclude the null hypotheses. My notes and memories and these few data points are what remain. The team was satisfied with a strong correlation between my approach and the desired outcome, but in some ways, the outcome measured a product goal and reflects one of the pitfalls of combining a short-term functional goal with an analysis of how it was achieved.

Due to the constraints and breadth of my scope, coding data used broad, overlapping categories: organizational/; substantive/user descriptive; and, to a minimal extent theoretical/researcher driven. I was effectively using a contact list as both a project management tool and an analysis matrix. I quickly started using organizational categories including [a.m.] [pm] to indicate a callback time and [corporate contact] to direct it. I also used substantive categories for themes like [customer service concern] and [in-house dining/delivery conflict].

While this allowed me to track a lot of data from the overlapping projects in a single document, it also meant that some of the artifacts/documentation were blended or incomplete. I was able to enter much of the Partner feedback into the Asana matrix and code the theme it represented, but I was left with some concern about accuracy and attribution.

Perhaps the most exciting piece to me was the exploratory research which pointed to areas that could be followed up with task analysis etc.

Part 2 THEMATIC OBSERVATIONs, research Toward Future innovation

Though this project was unorthodox in combining product and research goals, I was happy to collect feedback from Partners. Several themes recurred in the conversations. Though a bit outside the scope of the project, this information was important to my understanding of the product, so I include it here.

• Several Partners described their relationship to The Business with great enthusiasm. Smaller restaurants described it as a key tool in growing their business, while larger ones with an ample capacity for growth (in terms of staffing/facilities/market expansion) also welcomed the sales

• Many Partners in smaller/newer markets commented on the warm relationship they had with their “rep.”

• Two long-term Partners expressed pride in having an established ongoing relationship with (the company).

• Several Partners described a conflict in their efforts to balance pleasing dine-in customers and filling delivery orders. They pointed to the pressure involved in running off multiple platforms not integrated into their Point of Sale system and requiring extra staff/paperwork.

• Perhaps related to this, there is friction between some Partners and Runners. Runners were described as rude, impatient, and lacking in understanding by several Partners.

• There were some problems in scaling. Several Partners described themselves as having become “too busy” for the product as their business grew, but their kitchen/staff remained small. Some of them were really dismayed that this was the case but were unsure how to balance growth and continue to use (the delivery product).

• The most frequent complaint was about a lack of support. Users complained of unanswered emails from their rep, or a lack of a contact altogether.

• For many restaurants, the delivery market represents a growth area but one with great operational hurdles. Many of the Partners I spoke to were pleased to have delivery managed ‘out of house.’ However, most of the companies offering this require additional tablets and more labor to process delivery orders and re-enter them into the restaurant’s POS system, and some restaurants are operating off of multiple platforms.

Reflections:

This experience left me thinking quite a bit about organizational structures and the complexity of designing for multiple end-users and overlapping systems. Because this project had a limit in duration, budget, and scope, these thoughts are in the form of a string of unanswered questions.

If you have sets of end-users /multiple products, are they interdependent? Has an excessive focus on the customer as the primary end-user created a challenge for the business end-user in a B2B2C? Does the product create friction among different end-users? Is there an overlooked or under-considered piece in the understanding/design of task flow? Is the product a system of interdependent needs between different user groups? Has design inadvertently created/emphasized a conflict or exacerbated a flaw in any of the user-group’s existing task flows? What other problems are those businesses needing to solve? What other tools are they using? What sort of environment does their work take place in? What are the opportunities to create a tool so that it succeeds by supporting the Partner’s business as an entity with its own internal use case(s)?