Overview

Over the summer and fall of 2015, I worked with Antonio Ono to prototype a human-powered concierge service prompted by a question: Could on-demand services be made more useful and accessible by abstracting them behind a conversational interface? Since people are already used to texting and messaging their friends, it seemed like it would be natural for people to use text messages as a way to send requests for things they needed done. 

We prototyped the service to gauge interest, understand how it might fit into clients’ lives, and assess the difficulty of the project. I worked on coordinating the concierge service itself, while Antonio focused on building its digital components. Coordinating the service involved writing copy for canned messages, designing how to find out and sign up for the service, reaching out to potential customers as well as writing employee manuals, researching legal criteria for creating a startup and potential ways to hire Saint employees. 

We tested the service with a couple dozen people, and in the process, designed an iOS app, implemented an SMS-based messaging system, explored business models, and designed communications for service.

Currently, we’re using our findings to inform a new approach to delivering the service. It’s been interesting to see services like Facebook M, Magic and GoButler explore this product category.

Conversational

After narrowing down what the service itself might be, we designed and partially implemented an iOS app.

We eventually postponed the app to focus more on the service itself, and switched to an SMS-based experience, which allowed us to iterate much more rapidly.

When we started, we thought, what could be simpler than a human conversation? While it superficially seemed like the most natural experience for clients — everyone knows how to send messages — it crudely masked underlying complexities inherent in the service itself. For example, how would we handle the handoff from one concierge to another? Where does one request end and another again? How does the client indicate which request they’re responding to?

A linear conversation looks simple, but that simplicity glosses over the way the system actually works.

Request Oriented

We then  explored how the interface might work if requests were discrete, with messages pertaining to those requests (like questions and clarifications) being subordinate. In addition to better visualising how the service actually works, it makes the purpose of the product much clearer and optimises the interface for the most common actions. Testers more quickly grasped what the product was for and how they should interact with it.         

We tested our service with people who signed up online, as well as friends in various cities across the United States. We used Sonar to manage text messages. 

layout

Applying a richer structure to the architecture enabled us to explore a diverse variety of layouts. If the conversation is an atomized structure, it creates opportunities to use the typographic layout to drive more efficient usage and better elucidate the functionality. 

website

To elicit feedback on different ways we might illustrate a product we often found challenging to explain, we produced a few iterations of webpages explaining the service. This allowed us to iterate on the copy, layout, and examples simultaneously in response to feedback and the ways we were changing the service.

This was also how testers were able to sign up for the service. We built simple web app to keep track of users and billing information, and to route messages and delegate requests to concierges.

When someone signs up, they immediately receive a welcome message. As soon as they make request or ask a question, they’re assigned to a concierge. When the concierge marks the relationship complete, the connection is closed. If necessary, we collect payment information on a separate page.

View live.

This project was the product of a couple of years of thinking about how one might best build an experience synthesizing the proliferation of on-demand services. There are countless “on-demand” services (admittedly of varying quality and plausibility), but no one will download thirty-seven apps for thirty-seven “Uber for _____” services. Our goal was to abstract these services behind a natural language UI, allowing us to bring services together to solve abstract problems.

This quickly changed. There were three significant phases in our approach to communicating about and delivering the service.

Ultimately, our goal was to make the product essential to just a few people.

On Demand Anything

The first and most obvious iteration of the service was as a way to get anything on demand. While was easy to communicate the product, we increasingly found that the requests made were not beyond the scope of what people already knew services could provide (e.g., delivery and home services). We could fulfill requests of much greater complexity, but this was difficult for people to understand. Just as critically, it was not a service clients could make frequent use of.

Moreover, the services we were delegating to were often unreliable and mediocre. People need these things done, but in most situations, there aren’t any services that can reliably take care of them.

And of course, the emergence of services like Magic and GoButler eliminated whatever differentiating qualities this might have had.

         personal assistant

To test this, we responded Craigslist ads for personal assistants. The complexity and variety of clients’ expectations quickly made this infeasible, and it was hard to see how this service could amount to much more than an agency for hiring personal assistants.

We also considered structuring the product around home services. But here, too, clients’ needs were so varied as to make the pricing and scope of the product impossible to pin down. And we found existing cleaning services to be unreliable and inconsistent.

          bespoke

Faced with this, we realized what we should have done from the beginning: co-design the service with a single individual, without any presuppositions about what they might need or how they might want it delivered. Repeat this process with different individuals until patterns emerge. Where do clients struggle in their daily routines? What activities to they feel comfortable delegating? What can be most efficiently handled by third parties? What ought we handle ourselves?

This is the current phase of the project.

commission

We had been discussing this idea for about a year by the time we had heard of Magic, but felt the service unusably subpar, and the business model unsustainable. We thought an entirely free service would lead to even lower quality and unacceptable compensation for employees.

So, from early on, even though it wasn’t our main concern, the business model was at the top of our minds. Our main considerations were sustainability and simplicity. We considered a few options: 

Since the rapid growth enabled by totally free service was irrelevant to our goal of creating a few persistent clients, the closest thing we considered was charging a modest service fee on purchases. We experimented with different combinations of percentages and flat fees, but it never added up. Not only did a significant minority of requests involved no purchase (usually requests for research), but even a hefty service fee wouldn’t cover much more than minimum wage for the concierges. This wasn’t acceptable, and wouldn’t allow us to hire the best concierges. It would force us to optimize for speed at the cost of quality, and we observed that services that used this model persistently pushed clients to make purchases. 

service fee

A flat service fee on all requests was appealing for its simplicity, but suffered from a critical flaw. It presented a mental barrier for people to use the product. Even if the client considered it worth the expense to have something taken care of on their behalf, having to make that assessment for every single request would've presented enough mental friction to prohibit the habit formation and effortlessness we wanted. 

subscription

A subscription, despite presenting a high barrier to entry, accommodated our goals best. It encouraged frequent and habitual use, and allowed us to build a strong relationship with the client. And it suited our objective to maintain a handful of demanding clients. Of course, it also makes the product a very difficult sell, especially considering it’s hard to evaluate its value without first using in your own life.

Since our focus was on prototyping and evaluating the service, we never came to a decision on this. But it remained a frequent topic of discussion.