Automating a complex system

Introduction

My role during this project was IC Product Designer, embedded in the “Admin” product team who were responsible for reducing Sidekicker’s operational costs through product solutions.

Sidekicker is a two-sided temp staffing marketplace. We screen and skills test workers in a range of industries and then match them with businesses who need temp staff.

Let’s say you’re a bartender. When a business posts a job for a bartender, you’ll be able to see it and apply. The business will then be able to review all the applicants and choose who they want to hire.

Now let’s say you’ve been hired (congrats!), but during the period between getting hired and the job starting, life gets in the way - you get sick and you need to “withdraw” from that job. This case study is all about what happens next…

Problem

Before this project, the process of replacing a withdrawn worker was as follows (heavily simplified…):

1. The worker withdraws from the job
2. The job is reopened automatically and starts receiving new applicants
3. Our support team reviews the new applicants and selects a replacement on behalf of the business
4. The business is notified of the withdrawn worker and their replacement

While I can’t share hard numbers, let’s just say that this manual process was a SIGNIFICANT operational cost to the business. It was also something that clearly wasn’t going to scale. So the problem we needed to solve was simple: how do we automate it?

Let’s find out!

‍

Workers can withdraw from a job they've been hired on via the Sidekicker app.

Success Metric

As mentioned, the key success metric for this project was to reduce the operational cost associated with replacing a worker who has withdrawn. By automating this process, we expected to be able to reduce this cost significantly.

Process

Obligatory disclaimer: the actual process was of course not as neat and linear as below.

Discovery

I started by understanding the current state - how does this all work today?

I worked with the product manager to interview the internal support teams to map out their processes and identify issues and opportunities. We dug into the product to understand its role, including the email comms that were being sent to businesses. Finally, we talked with account managers to get an understanding of the broader business experience and the feedback we’d been hearing from them.

Design

The solution was comprised of three parts:

1. A matching algorithm that would identify the best replacement
2. Replacement logic that would determine how and when the replacement would occur
3. Email logic and designs that would determine how we communicated all this to the business

Matching algorithm

To better understand how our support team selected a replacement worker I conducted a simple survey. I asked them to tell us the importance they place on different positive and negative attributes of a worker. For instance, how important is it that the applicant has worked in that role before on the platform?

‍

Some of the survey results used to create the matching algorithm.

‍

From there, I used the results to calculate weightings that could then be applied to those attributes to determine a score for a given worker. The “best match” would then simply be the applicant with the highest score. A simple but effective solution that also laid foundations that could be improved upon later.

Score = weighted positive attributed - weighted negative attributes

Replacement logic

The next problem was when to use the algorithm. When a worker withdrew from a job, we would automatically open that job back up to the marketplace to get new applicants, but getting those applicants takes time.

I dug into platform data to understand the average time it took from a job being posted to receiving applicants. This became the basis for how long we would wait before running our algorithm and hiring the best match.

Comms logic

The final piece of the puzzle was how we communicate all of this to the business. The biggest challenge here was trying to design the logic and the content of these emails to work for a small business hiring 1 worker, as well as for an enterprise business hiring 300 workers for an event.

I iterated through a number of concepts exploring different replacement and comms logic, across different withdrawal scenarios. I again dug into the platform data to try and understand how certain decisions might impact the user experience - being particularly conscious of the risk of spamming larger businesses inboxes with notifications.

Delivery

Ultimately we landed on a solution that while necessarily complex, well and truly hid that complexity from our users.

The emails, while not the most personal and friendly for smaller businesses, were optimised to avoid large businesses being spammed. A summary email was sent daily to provide updates for any withdrawal activity in the past 24 hours, and a more urgent notification was sent if something occurred during the critical final 48 hours before the job start time.

Result

In terms of reducing operational costs, the project has been a huge success. Withdrawals requiring manual intervention from our support team have plummeted by more than 85%.

‍

Chart showing the reduction in withdrawals requiring manual intervention from our support team.

Lesson

When attempting to solve a complex problem, look for any and every opportunity to simplify.

‍

_{Photo by Possessed Photography on Unsplash‍}