Admissions Data Management System
Project Goal and Stakeholders ​
The context of the Admissions team when I first entered Teach for the Philippines was that we had a subset of members specifically dedicated to Recruitment and another one dedicated for Selection. While we were able to collect and store information on our candidates through different activities that we were doing, the way the team's data was structured prevented us from using it to inform our strategy and operations in an effective manner. Having 2 sub-teams within the same function team led to a challenges in communication and alignment and as a result, I sought to create a more unified data management system within the team that sought to streamline the way we collected, organized and utilized candidate information to drive our decision-making.
Approach and Methodology​
​
INFORMATION AUDIT​ AND MAPPING
​
The project began with an audit of existing information and data that was regularly being collected. This involved accomplishing the following:
-
Mapping out specific data points that were being collected across various activities
-
Reviewing how our team's tools stored and managed the information being collected.
-
Identifying which specific metrics and additional data points the team needed to track to make strategic and operational decisions
​
This was made possible by consulting with the all of my different team members, both associates and managers to see what was relevant to their needs and what kind of system would be most useful for them to use. Once I was able to collect all of the necessary information, I had a clearer understanding of what would be the most streamlined way to organize all of the team's information.
​
TOOL DESIGN
​
When I finished mapping out the way candidate information would be managed by the entire team, I identified 3 main tools around which our data management system would revolve around:
​
A simplified visual to I designed for onboarding to explain how our Admissions data system was set up. Candidates fill out forms set up with Form Assembly to provide information that is then transferred to Salesforce. Salesforce is also where recruiters provide inputs to process candidate applications. Our dashboard hosted in google sheets then pulls all relevant data from Salesforce in order for the team to act on the data real-time.
Form Assembly. This was the main platform that we used to interact with candidates and collect their information. Multiple stages in our process involved the use of forms so I worked with the team to design them in a way that not only collected candidate information, but also streamlined questions being asked to remove redundancies. Moreover, I set up the forms to transfer data seamlessly into our Salesforce database using connectors. This meant I ensuring that there was an alignment between what information was collected by our forms and the fields that were set up in Salesforce to reflect the information.
​
Salesforce. This Customer Relationship Management platform became the main database where all information regarding our candidates was stored. To set this up, I made significant changes to the objects and fields where candidate information was being stored so that the team's data was structured in an organized format. This tool was also customized to be more intuitive and user-friendly for the team members, as they regularly interacted with Salesforce to input relevant information collected about candidates to process their application. Automation was also set up using workflow rules, field updates and email alerts so that the team could scale the number of candidates it was processing at a given point in time.
A snapshot from one of our forms and a section from our Salesforce platform that displayed candidate data. I made it a point to ensure that all information collected through Form Assembly was reflected in Salesforce so that all relevant data points that we were collecting were being tracked properly.
Candidate Dashboard (Google Sheets / Excel). This was the main file that the team regularly utilized and updated so that it could serve the following functions:
-
Track significant milestones in the recruitment and selection of each individual candidate. This was made possible through the use of multiple SQL queries, that pulled key candidate information automatically from Salesforce into a consolidated Candidate information tab. Excel formulas were also set up in the tab so that it automatically informed recruiters what next step was needed to process a candidate's application.
-
Monitor KPIs and metrics that reflected our Progress-to-Target as a team. With the use of excel formulas, I set up our KPI tab so that it automatically generated a report on where the team was at an aggregate level in terms of meeting its targets in each stage of the admissions process, and report on how each individual team member was performing in terms of converting their assigned recruitment sources into accepted offers. One major feature I also sought to include was the use of pipeline projections that were updated real-time based on historical conversion rates and our active candidate pipeline. Regularly including projections for our progress on a monthly and end-of-year basis allowed us to make informed decisions on how we may need to adjust certain aspects of our operations and strategy.
A sample section from our Candidate Information tab. This is the main tracker that recruiters would review on a regular basis when processing their candidates. The sections in gray are all data points that are pulled in from Salesforce using SQL Queries. The sections in orange are automated using nested IF Functions to inform recruiters where in the Admissions process their candidates are, and what the next steps for them should be.
A sample section from our KPI tab. This is the main tracker that summarizes our performance as a team in relation to meeting our End-of-Year targets. The cells are color-coded using conditional formatting so that you can quickly eyeball which stages were converting within our expected range and which stages we were underperforming in. I also set up a model that automatically calculated scenarios for our end-of-month and end-of-year projections so that we can make informed decisions about how we may need to pivot our operations and our strategy.
ONBOARDING AND TRAINING
​
When all of the tools were successfully finalized, I then proceeded to onboard and train the different members of my team on how to utilize all of the tools in time for the launch of a new application period. During the sessions I conducted, I ensured there were clear guidelines in place in how to utilize each of the tools and how to troubleshoot should any problems arise. During these sessions, we tested the use of the tools to see if any challenges arose and made several iterations on the design based on the team's feedback on how to make it more user-friendly. Finally, I concluded this project by ensuring this was documented in a user manual that can be shared for future reference.
Project Outcome ​
​
As a result of the project, we were able to have a fully functional data management system that has since been utilized by the Admissions team. This system of monitoring our Admissions data has allowed for more consistent reporting and more effective alignment on our metrics and KPIs. Moreover, given the removal of several redundancies in our process, we were also able to become more efficient in processing applications.
​
The way our data management system was set up also reflective of a new direction that the team was taking in terms of its structure. From operating as 2 separate sub-teams under Admissions, members of the team now focused on an end-to-end Admissions process (i.e. Individuals taking on both recruitment and selection simultaneously). This allowed for a more effective candidate experience which was supported by the use of our updated data management system.
​
Overall, the project showed that with the right systems in place to utilize it correctly, data can be incredibly value-adding in driving decisions for teams in both a strategic and operational level.