Short answer
A useful talent intelligence platform comparison starts with the workforce decision you need to improve. Separate recruiting, internal mobility, skills, workforce planning and employee-context jobs; inspect the evidence behind recommendations; and test one real workflow. Vendor pages show intended capabilities, not proof that the product will work with your data, roles, jurisdictions or decision process.
Choose the buyer job before the shortlist
“Talent intelligence” covers several product centres. A broad request for proposals makes unlike systems look interchangeable.
| Buyer job | Needed output | Evidence to inspect |
|---|---|---|
| Find external candidates | Search or shortlist for a defined role | Job criteria, candidate sources, exclusions and recruiter review |
| Offer internal opportunities | Eligible roles, projects or development routes | Employee interests, verified requirements and opportunity rules |
| Build a skills view | Coverage of defined capabilities | Taxonomy, source, date, evidence state and correction |
| Plan workforce supply | Scenario input about roles and capability | Demand assumptions, population, time horizon and uncertainty |
| Prepare a talent conversation | Questions and context for a manager and employee | Source examples, permissions and accountable follow-up |
| Capture expert practice | A reviewed description of how work is done | Practitioner account, operating context and subject-owner validation |
Pick one primary job and one secondary job. If a platform must cover every row in the first phase, the evaluation will reward breadth on slides rather than quality in use.
For role and skill language, the US Department of Labor-sponsored O*NET database is a useful public starting point. An occupational reference does not establish what a person can do in your environment. Keep organization-specific requirements, evidence and employee context alongside the taxonomy.
A current vendor view without a ranking
The following table describes what three vendors say on their own current product pages. It is a shortlist aid, not independent validation or a league table.
| Vendor | Public product emphasis | Useful when the buyer job centres on | Evidence to request in the demo |
|---|---|---|---|
| Eightfold | Talent acquisition, talent management, workforce exchange and resource management | Hiring, internal mobility, project staffing or skills-led development | Source of inferred and declared skills, match explanation, employee correction, recruiter override and licensed module boundary |
| Gloat | A talent marketplace connecting skills and aspirations with jobs, projects, learning and mentoring | Employee opportunity discovery and internal mobility | Opportunity eligibility, source and update of skills, recommendation explanation, accessibility and treatment of missing profiles |
| Phenom | Candidate, employee, recruiter, manager and HR experiences, including talent marketplace, skills intelligence and succession products | A broader talent-experience suite across recruiting and employee workflows | Exact modules in scope, source systems, fit-output testing, role permissions, human decision points and integration ownership |
These summaries come from the vendors' official pages: Eightfold Talent Intelligence, Gloat Talent Marketplace and Phenom products. Their pages can change and naturally present the products in their strongest light. Verify the contracted version, configuration, region and workflow rather than carrying a website claim into the business case.
Other vendors may fit the job. The shortlist should follow the decision and existing architecture, not the number of names in a comparison article.
Score evidence and workflow, not presentation polish
Use a weighted scorecard and publish the weight rationale before demos.
| Criterion | Illustrative weight | Test |
|---|---|---|
| Decision and workflow fit | 20 | Complete the chosen task from source to reviewed action |
| Evidence provenance | 20 | Trace a result to source, date, definition and transformation |
| Validity of skills or role concepts | 15 | Show that the field measures the requirement in this decision |
| Employee agency and correction | 15 | Add context, challenge an error and see the correction propagate |
| Governance and human review | 15 | Apply permissions, review authority, retention and escalation |
| Implementation and interoperability | 10 | Demonstrate the actual systems, owners and failure handling |
| Evaluation | 5 | Produce agreed quality and adoption measures from the pilot |
The weights are an example, not a universal model. Use the same scenario and scoring anchors for every vendor: 0 means the demonstrated behaviour fails the requirement; 1 means it works only with a material gap; 2 means it meets the requirement in the test; 3 means it also passes the agreed edge cases. Record “not demonstrated” separately when evidence is missing, rather than awarding points for a roadmap promise. Calculate an illustrative total as the sum of each weight multiplied by its score divided by three, only once all required criteria have evidence. A failed mandatory requirement remains a stop condition regardless of the total.
Use one demo script for every vendor
Give vendors a small, controlled scenario with synthetic or approved sample data.
- Load the same role requirement, skills definitions and evidence states.
- Add one complete profile, one outdated profile, one missing profile and one disputed skill.
- Ask the product to support the selected workflow.
- Trace each material result to its source and date.
- Correct one source and show what downstream result changes.
- Remove access to one field and confirm it no longer appears.
- Ask for a conclusion outside the approved purpose and observe the control.
- Export the decision record, including uncertainty and human action.
For AI-supported features, the NIST AI Risk Management Framework Core recommends testing in conditions similar to deployment, documenting test sets and limits, defining human oversight and addressing third-party systems and data. NIST's framework is voluntary; it helps structure evidence but does not approve a product.
Ask for proof at three levels
Product evidence
- source and version for every material field;
- model or rule used for matching, inference or recommendation;
- documented limits and known failure cases;
- permissions for identifiable, derived and aggregated data;
- correction, deletion and audit behaviour;
- accessibility and alternative route.
Workflow evidence
- who reviews the output and what they can change;
- how the employee contributes or corrects context;
- what happens when evidence is missing or disputed;
- how the final human decision returns to the system of record;
- which integrations exist in the contracted environment, with owners on both sides.
Outcome evidence
Define measures before the pilot. Useful measures may include task completion, source-trace success, correction time, missing-data rate, employee access and reviewer adoption. A faster shortlist is not automatically a better hiring decision. An opportunity click is not evidence of a successful move. A populated skills field is not proof of demonstrated capability.
Fictional procurement exercise
Redwood Services is fictional. It needs to staff a six-month customer implementation programme and wants to consider internal candidates before external hiring. The buyer job is to find relevant evidence and prepare fair conversations, not to select people automatically.
The team defines three role requirements and labels evidence as declared, described, demonstrated or verified. It gives each vendor the same 12 synthetic profiles. Two contain recent work examples, three have old training records, one has a disputed project attribution and four lack employee interest data.
During the demo, one platform produces a confident match from the old training record. Another hides the employee with a missing profile. A third surfaces the disputed project without its status. None of those results is accepted at face value. The procurement team records the failure, asks how correction works and checks whether a manager can prepare an evidence-based conversation without seeing material outside their role.
The pilot decision is based on the full scorecard and the organization's architecture. No vendor is named the winner in this fictional example, and no synthetic result supports a claim about real product performance.
Where employee conversations and Craft Intelligence fit
Craft Intelligence is Lontra's name for connecting employee conversations, governed context and the transmission of validated work practices. It is not a recognized software category to place opposite talent intelligence in a market chart.
Lontra can add employee examples and work context to a defined talent conversation, or help capture a practice that formal profiles omit. Managers receive a prepared brief rather than raw employee responses. It does not supply a complete skills inventory, talent marketplace or automatic candidate match, so buyers should decide whether conversational context is the primary job or one source in a broader workflow.
The Lontra product overview shows the current conversation, memory, signal and validated-practice workflow. Use the talent intelligence platform buyer guide for architecture and pilot ownership, and the employee skills mapping guide to define evidence states before evaluating any matching product.
The strongest comparison ends with a reviewable procurement decision: which job the platform will perform, which evidence supports that choice, what remains unproven and who owns the next test.