Designing an 80% Leap in Operational Performance
In March of 2021, I started at a small startup called GetDone. It was a company working towards creating a marketplace of service professionals from which multifamily property managers could order job services. Think of it as ‘Uber’ for painting, cleaning, and bathroom repairs.
I was hired specifically to work on their internal back-office tool nicknamed “Invictus.” It was an incredibly powerful tool that could do some incredible things — assuming you could remember how to get to the actionable items.
It was your typical internal tool, built one feature at a time with no thought for the person who uses it for there day to day work.
If a feature was requested, they told the developers what they needed and an approximation of where they wanted it, and then the offshore developers would figure out the rest.
They ended up with a feature-rich tool that was difficult to use and next to impossible to train people on.
On average, a single operations user could manage maybe 20 jobs a day, and they needed that number to grow exponentially; otherwise, they could not scale the company. This is where I come in…
Problem
Our internal tool is messy and difficult to use. There is little to no visibility of what actions need to be taken to move a job along the process from its start to its eventual finish.
Goal
With the current functionality, a single worker can only manage about 20 jobs a day which isn’t scalable. We need to get to where a single operator can manage 100+ jobs daily. And then, we need to automate out some of the tasks that are currently done manually.
Initial Discovery
I learned that employees would create a new table for each job status as the company grew. The tables would contain different information based on the use case. But they always opened up the same job page.
Because of this, operations had no clear view of the jobs in progress and were constantly “Clicking Through” screens to manually view what was in process. This was incredibly time-consuming, requiring at least one person to always focus on the back office tool during business hours.
There was also no proper navigation structure. So, if a user clicked on something on the jobs page, there wasn’t a direct route back to that place. So you ended up restarting a workflow over and over again.
Working Sessions
I ran a workshop with operations where we identified several outcomes we wanted to accomplish.
The first outcome was our preferred workflow. Login — view dashboard — select issue — drawer opens — user resolves the issue. Simple Right?
At this point, I didn’t know what type of issues needed action. So I got together with the team, and we hashed out which job stated required action.
Active States
If a job needed attention, we bucketed those statuses into a column
- Quality Walk Suggested
- Route Jobs
- Route Work Order
- Cancel Request
- Pro Request
- Approve Jobs
- Offers Sent
If the status didn’t require Immediate action from a user, we classified it as “Passive Status.”
- On Hold
- Need PO
- Job Started
- Price Quoted
- New Offers
- Approve Orders
just because a job was in a passive status didn’t mean it wouldn’t need any inputs from the operations user. it just meant that “It didn’t need attention right away.”
Now that we had these bucketed, I began working on some whiteboard sketches of possible workflows.
After a few rounds of feedback from the team, I came up with the concept above and began working on a Lo·Fi version of it in Figma.
Contextual Action Drawers
Once we had an idea of the dashboard, I needed to design the drawers corresponding to the actions taken. To do this, I worked with operations users directly, and we created workflows for each status.
For example, we did not have a way to auto-route jobs that had been ordered. When a property manager ordered a job, we would have to choose which contractors we would send the job to manually. (later, this would be fixed with an auto-routing feature I would work on)
To make this as simple as possible, the drawer would need a list of contractors and the prices we would pay them for the job.
I spent at least a day (or more) on the UX work of each drawer to ensure that every process was properly thought out and then tested, ideated, and tested again before we considered it ready for development.
Implementation and Outcomes
Once development started, I would say there were generally two modes of thinking about this concept in the office. The first was a sense of “hopeful optimism” from the operations team drowning in work. The other was “slight skepticism” from management, who felt I was using too many development resources on things that would “Eventually be automated out of existence.”
When we rolled the feature out for the team, its impact was larger than I could have imagined. It reduced the time spent in the app by operations by 80-90%, depending on how we measured the metrics. It was so easy to use that Management proposed we offshore the day-to-day management of the tasks to a team in Nicaragua. This saved the company money and allowed the operations team in Austin to focus on more important business issues. And most importantly, it allowed us to scale while building automation for some of these tasks. A single operations user could now manage hundreds of jobs over a single day, whereas before, they struggled to keep up with 20 jobs in a single day.
Over the next year, we made several improvements to the Task Dashboard and even used it to verify and train our ML models. As we automated out one process, we would encounter a scenario where we needed intervention by a human and used the Task Dashboard to do just that.
I would end up redesigning a large part of Invictus. However, I would confidently say that the feature that made the most difference for our company was the introduction of the Task Dashboard workflows.
