Looksharp Self-Serve Postings

First, a Little Context

Looksharp aims to launch the career of every student by providing the largest online marketplace for internships and entry-level jobs. Employers big and small come to Looksharp to hire talented interns and recent graduates.

At the time of this project, Looksharp was pushing hard towards profitability and financial independence. The majority of Looksharp’s revenue came from large deals done with enterprise companies looking to hire hundreds if not thousands of students and recent grads. However, it was inconsistent and inefficient.

We had some smaller self-serve customer posting jobs and making 1-off hires. We were charging $99 for a 30-day job posting and generating $1,800/month. We knew that if we wanted to become profitable, we would have to better monetize our self-serve audience. Thus, this project was driven primarily by a business need, not a user need.

Observation and Problem Definition

I knew we needed to better understand why employers weren’t paying to post on our site. Conversations with our self-serve employers revealed the largest current hurdles to paying to post positions on Looksharp.com:

Going Broad: Solving the Problem

We quickly nixed the idea of going completely free. We had tried that in the past and while it stimulated marketplace growth, it didn't generate revenue. After additional brainstorming with the team, we coalesced around the idea of switching to a pay-per-applicant model.

This model would allow us to do 2 things. First, it aligned our business model with our customer's needs. We would generate revenue by driving quality applicants to these positions, which is what these employers were paying us to deliver. Second, it removed some uncertainty and fear from the posting process for employers. They would only pay for results.

Fleshing Out the Plan

Changing our business model was going to be a costly investment, so the first task was to ensure that the idea resonated with our employer audience. I began sketching out potential workflows and used them to run the concept past employers.

It quickly became obvious that once understood, the pay-par-applicant model was a good fit. Unfortunately, it wasn't the easiest model to explain to the average SMB owner. They were used to paying a flat rate and understanding a new model was an overwhelming task.

Where I didn't expect them to get hung up was in setting a budget for their position. It took many iterations to figure out the best way to communicate the idea of usage-based payment.

The Launch

After iterating through sketches and getting input on the most confusing aspects of the model switch, I dove into higher fidelity designs.

We quickly built and launched with the basic pay-per-applicant model extremely quickly and found quite a bit of success.

Within the first month after launch we began seeing $400 days (up from $60 days with the previous model).

After the initial launch it became painfully clear through product feedback channels that we still had at least 1 major concern to address on the behalf of employers - the quality of applicants. Employers were concerned that we were simply going to go find just anyone on the internet to apply to their position and then charge them for it.

In response, we quickly iterated into an applicant restrictions feature that allowed employers, for a slight increase in cost, to restrict who could apply for their positions. If a student on our site wasn't qualified to apply for their position, they wouldn't even see it in search results.