Tools for HR Professionals: The Permission Model Is the Purchase

The mistake HR teams make after they buy

An HR team evaluates HR help desk software the way it evaluates any enterprise tool. It looks at feature lists, checks the AI capabilities, reads the automation options, and requests a demo. It picks a product it likes and signs an annual contract.

Six months later, someone in the team asks the question that surfaces the gap: "Can we make sure the disciplinary hearing correspondence is only visible to the HR team and not to every employee who raises a general query?"

The answer from the software is usually yes, up to a point. Restricting an agent to their own group's tickets is there at the entry tier on every platform in this comparison. What is not there is the shape HR actually needs: one named person who may read a case that their own group must not, which is a custom role, and custom roles sit further up the ladder. The team bought customer service software. What it needed was HR-grade access control.

This is not a rare problem. It is the most common post-purchase discovery in HR help desk deployments, and it is avoidable if the permission model is the first question rather than the last.

Why HR needs a different permission model

A customer service help desk is built on one assumption: agents handle tickets from people outside the organisation. Visibility is all-or-nothing. A supervisor can see everything their agents can see, or they cannot.

HR work runs in reverse. The majority of HR queries should be visible to every employee: holiday entitlement, flexible working policy, parental leave process, who their line manager is, what the onboarding checklist looks like. A minority of tickets name an individual and must not be visible to anyone outside a small HR group: a disciplinary matter, a salary review, a grievance, an occupational health referral, a reasonable adjustments conversation.

Most help desk platforms are built for the first model. The permission architecture that HR needs is the inversion of it, and that inversion costs more on platforms where it is gated.

Questions that must split by audience

Before evaluating software, write down the split. For a team serving 2,000 employees, a typical distribution looks like this:

• Visible to all employees: policy questions, published guidance, general how-to, team directory queries, benefits information, absence notification procedures.
• Visible to the HR team and the individual: occupational health appointments, grievances, performance improvement plans, flexible working applications.
• Visible to an employee's manager and the HR team: leave approvals, absence records, probation reviews, salary review input.
• Visible only to named HR individuals: disciplinary correspondence, settlement discussions, restructuring plans, recruitment shortlisting before an offer is made.

At any given time, the proportion that requires restricted visibility varies by organisation and by what is in flight. The platforms in this comparison charge different amounts for the ability to enforce that split, and the difference is not always visible on the front page of the pricing table.

The published price ladders

All figures are per agent per month when billed annually. Prices are taken from each vendor's own pricing page, checked September 2026.

The Asyntai row is ours. Read it as a disclosure. We make Asyntai, so the comparison of access controls is based on published product descriptions, not on our inference about a competitor's roadmap.

What the annual bill looks like for a 10-agent HR team

The team is 10 people. They need visibility controls. The question is not what the entry price is. It is what the tier with the controls actually costs.

For reference, Freshdesk Pro for the same 10-agent team costs $6,600 per year, and that is the tier that adds custom roles rather than basic scope. Asyntai Pro, which carries all ten seats, costs $5,388 per year for the same team. The difference in billing model is the key distinction: per-seat pricing multiplies by every agent, while Asyntai steps once at the seat block and once at the message allowance.

Why the billing model changes what you pay at scale

Per-seat pricing means the annual cost is the per-agent rate multiplied by headcount. If the HR team grows from 10 to 15 agents, the Freshdesk bill rises proportionally. The Asyntai bill does not change because of headcount; it changes only if message volume crosses a plan threshold.

For a team evaluating tools, the relevant comparison is not entry price against entry price. It is the tier with visibility controls against the tier with visibility controls, at the team size you have today, with headcount growth factored into the contract year you are signing.

At 20 agents, the annual cost comparison shifts further:

The architecture difference that a price table does not show

Every platform in this comparison can technically restrict ticket visibility. The difference is where in the product that restriction lives and what it can express.

On platforms built for customer service, visibility is typically a ticket-level flag: public or private. A ticket is created, and someone decides whether it is visible outside the assigned group. This works for most customer service use cases. For HR, it creates a structural problem: if every ticket starts as potentially private, general questions that should be visible to all employees require active work to publish. Over time, the system becomes a repository of restricted items, and the public knowledge base that employees actually need stops existing.

Asyntai uses per-tab permissions and per-website scoping. Tabs are configured separately. A general HR tab can be set to allow full employee access by default, while a case management tab restricts access to named HR agents. This mirrors how an HR team actually works: a public-facing policy section and a private case-handling section, with different audiences and different access rules, not one queue with a visibility toggle on each ticket.

The practical difference appears in onboarding. When a new employee starts, they need access to the general HR tab immediately. They do not need access to case management. With per-tab permissions, that access is granted by default for the right tab without configuring individual ticket restrictions. On a platform where every ticket is a separate visibility decision, the same outcome requires either leaving the system open (wrong) or setting defaults that someone must maintain (error-prone).

What to do before signing a contract

The steps below apply whether you are buying for the first time or renegotiating a renewal.

1. Name the tier that gates visibility controls. Ask each vendor directly: at which tier does the ability to restrict who reads a ticket appear? Get the answer in writing. Treat that tier's price as the actual entry price.
2. Calculate the annual cost at that tier for your team size today. Use the arithmetic above. Do not use the tier-1 figure if the controls you need are on tier 2 or tier 3.
3. Test the permission model with a real scenario. Create a general question that should be visible to all employees. Create a second question that should be visible only to HR. Check whether the platform enforces that split by default or requires manual intervention on every ticket.
4. Ask what happens to historical tickets when a plan changes. If you start on a plan without visibility controls and upgrade, are old tickets still open? Do they inherit the new restrictions? This is where data governance failures happen.
5. Check the audit log. HR work requires an immutable record of who accessed what and when. Asyntai includes an append-only audit log on Enterprise, where entries cannot be edited or deleted. Verify that your chosen platform's audit log entries cannot be edited or deleted after the fact.

The talent attraction problem nobody talks about

A help desk that cannot separate general HR information from personal casework has a secondary effect that is rarely discussed in procurement documents: it signals to candidates and new hires that the organisation does not have a clear separation between its people processes and its case management.

Candidates who interact with the HR function during recruitment notice whether they are being pointed to published policies or being asked to submit a ticket that will sit in a queue alongside someone else's disciplinary matter. The tools for talent acquisition and the tools for HR operations are not the same product, but they share a user experience, and that experience communicates something about how the organisation handles information.

The permission model matters for the employer brand as much as it matters for the data governance requirement. Tools that enforce the split cleanly present a more professional HR function to every employee who uses them.

Moving from a tool built for customers to a tool built for employees

If your team is already mid-contract on a customer service platform and has discovered the permission gap, the options are:

• Renegotiate the contract. Request visibility controls be added to the current tier, or negotiate a move to the tier that has them. Use the annual cost comparison as leverage.
• Run two systems in parallel. Keep general HR queries on the current tool (visible to all employees). Route restricted casework to a separate system with proper access controls. This is operationally inconvenient but avoids a full migration.
• Migrate. If the permission model cannot be fixed at a reasonable tier, the cost of migration is the cost of being on the wrong platform. Calculate it against the years remaining on the contract and the ongoing cost of the workarounds.

The question to ask of any vendor at renewal is not "what features are included" but "which tier gates the access control we need, and what does that tier cost for our team size". The answer determines whether the product is suitable for HR work at all.

Summary

Permission models are the real purchase decision for HR teams. All three per-agent tools restrict who reads a ticket at their entry tier, which is $2,280 a year for 10 agents. The gap opens at the next question: a custom role on Freshdesk is Pro, $6,600 a year, and on Zendesk it is Suite Enterprise, which is quote only. Asyntai includes per-tab permissions and per-website scoping, and its Pro plan carries all ten seats at $5,388 per year with no per-seat multiplication.

The architectural question is not whether visibility can be restricted, but whether the default for a general HR tab is open access and the default for a case management tab is restricted access, rather than the reverse. A platform that starts every ticket as potentially private forces active work to make things public. A platform with per-tab permissions enforces the right default for each use case automatically.

Before signing any contract: name the tier that gates visibility controls, calculate the annual cost at that tier for your team size, and test the permission model with a real general question and a real restricted question side by side.