Cvent: Revamping the Experience for Hoteliers’ Proposals
Just a giant image of the final concept for the redesign. Read on below…
The Problem and The Goal
The task at hand was a complete reimagining of the RFP (Request for Proposal) response process for hoteliers when trying to win the business of event planners for large events. In the conventional workflow, event planners would send an RFP, and suppliers (hoteliers) would respond with a proposal. However, the existing system for creating proposals was outdated, heavily reliant on manual inputs, and required users (hoteliers) to provide information that wasn't always relevant to the RFP they were addressing. The goal was to rethink and rebuild this experience to reduce cognitive load, speed up response time, and ensure its compatibility with AI technologies.
Challenge: No Users to Speak to During the COVID-19 Pandemic
During the initial three months of the project, there were significant challenges. The COVID-19 pandemic had severely impacted the industry, with many hoteliers out of work. This made it difficult to engage with users for research and product development.
The Research Workaround: Stakeholder Engagement
The research phase commenced with the absence of a dedicated product owner. Due to the lack of available users on the panel, internal stakeholders who interacted with hoteliers were initially interviewed. This laid the foundation for forming a new panel of suppliers and conducting a baseline usability study, as well as a path for competitive analysis. This phase allowed the team to identify user needs, pain points, and goals, including the need for precision, quick proposal completion, standing out to planners, having proposals accepted, and moving swiftly from one RFP response to the next. The resulting persona, "On-property hotelier," was distilled from this research.
As silver linings go, the one thing COVID did for us was speed up the cadence of our research plan
An example of a page from the old Proposal Builder application. Heavy usage of inputs increases cognitive load. Additionally, items such as allowing the user to select distinct room rate packages means that mutually exclusive selections are allowed because of the systems scant error handling.
Identified User Hassles and Problems
In a lot of ways, having such a flawed system is a blessing, because it’s easy to figure out where the problems are, and generally they align with the users’ criticisms of the product. In the case of our old system, stakeholder feedback and user sentiment aligned closely, and after extensive baseline testing, the major pain-points were the following.
High Friction: Manual inputs, a lack of stored data, onerous requirements, contradictory fields, and inconsistent information architecture. As an anecdote, the itemized page for Food & Beverage was ~390 inputs, which needed to be deleted individually should the user decide they didn’t want to enter data in them.
No Cost Totals: Users couldn't see the cost of the RFP as they progressed. This is a huge problem in terms of the user understanding their progress, as we’ll see below.
Toggling Screens: Constantly switching between RFP and proposal builder screens, generally on smaller monitors, which created unnecessary cognitive load.
MVP, Collaboration, and Technical Considerations
This was a highly cross-functional affair, and would require collaboration between design, product and dev at all points in order to make sure that requirements and technical capability align.
When the pandemic permitted, product, design, and development held a design workshop, where we worked together closely to collaborate on ideation. and to view the experience as a whole By early 2021 we were finally able to meet in-person, albeit masked, for a prototyping workshop to walk through the experience as a group.
MVP layers 1, 2, 3 were planned out according to what would require changes to the tech-stack, as well as what our dev team would need to support us directly, versus what could be supported by the wider development org - Limitations in the fundamental code-base data model (~20 years old), dictated where we would need to find workarounds to make the system feel as automated as possible. For example, if we wanted food pricing to be available at the account level for all users, but the system couldn't effectively ingest spreadsheets, then workarounds to limit manual entry were necessary. In this particular case, if a new item or variant of an item were entered in the process, and a user wants to save this item for future use, the system would ask if they would like to include it in the permanent pricing list, and if necessary, notify the admin of the price list.
Fig 1. - A paper prototype put together by the team to think through the experience as a physical artifact. We also brought in stakeholders to do blind walkthroughs to validate our assumptions.
Though we don’t dive into it in this particular case study, we were redesigning the RFP creation experience too, which necessarily had to closely align with the Proposal Builder in terms of flow and interactions.
When does an interaction need RFP information inserted? In this content design exercise, we bucketed things into “stub” (micro-interaction), “overview” (longer info interaction), and “event info” (requiring a callback to the RFP). This helped us determine injection points of RFP info.
Solutions: Moving Beyond Problem-Solving and Delighting Instead
Requirements could be easily mapped from pain points if we wanted to just solve a problem. But there was plenty of opportunity to delight; making a “dumb” system act smart with out AI was a bit of a challenge, but reading deeper into user and stakeholder input, it was evident that there were many possible design enhancements that would make the experience not just quicker, but one that delights. These are what we came up with
Reduce Friction: Calculating costs, particularly when it comes to food & beverage, A/V, room configuration is probably the most time-consuming phase of the process of responding to an RFP. Solving this by ingesting as much venue data ass possible at the account level would reduce user input time by making the system calculate cost automatically by reconciling the internal pricing list with the quantities requested in an RFP. Thus the system requires less input from the user. Additionally, items that were specifically requested by a planner in an RFP would now be automatically calculated as line items in the proposal builder by the system, freeing up more time for a user.
Conversely, if a user wanted to just give high-low estimates of costs, they were welcome switch modes and do so manually, which would require them touching only 10 inputs. No line items necessary.Show Cost Totals in Context: One of the biggest markers of progress in filling out a proposal is knowing what cost categories have been covered. This has been done by toggling between an RFP screen and a proposal builder screen in the old system. In the new system, all the user needs to do is open up a side-drawer, and the cost totals for each section of the form will display for them. They can even watch it update totals as they work.
Integrate RFP Info into Proposal Builder: Toggling between screens was a big headache, obviously. The user needs to refer to the RFP constantly and pulled out of their workflow constantly. As a solution, we presented relevant RFP info in the context of the field that needed to be filled. Practically, that is shown below in Solution 1b, where the information about square footage needs and room configuration are presented next to their corresponding fields for each line item. Additionally, as sort of a “security blanket”, the user can select “View RFP” from a floating menu at any point, which brings out a side drawer so that they can view the RFP in its entirety, without being removed from the context of their workflow.
Solution 1a: Reduce friction by having the system automate cost and total calculation. In this case the user is required to use four touch points, but some can be added in as little as one.
Solution 1b: Room selection was turned into a simple, one-click solution. In addition, important information about things like needed room capacity and configuration are now pulled from the RFP, and presented in-context for all necessary fields.
The side drawer allows users to view either the complete RFP, the ongoing proposal costs, or even location stats with the click of a button of the upper right-hand floating menu. The only interruption of the workflow is that the main content area width will narrow, but the layout and data are preserved.
Results: So, Were We Right?
This comprehensive overhaul of the RFP response process not only streamlined the workflow for hoteliers and event planners but also had a substantial positive impact on the business, resulting in increased reservations and higher user satisfaction. In short, significant improvements were achieved:
A pilot test (2022) with a large client resulted in a nearly 70% reduction in response time for hoteliers.
In pilot locations (LA, Atlanta, DC), there was a 20% increase in venue reservations.
The System Usability Scale (SUS) score increased from an acceptable baseline of 68 to 84.
A/B testing demonstrated that users spent about ~60% less time on the Costs page, with user sentiment indicating that perceived completion time was 50% less.
Actual time spent on the proposal creation process reduced by nearly 70%.