Post a job

Since the beginning of Mybuilder.com, we've had a simple form to help homeowners post a job. For the longest time this process involved selecting a category then populating title and description fields. It had contextual tips for each category, but essentially it was an open text description.

For jobs to be seen by tradespeople they must first be categorised, priced and approved - a process that was 100% human powered, requiring a dedicated team. When we started the project, jobs were being posted at a rate of 25k a week and growing. 

In addition, homeowners often did not really know what to write. For a tradesperson to be interested in a lead and for us to price it accurately it needs to contain a certain level of information. The jobs approval team would often need to change the job category, title, and description. But from feedback over the years we learned that tradespeople are often left wanting for more information on the jobs posted in order to make a more informed decision about their expression of interest.

The business was scaling fast and we didn’t want to have to scale the human power in this team at the same rate. Enter design and tech. 

Our early ideas were around using chatbots to gather the information from users in a progressive and engaging way (time reference;  peak chatbot). We figured, once we knew the job category we could ask a series of directed multiple choice questions to draw out enough information to put together a superior job description for tradespeople without the hassle of having to think about and write up the details yourself.

We made design prototypes and user tested the outcome. It showed great promise and everyone seemed really engaged in the new process. 

The next major hurdle was content. We needed to prove the concept worked and delivered usable results. So we began trawling through hundreds of posted jobs in each category, looking for trends, grouping them up into the most common sub-categories and understanding the scope of data we needed to capture. This allowed us to write the initial questions, and a set of follow on conditional questions based on the answers given. 

We pumped this into survey monkey where we bought a bunch of traffic to get completed answers, forming our early test outputs. We iterated on and repeated this process for several categories until we got what we thought was a winning formula.

Back to design and after some experimentation we decided to pause the chatbot implementation but kept the data structure, instead opting for a more typeform-like experience. Questions could be delivered one at a time in a vertically flowing, responsive layout that felt more accessible and less socially forced than the chatbot. We thought if we made a chatbot for such a business critical feature we would need an alternative experience anyway, so build that first and maybe return to the chatbot later. 

Working agile with our dev team we quickly moved to functional prototypes. The two hardest challenges here were moving to React with an experience that flowed the way we wanted, and figuring out how to structure and input the content. 

Our lead Developer came up with a clever solution to create our own set of coded schemas written in TypeScript. Using a set of pre-programmed question types and behaviours, we started to write the schemas for each job category. This investment paid dividends as we’ve continued to evolve and reuse this tech in future projects.

We ran a concurrent project called sub-categorisation. Its purpose was to take our existing job categories and break some of them up (on the trade side only so as not to increase homeowner complexity), enabling tradespeople to better target only the leads they want. For example a carpenter could previously only get all carpentry jobs, sub-cats allowed them to target 1st fix carpentry, 2nd fix carpentry, furniture/cabinet making, or any combination therein. 

Previously the jobs team would have to have made the appropriate sub-categorisation choices manually using just a written description. Now, with the new Post a job process we could add consumer friendly questions that make these determinations and assign the correct category automatically. 

Every lead must also be priced for the marketplace based on a number of variables, including job type, location, scale, intent, etc. Again, a manual process that frequently included contacting the job poster to get the relevant information to make the correct pricing decision. Another thing the revised Post a job could help with. 

Some of the questions added were to establish scale and intent in order to price the lead. Others were there to flesh out the job description so that tradespeople has enough detail to make an accurate determination of interest.

At the end of each user flow a final multi-line text box was provided to add additional details that the job poster feels weren’t captured by the questions alone. Some routes through the experience are just a few questions, others might take 10-15 answers. Regardless of the number of questions asked, we designed it to feel effortless by doing the hard work for you and ensuring we get an answer for the most pertinent details. Every question answered adds a line to your job description that is displayed in a structured format upon completion.

As part of the Post a job process users must either create an account or log back in to access their job again in the future. We had previously created a magic-link process to streamline this user flow, which we further optimised and enhanced as part of the Post a job project. Another detail that helped make the new Post a job experience feel effortless, especially on mobile.

We launched the new Post a job app in a staged roll out: A small percentage of traffic was given this experience and we learned and iterated based on the outcomes we started to see. Thanks to the brilliance of the schema system, making changes was as simple as changing a few lines of code, testing, committing and deploying.

We took a month to fully roll out the new experience to 100% of users, by which time we started to make organisational changes to get used to working with this new process and data. 

In the months that followed the launch we continued to monitor the jobs produced, looking for edge cases, improving the schemas and adjusting for the continued rollout of sub-cats and further auto-pricing optimisations. 

When we started, 100% of the jobs were manually reviewed and priced, with 20% requiring some further communication with job posters to make publishable. Today over 80% are auto-priced and less than 5% require our team to contact the poster for more information. 

We made dramatic PPC change’s at the time of launch which made conversion rate differences impossible to measure, but everyone is convinced it must have been positively impacted. 

One place we did see a marked improvement in conversion was on mobile compared to desktop. Before this project desktop converted 12% better than mobile on average, once launched the numbers shifted to mobile converting better than desktop by 3%. There was a trend heading in this direction naturally, as you might expect, but this project accelerated the process with it’s much more friendly mobile experience. 

The efficiency gains have been tremendous and have allowed us to scale the number of jobs posted in a way that doesn’t involve as much labour. Our homeowners get a simpler and more understandable user experience, and our tradespeople get higher quality leads. It was a big win all around, and our most successful project of 2018.