Build a Searchable Talent Pool for Every Role

Talent pool management software is a searchable candidate database that recruiters own, maintained so past applicants, sourced profiles, and imported contacts can be reused for future roles instead of re-sourced from scratch.

The distinction that matters is between a list and a pool. A spreadsheet of candidates is a list: it goes stale, it is not searchable by skill or availability, and nobody opens it when a new role opens. A talent pool is queryable: filter by tech stack, minimum experience, required and nice-to-have skills, location, job type, and whether someone is open to opportunities, and it connects to an action, so a recruiter can move from search result to job invitation without leaving the workflow.

In Edvenity, talent pool management covers both sides of that: discovering candidates you have never contacted, and rediscovering the ones you already have.

Edvenity separates the candidates you are discovering from the candidates you own.

The global pool is for sourcing outward. Search across a wider candidate network with a plain-language query, then narrow with filters for tech stack, minimum experience, required skills, nice-to-have skills, locations, job types, and availability. Results carry a relevance score against the criteria you set, so a shortlist can be assembled before anyone opens a profile.

The local pool is the recruiter-owned database: everyone imported by CSV, every parsed resume, and every past applicant. It is organised into candidates and resumes, searchable with the same filters, and filterable by date range and import batch so a specific intake can be found months later.

Most recruiting tools do one or the other. Sourcing platforms find new people but do not retain them usefully; applicant tracking systems store past applicants but make them hard to search. Keeping both in one place is what makes rediscovery cheaper than sourcing.

Import runs in four steps: choose the import type, upload the file, name the batch, then map and validate the fields before anything is written.

The mapping step is the one that decides whether an import is usable later. Columns from a spreadsheet or a legacy system are matched to structured candidate fields, and the result is reported per record as created, updated, skipped, or failed, so a partial import is visible rather than silent. Naming the batch is what makes an intake findable afterwards: months later a recruiter can filter to that batch instead of searching the whole database.

Resume archives import the same way, with files parsed into candidate profiles. Parsed resumes are tracked as linked or orphaned, so files that never matched a candidate record surface as a fixable gap instead of disappearing.

Candidate rediscovery is searching people you have already sourced or who already applied, before spending on new sourcing for a role.

The economics are the argument. A candidate who applied six months ago has already been screened once, has known context, and costs nothing further to reach. A new sourced candidate costs job board spend, outreach time, and a cold start. Most recruiting teams re-source anyway, because the previous applicants are spread across old job posts, inboxes, and spreadsheets where nobody can query them by skill.

Rediscovery in Edvenity works because the local pool is searchable with the same filters as sourcing, and because a rediscovered candidate can be selected, matched to an open job, given customised outreach, and invited without being re-entered anywhere.