Feature Proposal - Applicant Tracking System (ATS)

Howdy. My company is growing and so I am putting on my “recruiter” hat. With this, I started to notice a feature that could be added to the HR module to aid companies in their recruiting process better than what is in place today. This is a long post, so please bear with me.

Right now the workflow is Job Opening -> Job Applicant -> Offer Letter -> Employee.

I would like to propose a change to Job Opening -> Job Applicant -> Job Applicant Review -> Offer Letter -> Employee

The current doctypes of Job Opening and Job Applicant need more fields and children doctypes to get more usable information into the system about employment candidates.

Changes to Job Opening

  • Ability to adjust the website route after initial creation/save
  • Add Job Opening Date - The date the job opening was opened
  • Add Job Opening Close Date - the job opening will close on this date and will automatically be unpublished from the website and the status changed to closed.
  • Add Job Type field (Full Time, Part Time, Seasonal, Temporary, Contract, Internship, Commission)
  • Add Salary Type field (per hour, per day, per week, per month, per year, and per sale (for commission))
  • Add Min Salary and Max Salary fields, linked to salary type field to be able to show the min and max pay range for the job opening
  • Add Location Fields (city, state)
  • Add link to Company docytype to show which company the job is for
  • Add link to Employee for “Hiring Manager”

Changes to Job Applicant

  • Change applicant name and break out to First, Middle and Last Name fields
  • Add address information
  • Add phone number
  • Add Possible Start Date - “If Hired, on what date can you start working?”
  • Military Service Y/N
    – If yes then ask for Branch, Rank, Years of Service, Skills/Duties, Other Details, Discharge Status (honorable, other than honorable, dishonorable)

Add new Job Applicant Employment History doctype

  • To be presented as a table in Job Applicant so the applicant can fill in previous work history.
  • Fields
    – Employer
    – Employer Address
    – Job Title
    – Supervisor Name
    – Supervisor Telephone
    – Job Type
    – Salary Type
    – Last Salary
    – Start Date
    – End Date
    – Position Description
    – Reason for Leaving
  • The end date field needs a possible override of “current” or “present” if the person is still employed by that company

Add a new Job Applicant Education doctype

  • To be presented as a table in Job Applicant so the applicant can fill in previous education and other experience data
  • Fields
    – School Type (High School, College/University, Vocational)
    – School Name
    – School Address
    – Number of years completed
    – Graduate Y/N
    – Degree/Diploma Earned Y/N
    – Degree Name
    – Notes

Add a new Job Applicant Training doctype

  • To be presented as a table in Job Applicant so the applicant can fill in training, certifications, professional licenses, etc
  • Fields
    – Training Type (General, Technical Certification, Accredited Certification, Professional License, Foreign Language)
    – Date Earned
    – Company
    – Date Expires
    – Name
    – Description

Add a new Job Applicant References doctype

  • To be presented as a table in Job Applicant so the applicant can give references
  • Fields
    – First Name
    – Last Name
    – Telephone number
    – Address (optional)
    – Email Address
    – Related Company (from employment history)
    – Number Years Acquainted

All of the changes to the Job Applicant* doctypes must reflect on the associated web form so anonymous users can apply from the ERPNext website. If an administrator customizes any of the Job Applicant* doctypes, then those changes also should appear on the web form automatically. This allows a local administrator to ask other questions, collect more data for their site specific job applicants.

Now let’s move into the new main workflow doctype called Job Applicant Review. This doctype will have a collection of children doctypes to fully support the process of interviewing candidates in a “review” process before you move forward or not.

Add a new Job Applicant Review docytpe

  • The purpose of this document type is to create a place where a recruiter can intake an applicant and then gather all pertinent information about interviews, questions asked, score, etc.
  • From the Job Applicant form, there would be a button to “intake applicant” that would create a review document
  • If you move an applicant to review phase, then the status goes from open to “in review” on job applicant document
  • Fields
    – Recruiter (linked to employee list, maybe a new role in setup to create a filter - auto populate with current logged on user)
    – Interested (Yes, Maybe, No)
    – Status (New, In Review, Phone Screened, Interview Scheduled, Interviewed, Do Not Hire, Progress to Hire)
    – Link to Job Opening
    ---- Read only fields (but visible on the review document pulled from job opening document) are: title, opening date, closing date, hiring manager
    – Link to Job Applicant
    ---- Read only fields (but visible on the review document pulled from job applicant document) are: first name, last name, phone number, email address
    – Notes Log - would work like the comments area on the form. As the recruiter has conversations with the applicant or the hiring manager then he/she can add a note here as they go. Then all of them are organized by date/time stamp in descending order (newest on the top)
  • Table of Job Applicant interview Question Records w/ Links
  • Table of Job Applicant Score Records w/ links

Add a new Job Applicant Interview doctype

  • The purpose of this doctype is to manage job interviews for the candidate
  • Can be managed from the Job Applicant Review document with a button (create interview).
  • Fields
    – Date
    – Time
    – Location Address
    – Meeting Room
    – Interviewer (e.g. the hiring manager, but could be another person)
    – Table of Job Applicant Interview Score records w/ Links
  • When an interview is created, the system will email an ICS invite to the interviewer and interviewee so they can add to their personal calendar.
  • The interviewer would get a separate email with a link to the associated Job Applicant Interview Score document for the particular interview to fill in during or after the interview.

Add a new Job Applicant Interview Questions & Job Applicant Interview Questions Template doctypes

  • The purpose of these doctypes is to allow a recruiter to work with varying hiring managers and develop lists of interview questions and to capture answers when used.
  • The lists could have a type, such as “phone screen”, “first round”, “reference” or others to differentiate the lists.
  • These doctypes would work very similar to the Appraisal Template and Appraisal doctypes that already exist in HR.
  • A lot of companies have highly standardized hiring procedures and questions that candidates must be asked as part of the interviewing process. These doctypes allow for the standardization and capture of all questions and the answers.
  • To be seen on the Job Applicant Review document as a table.
  • I don’t list fields here as I am not sure exactly what would be needed.

Add a new Job Applicant Score & Job Applicant Score Template doctypes

  • The purpose of these doctypes is to capture candidate scoring scores from a Job Applicant Score template document
  • The doctypes would work very similarly to the Appraisal Template and Appraisal doctypes that exist already in HR.
  • This way an administrator and can work with his/her company HR department and develop a standard candidate scoring process for all applicants by company.
  • To be seen on the Job Applicant Review document as a table and then a section below the table that takes all the scores and weights and gives a total score.
  • I don’t list fields here as I am not sure exactly what would be needed.

With all of this in place, ERPNext would be way ahead in HR in this area. Most companies have to use external processes and tools to accomplish this.

Not sure the best way to get this into the platform as it is probably a good deal of effort. Maybe create a collection of git issues that breaks the work down into logical chunks? For example the proposed changes to the existing doctypes can be done in a few issues and then the last pieces as one big one? I am also under no illusion as to the amount of effort this will take. Maybe the HR module leader can take a look and see if this is a good fit for a roadmap item. I am happy to create the git issues and contribute thought leadership on this subject.

Thanks for your consideration of this feature.
James

6 Likes

@James_Robertson I think this a great idea and i have trying to get time to work on something like this.

I found this and i think it could provide a good base https://github.com/imad-abdou/addons

I have seen that repo posted before. I definitely think some of the project items would be worth taking a close look at. <off topic> I am not a fan of the way the projects module does tasks right now so we don’t use the module. WAY TOO MANY clicks to add a task. </ off topic>

I can’t tell potential use cases for the HR ones listed, except for the interview evaluation one. That is part of what I am proposing above in the Job Applicant Interview Questions doctype (and related template).

Opened gits to break the effort up

2 Likes