Project Background
Company Goals
After a period of high churn (12%/mo- 50% retention over 6 months), Events Management was slated for a “redesign” to increase retention.
Design Problem
Motivate restaurant event managers to adopt a new workflow by automating and centralizing the work they already do in other tools.
Product Audit
I started by familiarizing myself with BentoBox's existing event planning product. A quick look exposed potential areas of experience friction.
A user would first create an event, where they would input basic information such as event date/time, number of parties, so on. Then they would be prompted to add a contract to the event, which would include the event details as well as additional free-form fields where users could add more details like selected menu or drink options. Then the user could share a link of this finished contract with the guest, which included a form where the restaurant guest could make payments on the amount charged by the restaurant. The following product decisions were also discovered:
- Contract is a 1:1 reflection of the event detail- any time a change was made to the event details in the BentoBox app by the restaurant, it would be directly updated on the guest contract.
- Distinction between event and contract page was visually unclear. They had the same information duplicated with only a couple fields that differed, and it was difficult to tell if I was looking at the contract or the event.
- Users did not have to preview the contract before sharing it with guests. The "View as Guest" button option had the same visual weight as the "Send Contract", and it was possible for the user to send out contracts without double checking details through the guest view.
The current flow laid potential for ambiguity in what information was being agreed upon between the user (event manager) and the restaurant customer. It was a very possible scenario that a user could change an event detail after the contract had been "signed", and there was no historical trail of what versions of the contract the guest had agreed to- a matter further complicated once payments were involved.
Understanding Users
Looking at existing data
To further dive into the motivations of our users, I looked through trails of feature requests that came in by speaking to our customer success team. The main feature request they received around Events Management was such:
Restaurant event managers want to send out multiple iterations of contracts to their guests.
I was also able to look at the initial adoption reasons and the overall positioning of the feature through our sales team.
Restaurant event managers will be able to collect payments and share event details online with their guests.
We had initially made the assumption that pure digitization of the labor intensive invoicing and contracting workflow would be enough to meet the users' needs, but it was becoming clear that we could not get users to adopt our product until we offered a solution that at least loosely modeled their existing workflow. This became more evident as we dug into the churn reasons, captured by the CS team.
Restaurants felt that they were not seeing enough value in the product.
- The product was expensive ($150/mo).
Contract feature usage was low
- It didn’t address all of their use cases.
- It didn’t actually make their work less tedious.
User Interview
We spoke to 5 restaurant managers to get a first hand account of their workflow to take an inquiry all the way to event booking.
Main friction areas
- Generating an estimate based on price, manual and tedious work
- Waiting for guest to approve the deposit, security of forms
- Communicating/charging extra payments
Overall a lot of loose links/email threads that further complicate approval of event details.
This is done over email in the method of loose pdf documents that get sent multiple times over. Payment is taken through the form of credit card authorization forms, typically a document with a line where guests type or handwrite their card information in, which are unsafe.
Design Goals
Using my learnings from the research, I set out to solve the following problems as I designed the product.
- Reduce redundancy in the overall restaurant workflow
- Allow restaurants to share different parts of event information with guests
- Direct guests to take action on the latest information
Solutions
Reduce Redundancy
I first clarified each step/page’s purpose by consolidating extra screens that caused unnecessary friction in workflow, and added steps that would simplify the contract/proposal process.
We also direct users to review the proposal/contract from a guest view perspective before sending it out with these changes.
Reusable Items
I also added storable items and menus so that users can quickly choose their most requested items and add it to the event charge.
Direct guests to latest information
Only one proposal could be active at any given time to remove liability for guests to act on any old proposals. I redirected users to the latest proposal if there is one.
.png)
