Can We Staff This Project? Answering It From Data You Already Have

A client asks whether you can take on a project that needs Postgres, Kubernetes, React, a bit of data engineering and someone who can run a client workshop. Somebody in the room says "yes, probably" and the quote goes out. Three weeks later it turns out the one person who actually knows Kubernetes is serving notice.

For a services company of fifteen to eighty people, this question -- can we staff this, and with whom -- gets asked constantly and answered from memory every single time. The information exists. It is spread across a delivery lead's head, an old spreadsheet, and the resumes of people you hired two years ago.

Why this belongs in a hiring product

It belongs here for one reason, and it is a good one: the skills were already parsed.

Every application that comes through ShortlistAI is parsed into structured resume data, including a skills breakdown. When a candidate reaches the Joined stage, the system already knows what they said they can do. So marking somebody as joined adds them to the capability map automatically, with their skills filled in.

That is the whole trick. Capability maps in HR suites fail because they are another form somebody has to fill in, and nobody does. This one populates as a side effect of hiring. An HR suite bolted onto payroll cannot do that, because payroll never saw the resume.

Skills that arrive this way are marked as coming from a resume, with no assessed level. Nobody has confirmed any of it. The map shows that distinction rather than presenting a parsed CV as assessed fact -- a skill listed on a resume and never verified is genuinely weaker evidence than a manager's assessment, and a capability map that pretends otherwise is worse than no map.

The import is capped at 60 skills per person. A resume listing eighty skills is padding, and importing all of it drowns the real signal.

Not an HRIS, deliberately

Stated plainly, because the scope creep here is obvious and worth refusing: this records capability. No payroll, no attendance, no leave, no compensation history. Those belong to Keka and greytHR, and they bundle recruitment alongside them. This is the other direction -- a hiring product that knows what the company can do, because it watched the company hire.

The people list is also deliberately separate from your logins. Most employees in a capability map have no reason to hold a seat in a hiring dashboard: the delivery lead recording who knows Kubernetes is not thereby giving all of them access to salary data on live candidates. A person can have both, and they are linked when they do, but neither requires the other.

What the map gives you

Everyone's skills roll up into a per-skill view. For each skill you see who holds it, how deep the bench is, and how much of that depth is one person.

The rules that matter:

• People who have left are excluded from the holder count entirely. A capability map that counts former employees answers the question wrongly, and wrongly in the dangerous direction.
• Availability separates "active" from "serving notice". Someone on notice still holds the skill; they are not available to staff next month's project.
• A skill only one available person holds is flagged. This is not a nice-to-have metric. It is the main thing a capability map exists to reveal, and it is the thing everybody discovers at the worst possible moment.
• Skills people are working towards are tracked separately from skills they hold, so a growth plan never inflates your apparent capacity.

Four numbers sit at the top: how many people, how many distinct skills, how many skills rest on one person, and how many skills nobody currently holds but somebody is learning.

Answering the actual question

The coverage box is the part that answers a client email. Paste the skills a project needs -- comma or line separated -- and you get back the gap rather than a yes or no:

• which of them you have covered, and by whom
• which you have nobody available for
• which are covered but by exactly one available person
• and the coverage percentage

"We have four of six" is the useful shape. It tells you what to subcontract, what to hire for, and which single dependency to de-risk before signing. A yes/no verdict would have hidden all three.

Getting started without typing anything

If you have hired anyone through a job post in ShortlistAI, there is a page listing every person you marked as joined who is not yet on the map, so adding them is one click each with skills pre-filled. People already added are filtered out of that list -- a list that keeps suggesting someone you added is noise.

Anyone else -- your founding team, people hired before you started using the product -- you add manually with a name, and optionally a title, department, email and joining date. Skills are free text. There is no controlled vocabulary on purpose: every company names things differently, "React" and "ReactJS" and "React.js" are all somebody's house style, and forcing a taxonomy on entry is exactly how these inventories end up empty. Grouping happens on a normalised key behind the scenes; what you typed is what you see.

Reading the map is open to every member of your organisation, viewers included -- the point is that colleagues can see the company's capacity. Editing requires more than viewer access.

Adding people and their skills goes through the Advanced Hiring API, so it needs the Business plan or above, the same as the rest of the hiring toolkit.