Recruiters can use Mya to help with both inbound and outbound recruiting. Mya can talk to candidates via text or chat widget to gather job-related information, answer questions, keep potential candidate profiles up to date, and do a variety of other things.

With outbound recruiting specifically, Mya could reach out to thousands of candidates at once and gauge their interest for specific job roles or simply add/update their profile in the Mya recruiter portal.

We call these outbound recruiting initiatives Campaigns.

For every Campaign, Mya would have dozens up to thousands of conversations each week. Each conversation typically brought in information related to the candidate and generated data around Mya’s conversation performance. All of that data is stored individually in candidate profiles and could only be viewed there. This data is extremely useful, but there were more ways to organize it in a way that could benefit users and improve their efficiency with Mya products. So, how exactly would that work?

What if we could group and display Campaign’s generated data in individual dashboards?

The primary user group that handled all things Campaigns were recruiter admins. We brought them an idea where they could create and launch their own Campaigns, rather than having to go through the Mya team. They could then view candidate profiles, drill into Campaign performance analytics, and manage the Campaign via a dashboard. Needless to say, they were pretty excited.

Meetings with customers as well as the engineering, leadership, and product teams unveiled some helpful knowledge:

• Stats: There were tons of Campaign performance statistics available to me and some held more relevance to users than others.
• Campaign creation: The way Campaigns were currently created was quite simple. All they needed was some information from the customer and a shortlist of candidates to contact. Most, if not all, customers were using an Applicant Tracking System (ATS) outside of Mya, where they managed candidates and jobs. They typically would create a shortlist in their ATS and import it into the Mya recruiter portal via a CSV file. For me, it was mostly a matter of translating their process into a nice and easy-to-use UI.

‍

We kept version one of the new Campaign features fairly simple. Although I was insistent about including a Sankey chart somewhere in the Campaign Dashboard, it didn't make it into the MVP. To ensure rapid delivery and minimal backend involvement, we kept the design very simple. It displays several relevant overall Campaign statistics and included a preview of some candidates. The "View All Candidates" button took users to the global candidate list view and auto-applied the filter for that Campaign. Users could also see where in the conversation process Mya was at.

The Campaign creation process was a form with a CSV upload option for the shortlist.

The new Campaign features made it to two large customers with the same ATS integration. The rollout went very smooth and we didn't receive too much negative feedback. Users were appreciative that they could launch Campaigns more quickly and check on their progress whenever they wanted. The statistics informed them on how Mya was performing, allowing them to test different types of conversations effectiveness, and collect data related to each different job listing. However, on our end, we knew that the company and the product were scaling, and there would more potential for this feature down the road. But for now, we could just enjoy the win.

I was heavily involved with planning the next version of the Campaign dashboard and further improving the overall way Campaigns functioned. Sadly, I was not at the company long enough to see my designs all the way through, and am unsure of the outcomes. However, I still want to briefly showcase the direction we were going in.

The biggest improvement was centered around how Campaigns ran. Normally it was one and done. A Campaign is initiated and as soon as it finishes, it essentially becomes obsolete. We made moves towards allowing the same Campaign to run multiple times over any given duration (weeks up to years). Each time it would run, it would be using a different shortlist. This would be immensely helpful for high-volume roles with high turnover and in need of fast turnaround times. Each time a user wanted to trigger the Campaign to run, they simply had to upload a file with the candidate pool and desired run time into an s3 bucket.

With this addition, creating and setting up the Campaign became a little more complex. Scheduling run times came into the picture.