HR People Analytics Software: What It Does, What to Buy, and Where It Breaks

HR people analytics software connects to your HRIS, ATS, payroll, and engagement survey tools, keeps a dated history of every employee record, and turns that into headcount, attrition, hiring funnel, compensation, and representation reporting without anyone exporting a spreadsheet. The useful ones do three things that a standard report inside your HRIS usually does not: they keep effective-dated history so you can ask what the org looked like in March instead of only today, they join records across systems that share no common key, and they enforce row-level permissions so a department head sees their own team and not the whole company's salaries.

There are three ways to buy it, and the right one depends mostly on headcount and whether you have anyone who can maintain a data pipeline. Under roughly 300 employees, the reporting already inside your HRIS is usually enough and a dedicated platform is overkill. Between 300 and about 3,000, a dedicated people analytics platform earns its price because you now have enough history for trends to mean something and enough systems that joining them by hand has become someone's part time job. Above that, or anywhere there is already a data warehouse, the cheapest and most flexible answer is usually to land HR data in the warehouse alongside everything else and use the BI tool the rest of the company already uses.

The three categories compared

The trap in the third column is real. A warehouse-based HR model is the most powerful option and the most likely to quietly rot. If no one owns the dbt models, the attrition number drifts from the one finance uses and both get quoted in the same board meeting.

What you get on day one

Every product in all three categories will give you the same starting set: headcount by department, location, and manager; joiners and leavers by month; voluntary and involuntary attrition; time to hire and time to fill; span of control and management layers; compensation distribution and pay ratios; representation by level. Engagement scores show up if you feed in survey data from a tool like Culture Amp or Perceptyx.

That list is table stakes, so it is a bad basis for choosing. What separates products is what happens when you ask the second question, the one that starts with "why".

Where the simple answer breaks

Two analysts can compute attrition from identical data and get different numbers

Take a support team. It started the year with 40 people, ended with 60, and 9 people left during the year. Three of those exits were performance-related.

Same nine people, four defensible numbers, a range wide enough to change whether anyone acts. In a fast-growing team, the denominator choice matters more than anything that happened to the humans. Before you evaluate any software, write down your definitions: the denominator, whether contractors and interns count, whether an internal transfer out of a team counts as attrition for that team, and what makes an exit regretted. Then check that the tool lets you configure all four. Some do not let you change the denominator at all.

Time to hire has the same problem. Measured from requisition approval, from the candidate's application date, or from first recruiter screen, the same hire produces three durations. A vendor demo that shows "23 days" without naming the start event is showing you nothing.

Small numbers make most cuts meaningless

At 200 employees, a department of 12 that loses 2 people posts 17% attrition and looks like a crisis. One of them moved cities. There is no signal there. The practical rule is to stop cutting when a cell drops below roughly 15 to 20 people, and to set a suppression threshold for any demographic breakdown so that a group of 3 is never displayed, both because the number is noise and because it identifies individuals. Check whether the tool supports suppression thresholds natively. Rebuilding that logic in a BI layer after the fact is tedious and easy to get wrong.

Your HRIS may not remember what it used to say

Many HR systems store current state and overwrite it. A person who moved from Sales to Customer Success in June can appear to have always been in Customer Success, which silently rewrites every historical headcount chart. Ask two questions of any system you are buying or already own: does it keep effective-dated records with a valid-from and valid-to, and can I retrieve the org as of an arbitrary past date. If the answer is no, the fix is to snapshot the employee table on a schedule into your own storage, starting now, because you cannot recover history you never captured.

Nothing joins your systems for you

A single person exists as a candidate in your ATS, an employee in your HRIS, a user in your identity provider, a payee in payroll, an assignee in your ticketing system, and an account in Slack. Those records rarely share a key. Work email is the usual join, and it breaks on name changes, on rehires, on contractors converted to employees, and on anyone whose ATS record used a personal address. Budget real time for identity resolution. It is the single largest hidden cost in every people analytics implementation, in all three categories, and it is why "two week deployment" claims tend to mean "two weeks after you hand us clean mapped data".

Access control is the hard part, not the charts

People data is the most sensitive dataset most companies hold. A workable model has at least four tiers: HR business partners see their supported groups, managers see their own reporting line down to some depth, executives see aggregates across the company, and compensation detail is restricted separately from everything else. Ask specifically how the tool derives the manager hierarchy, what happens on the day someone changes manager, and whether permissions are enforced at the data layer or only by hiding a dashboard tile. Hidden tiles are not security.

Questions worth asking a vendor

• Show me the same attrition metric with three different denominators, changed live in the product.
• What happens when I ask a question your data model does not cover. Can I add a table.
• Where do effective-dated records come from if my HRIS does not provide them.
• How do you resolve one person across the ATS, HRIS, and payroll when emails differ.
• What is the suppression threshold, and who can override it.
• If we leave, do we get our modelled history back, and in what format.

The questions the dashboard cannot answer

Every category above is good at counting and bad at explaining. Suppose support attrition really is 18% and rising. The dashboard tells you that. The reason is in the exit interview notes, in the Slack thread where three people complained about the on-call rotation six weeks earlier, in the Zendesk queue depth that doubled in March, and in a manager's 1:1 doc. BI tools connect to databases and modelled sources, so evidence that exists as a sentence in Slack, an email, or a document is outside what they can see. That is not a flaw in the software. It is a boundary, and knowing where it sits stops you from buying a more expensive dashboard to solve a problem no dashboard has.

Working across the tools where the evidence lives

Skopx sits on the other side of that boundary. It connects to nearly 1,000 tools, including Slack, Gmail, Greenhouse, BambooHR, Workday, Zendesk, and Jira, plus direct connections to PostgreSQL, Snowflake, and BigQuery, and answers questions in chat with citations back to the source. So you can ask what the six people who left support in Q2 said in their exit interviews, and get the passages rather than a count. Its Internal Apps feature builds a read-only console from a sentence typed in chat, for example a headcount and attrition view joined to open requisitions, with an action button that requires a confirmation before it does anything. It stores nothing of its own: no forms, no records, no writes back to your HRIS. Team is $16 per seat per month with 2.3 million AI tokens included per seat. If you want the mechanics, see Internal Apps.

Buy people analytics software to count accurately. Solve the explaining separately, and be clear with yourself about which problem you are actually trying to fix before the first demo.