Helping Operators Prioritize and Address
Their Workload
A B2B transaction management tool for internal Opendoor operations
STAKEHOLDER OPENDOOR
THE CHALLENGE
Design a 0-1 internal tooling platform that helps Opendoor unlock scale to become the true one stop shop for all institutional transactions
THE OUTCOME
Pipeline, a desktop app that acts as an operators' source of truth, helps with everything from quickly getting context and prioritizing tasks to empowering them with insights so they can take a more proactive approach towards their casework
IMPACT
Since Pipeline's MVP launch we've increased SLA compliance on all tasks among operators from ~20% (Aug 2020) to ~90% (Aug 2021). Not only did we improve the UX but we also equipped leadership with the ability to understand operations' performance so that better strategic decisions can be made. And lastly, metric to beat for the project was 1500 COEs (Close of Escrow) which we were able to reach in as little as 6 months.
MY ROLE
Sole designer responsible for supporting all UI/UX needs within this org of Opendoor.
Additional responsibilities: Guiding product strategy, conducting user research, rapid prototyping, cross organizational collaboration, stakeholder management, requirements gathering, and use training
INTRODUCTION
Opendoor is known for being the alternative way to sell your home online but what many don’t know is we also provide our seamless experience and technology to institutional investors (that on average buy 2000+ properties/year). Becoming the preferred platform for these customers is mission critical to Opendoor’s success because unlike our core product, where there are costs associated with acquiring a home, there are no such fees for this product—only positive margins! And with proven product market fit the only blocker to unlocking scale in this space is the effectiveness and efficiency of our internal operators.
To capture this opportunity, we needed to understand what factors were keeping our internal operators from realizing their full potential
BACKGROUND
The institutional investors we’re dealing with are large organizations primarily concerned with acquiring, renting, and then finally the sale of single family homes; and it’s estimated that this is a ~$4T industry. Traditionally, these investors pull their leads from various sources of supply but the downside to this method is that it creates many different bespoke processes. Not only can Opendoor help to meet this demand by aggregating supply we can also streamline the closing process because we’ve brought key services in-house (such as OS National for title).
OUR USERS
Also known as Opendoor internal operators
LICENSED CUSTOMER EXPERIENCE PROFESSIONAL
Owns the end-to-end customer experience
By law, any person representing a buying or selling party in a real estate transaction must be licensed. In this case, our LCEPs represent the buyer (institutional investors) and communicate with all parties such as the seller’s agent, Opendoor, and outside parties.
TRANSACTION COORDINATOR
Handles all the behind the scenes
TCs do not need to be licensed and can support any LCEP in any market. Their role is concerned with anything that is not customer facing such as preparing documents, handling escalations, and managing the inspection / closing period.
USER JOURNEY
To truly understand what our operators are responsible for and where handoffs in a transaction lie, design worked closely with engineering to transcribe our backend state machine into a more user friendly representation of the process. Knowing where these handoffs were helped us to identify gaps and pain points in the current user experience. And from a product management perspective, creating clear labels for these sections allowed the team the ability to strategically prioritize parts of the transaction over others.
USER INTERVIEWS
As the research phase moved to lower altitudes we naturally started to involve our user base, who had much to say. What we quickly learned was despite having access to the same tools each operator used them in very different ways. This led us to group users in one of two buckets: proactive and reactive.
Investigative work and work involving strategy are considered to be proactive, while reactive work is characterized by closely following tasks and processes expressed within the tool. Additionally, proactive users had better overall performance but trailed behind reactive users in SLA adherence, which we attributed to them creating custom workflows outside of the platform. This discovery would lead us down a path to incorporate select workflows and create better task management (which directly correlates with SLA adherence) to uplevel all operators.
INTERNAL TOOLS AUDIT (TASKS)
Pros:
-
Easy to follow (Especially for onboarding new users)
-
Task priority is useful when planning "What to respond to”
Cons:
-
Some tasks appear in multiple systems creating double or even triple work.
-
Tasks are jumping off points and don’t provide enough of a description i.e. “Record”
-
Creating custom tasks for follow up could be improved
INTERNAL TOOLS AUDIT (INDEX VIEW)
Pros:
-
Contains all transactions which makes it a source of truth
-
Keeping a clean Index means you should be caught up in all the other systems too
-
Better than BAP Tasks for pre-contract work
-
Visibility into operator coverage for covering co-agents
Cons:
-
Users avoid the tool because they don’t have a workflow in mind, nor does the tool imply a workflow to begin with
-
The table view hides important information and is bloated
-
It doesn’t provide a way to resolve simple actions and only links operators to complete the task in other tools
OPERATORS' NEEDS
At this point we had a complete user journey, a full audit of existing tools, and pages of interviews but what we lacked was a concise understanding of our user’s needs that could tie it all together. One milestone in particular served as the juncture where we could see operator behavior change, which was when a transaction goes under contract and is no longer a lead. What matters before this point and what matters after this point are very different so we made sure to capture those nuances in our summation of user needs.
With confidence I can say that this is the point in the project where an understanding of our users and their respective needs had been reached. Every decision here on forward would map back to supporting one of these 6 needs.
DESIGN RECOMMENDATIONS
Designs' pitch to what we should build
PROBLEM STATEMENT
Fragmented tooling creates unscalable workflows which prevents operators from accurately and efficiently identify bottlenecks; ultimately leading to loss of contracts and the erosion of trust with our partners (institutional investors)
.png)
PIPELINE ITERATIONS (OPTION 1)
Prior tools had made users familiar with configuring filters (I.e. Product, Task, Deadline, etc) in order to see and complete the work assigned to them. Noticing this existing behavior, we began by visualizing every stage of a transaction in a tab-like fashion, and finding clever ways to display it all in one view.
This direction took inspiration from the kind of stock tickers you see on news channels as they glide across the bottom of your TV.
PIPELINE ITERATIONS CONTINUED (OPTION 2)
As we designed this feature it became more clear that the long names used to describe each transaction stage needed to be rethought. Names like "Awaiting Opendoor to send contract" and "Awaiting seller counter evaluation" were too wordy and made the user experience more difficult.
Fighting for ideal experience meant that re-naming everything was a must-have but naturally there was engineering push back. Mainly due to the database not being conducive to overriding all existing instances at once. Therefore the compromise we came to was we'd forgo the ability to show any sort of global priority on the pipeline tiles. Meaning for launch, all they would display would be the new names and the counts.
LEVERAGING ADJACENT TEAMS' INFRASTUCTURE
When we demoed the collapsable panel to users containing all their tasks, they were shocked. The biggest value-add they saw was the ability to access their list of tasks at any point without having to leave the experience and mark them as done. Seeing the value of this feature, I then went around to adjacent teams to see if there was anything we could reuse or if teams could leverage what we were about to build. I discovered that while there wasn't any reuse-able UI there was some backend infrastructure at our disposal as well as an appetite among other teams to use a feature like this.
GETTING CONTEXT
Operators now have access to see assigned tasks for any transactions without having to leave the tool. This supercharges their workflow and allows them to close out their SLAs more efficiently and with certainty.
Previous tools did not support any deadline visualization which resulted in users creating workarounds with calendars and kanban boards. We thought this would be costly to implement but during a hack-week the team crushed out a robust lightweight version that managed to make the MVP.
PRIORITIZATION
Operators can take advantage of the comprehensive list of filters and table sorting to help determine where they should begin their work. In addition, the pipeline filters dynamically sort the table view below to show only the information relevant to that transaction stage.
Unnecessary table information was omitted and allowed us to fit everything in one easy-to-scan view.
COMPLETING YOUR CASEWORK
Perhaps the crowning achievement that this project was able to accomplish for users proved to be seamless combining the "what to do" tool with the "where it's done" tool.
Merging two different backends proved to be a difficult challenge but through a series of compromises design and engineering were able to arrive at an agreeable solution without the user noticing the seams.
KEY RESULTS
Measuring our teams success
IMPACT
Since Pipeline's MVP launch we've increased SLA compliance on all tasks among operators from ~20% (Aug 2020) to ~90% (Aug 2021). Not only did we improve the UX but we also equipped leadership with the ability to understand operations' performance so that better strategic decisions can be made. And lastly, metric to beat for the project was 1500 COEs (Close of Escrow) which we were able to reach in as little as 6 months.
