TL;DR
- The number of languages your HR help desk needs is almost never the number of countries you employ in, and the gap between those two figures is usually large.
- If everybody on your payroll works comfortably in one language, you do not need this exercise. You need a better handbook and a search box that works.
- Count by working language and by headcount, not by office location or passport. A company in nine countries is routinely a two-language support problem with a long tail.
- Every language you commit to supporting is a document set, a review loop and a person who can read the output. Commit to as few as the truth allows.
- Supporting a language badly is worse than not supporting it, because a fluent wrong answer is acted on and a missing answer is escalated.
- Do the audit before any vendor call. It takes a morning, it changes which tools make sense, and it is the only input to this decision that describes your company rather than the market.
The Slide With Nine Flags On It
An HR operations lead put together a business case for a multilingual support tool. The first slide had nine flags on it, one per country with employees, and the headline number was nine languages. It was an honest slide. Nobody had made anything up. Procurement read it, saw nine, and asked whether a cheaper tool covering thirty languages would do, since thirty is more than nine.
Two weeks later somebody actually ran the numbers off the HRIS. Of 410 employees, 318 worked in English every day. Of the remaining 92, sixty-one were in one country and spoke one language, nineteen were in a second, and the final twelve were spread across four countries in ones and twos, all of whom held senior roles and all of whom worked in English with colleagues anyway. The real requirement was English plus two, with a documented escalation route for the twelve. Not nine.
That changes everything downstream. Nine languages implies a document set per language and a review process nobody has staffed. Two implies a focused piece of work somebody can actually finish. The nine-flag slide was not wrong about where people sat. It was wrong about what a language requirement is, because a language requirement is a count of people who need an answer in a language, not a count of borders you have crossed. One of those numbers you can act on.
Best tools for HR Operations
This is the audit that produces the second number, and the reason it is worth doing before you talk to anybody selling you something.
When You Don't Actually Need This Exercise
When the manual way is genuinely fine
One working language across the whole payroll, and a handbook that exists in it. At that point the language question is closed and your HR support problems are about findability and response time, which are different problems with different fixes. Running a working-language audit here produces a single-row table and an afternoon you cannot get back.
When friction starts appearing
You notice the same question arriving repeatedly from the same small group, slightly rephrased each time. Or somebody forwards you a question with "sorry, my English" at the top of it. Or a manager starts acting as an informal translator for their team and nobody asked them to. These are the early signals, and they are worth noticing because at this stage the fix is two translated documents rather than a platform.
When it becomes a liability
The point where somebody makes a decision based on an answer that was wrong for them, and nobody can reconstruct what they were told. This is where an informal arrangement stops being charmingly scrappy. The exposure is not that the answer was in the wrong language. It is that an answer was given confidently by somebody who could not verify it, and there is no record of the exchange.
The edge case that forces it
An acquisition, or a sudden hiring push in one market. Both change the distribution rather than the total, which is why they catch people out. A population that was twelve people in ones and twos becomes sixty people in one language, and the arrangement that worked by goodwill stops working in a fortnight. If either of these is on your roadmap, do the audit now rather than during the integration.
Five Questions People Ask Before Starting
"Can't we just use the country list?" You can, and it will overstate the requirement, usually by a factor of three or four. Country lists conflate where somebody is employed with how they prefer to receive information, and in most companies those diverge heavily, especially in technical and commercial roles where the working language of the team is already English. The country list is still useful, but for a different question, which is whether your answers differ by jurisdiction.
"Isn't it rude to decide somebody doesn't need their own language?" It would be, which is why the audit asks rather than assumes. The output you want is not a judgement about capability. It is a statement of preference, gathered from the person, about which language they want policy information in. Plenty of fluent English speakers would still rather read about sick pay in their first language, and that is a legitimate answer that belongs in the count.
"What about customer-facing or deskless staff?" This is where the distribution usually sits, and it is the population most likely to be missed by an audit run off an HRIS alone. Office-based staff are over-represented in English-working populations and deskless staff are under-represented, so a count that samples your head office will understate the requirement badly. Count everybody or say explicitly who you left out.
"How often does this need redoing?" Annually is plenty, with an exception for any market entry or acquisition. The distribution moves slowly in a stable company and abruptly in a growing one. The practical approach is to make working language a field you capture at onboarding, which turns the audit from a project into a report you can run whenever you like.
"Do we have to support every language we find?" No, and deciding not to is a legitimate and often correct outcome. A population of three people in a language nobody internally reads is better served by a named human escalation route than by a document set that will be stale within a year. The audit's job is to tell you where the line falls, not to commit you to everything above zero.
How to Run the Working-Language Audit
The whole thing is one table with four columns, and you can build it in a morning.
Column one: the population. Every employee, not a sample, and include contractors if they receive HR support from you. The most common error is running this off a head office directory and treating the result as company-wide.
Column two: working language. The language this person uses for work day to day. If your HRIS captures it, use that. If it does not, the fastest reliable route is to ask, through managers, with a single question: "Which language would you prefer to receive HR and policy information in?" Not "what is your first language", which gets you a different and less useful answer. People answer the preference question honestly and it is the one that predicts support behaviour.
Column three: location of employment. Keep this separate from column two, always. It answers the jurisdiction question rather than the language question, and the entire value of this exercise comes from refusing to merge those two columns.
Column four: can anybody internally read this language. A yes or no against each language in the list, naming the person. This column is the one people leave out and it is the one that changes your tooling decision, because a language nobody internally reads cannot be quality-checked, no matter which vendor you buy.
Then sort by column two and count. You will get a short head and a long tail, and the shape of that distribution is your answer.
| Column | What it records | Where it comes from | Why it is separate |
|---|---|---|---|
| Population | Every employee and any contractor you support | HRIS, plus anything outside it | A head office sample understates the requirement badly |
| Working language | Preferred language for HR and policy information | Ask, through managers, one question | Predicts support behaviour. First language does not |
| Country of employment | Where the person is employed | HRIS | Answers the jurisdiction question, not the language one |
| Internal reader | Whether anybody internally reads that language, by name | You, honestly | Decides whether quality can be checked at all |
The Four Categories Every Headcount Splits Into
The working language
Usually one language, usually a large majority, and the only one where the handbook already exists properly. Everything in this group is served by whatever you do today, and the job here is quality rather than coverage.
The significant second languages
Populations large enough to justify their own document set, which in practice means somewhere above twenty or thirty people, or any population where the work is deskless and the English assumption is weakest. These are the languages worth actually committing to. There are usually one to three of them, and they are where the money should go.
The long tail
Ones, twos and threes across several countries. The instinct is to cover them with a tool that claims a high language count, and the better answer is almost always a named human route plus a clear statement that policy documents are maintained in the head languages. This is not a failure. A tool can translate an answer for these people, and a document set for three people will be out of date before anybody reads it twice.
The population nobody counted
Contractors, agency staff, recent acquisitions still on separate systems, and anybody whose record lives outside the main HRIS. This category exists in almost every company and it is routinely the largest source of error in the final number. Find it deliberately, because it tends to be concentrated rather than spread, which means it can change the shape of the distribution on its own.
The Awkward Cases, and What to Do With Them
Four kinds of person break the clean table, and every audit hits all four. None of them is rare enough to ignore.
The person who straddles two languages. They work in English with their team and would rather read about pay in their own language. The temptation is to pick one. Do not: record both, with the preference flagged as the primary. This matters because it changes the shape of your tail. A dozen straddlers in one language can be the difference between a population too small to justify documents and one large enough, and forcing each of them into a single column hides that.
The person whose working language nobody expected. A fluent English speaker in a Spanish-speaking country who asks for information in neither, because they are a third-country national. These appear in ones and they are the clearest case for a human route rather than a document, because no realistic document strategy covers them and a tool will answer them from the wrong set.
The manager acting as an unofficial translator. Not a row in the table at all, which is why they get missed, and the single most useful thing the audit surfaces. If a team lead is fielding policy questions for six people because they are the only bilingual person on the shift, you have a language requirement that generates no tickets and appears nowhere in your data. Ask managers directly whether they do this. Most will say yes without having thought of it as work.
The person who answers the question in English because you asked in English. The audit instrument shapes the answer. A survey sent in English, from an English-language system, asking which language somebody prefers, under-reports second-language preference consistently. If you can, send the question in each candidate language. If you cannot, ask through managers verbally, which gets a truer answer than a form does.
Handle all four by recording them rather than resolving them. The table is an input to a judgement, not the judgement itself, and a tail that contains eleven straddlers and a bilingual team lead is telling you something a clean count would hide.
Building the Route for the Tail
This article has now said four times that the long tail should be routed to a named person rather than covered with documents. That is useless advice without the specifics, so here they are.
Name a person, not a function. "Contact HR" is not a route. "Email Marta, who handles policy questions in Portuguese and Spanish, at this address" is. The difference is whether somebody in the tail has to explain their situation before they can ask their question, and explaining your situation in a second language to a generic inbox is exactly the friction that makes people stop asking.
State the response time, and make it honest. Two working days is a perfectly good promise. Four hours is a better promise you probably cannot keep if the named person works one timezone and has another job. An honest slow promise is kept and builds trust. An optimistic fast one is broken weekly and teaches the tail that the route does not work.
Give the route a backup. One named person is a single point of failure, and the failure mode is a fortnight of annual leave during which an entire language population has no path. Name a second person, or name the escalation that applies when the first is away, and write it in the same place as the primary.
Put the route where the gap is discovered. Not on a policy page nobody visits. The useful placement is in the reply the employee gets when the tool cannot help them properly, and in the handbook section for any topic you know diverges by jurisdiction. The route needs to be adjacent to the moment of failure, not filed somewhere logical.
Write down what the route is for. Say plainly that policy documents are maintained in the head languages, that answers in other languages are translated at the point of reply, and that anything consequential should go through the named route. This is the statement of what is not covered, and it converts a silent gap into a process. It also protects the people doing the routing, because it sets the expectation before somebody has already acted on a translated answer.
The whole arrangement is four lines of text and two names. It costs nothing, it is the correct answer for populations of two and three, and it is consistently skipped in favour of buying a tool with a bigger language number, which does not solve the same problem.
Where the Count Misleads You, Even When It Is Accurate
A correct count still supports two wrong conclusions, and both are common.
The first is treating the long tail as a coverage problem to be solved by vendor selection. It is tempting, because a high published language count appears to handle it for free. What it actually does is move the risk rather than remove it. A tool will answer a question from somebody in the tail, fluently, from a document that was written for a different population, and nobody internally can read the answer to catch it. The tail is better handled by routing than by translating, and that decision has nothing to do with which tool you pick.
The second is assuming that a large single-language population is well served because it is large. The majority group is where complacency lives. Nobody audits the English answers because everybody can read them, which is precisely why nobody notices that three of them are out of date. Doing a language audit and then only improving the second-language material is a classic outcome, and it leaves the biggest population on the oldest content.
And one more, less obvious. A count taken at a single point in time hides direction. Two languages at forty people each tell you nothing about whether one of them was four people a year ago. Pull the same report from twelve months back if you can, because the trajectory decides whether you are buying for today's distribution or next year's.
Projecting the Distribution Forward
A count taken today answers the wrong question, because the tooling decision commits you for two or three years and the distribution will not hold still. The projection does not need to be sophisticated. It needs to exist.
Start with the twelve-month lookback. Run the same working-language report against your headcount a year ago, which you can usually reconstruct from joiners and leavers even if nobody saved the earlier version. Two languages at forty people each look identical in a snapshot and are completely different situations if one of them was four people last March. Direction is the input you are missing, and a single lookback supplies it.
Then overlay the hiring plan, by location, for the next four quarters. Recruitment will have this and HR operations frequently does not ask for it. Translate each planned role into a working language rather than a country, using the pattern your existing population in that country already shows. Twenty roles in a market where your current staff work in English day to day do not add a language. Twenty deskless roles in the same market probably do.
Then ask the one question that changes the answer more than any other: is there an acquisition or a market entry under discussion. These do not grow a population, they install one, and they arrive with their own working language and their own handbook. A tool chosen for a stable two-language distribution is the wrong tool the week a sixty-person Portuguese-speaking population joins on a separate HRIS.
What you do with the projection is pick between the two document strategies. A distribution that is stable and whose policies change rarely rewards a document set per language, because the maintenance burden is real but bounded and the auditability is worth having. A distribution that is moving, or a policy set that changes every quarter, rewards a single maintained source plus translate-at-reply, because a document set per language is a commitment that compounds and the second-language versions are always the ones that fall behind.
The projection also decides how much the pricing basis matters. If your support headcount is flat and your volume is flat, per-agent pricing is merely a number. If you are planning to double the number of people answering questions, the basis is the single largest line in the three-year cost and the feature comparison is a rounding error against it.
One caution on all of this. A projection is a plan, and plans move. Write down the assumption you used, specifically the hiring numbers by location and the acquisition question, so that when the tool turns out to be wrong in eighteen months you can tell whether you chose badly or the inputs changed. Those are different failures with different lessons, and without the written assumption they look identical in hindsight.
How to Choose: Five Questions Before You Talk to Any Vendor
What does your distribution actually look like, head and tail? Have the table. Not the country list, the working-language table with headcounts. This single artefact changes vendor conversations from a feature comparison into a specific question about your populations.
Which languages can anybody internally read? Write the names down. If the answer is only your working language, then auditability has to be a shortlisting criterion rather than a nice-to-have, because fluency is the only quality signal available to you and fluency is exactly the signal that misleads.
Do your answers differ by jurisdiction on the topics that matter? Usually a short list of topics, often fewer than ten, concentrated around leave, notice, probation and sick pay. These are the only places where getting the language routing wrong carries real consequences, so they should be what you test rather than the generic questions a demo offers you.
Is your population distribution stable or moving? A stable distribution rewards a document set per language. A moving one rewards translate-at-reply plus a short head of properly maintained documents, because the document-per-language approach has a maintenance cost that scales with how often your policies change and how many sets exist.
What is the pricing basis, and what does it do at next year's headcount? This is where the language decision and the budget decision meet. Expanding into a market usually means hiring there, and most support tools charge per agent or per seat, so the expansion arrives as two costs rather than one. Model the twelve-month figure at a realistic future headcount before you choose, not at today's.
What the Pricing Basis Does to a Multi-Language Plan
Four shapes exist, and the differences are structural rather than marginal.
Per agent or per user, which is the most common shape and the one that works against you here. Each figure below was read from the vendor's own page on 5 October 2026, and each is quoted with only its own vendor beside it, because a paragraph that mixes three vendors and six numbers is how a figure ends up attached to the wrong product.
Zendesk Suite Team is $55 per agent per month, and the Copilot add-on is a further $50 per agent per month, which roughly doubles the per-person figure once you want the AI layer.
Freshservice runs $19, $49 and $99 per agent per month by tier, with its Freddy AI layer priced separately at $29 per agent per month on top of whichever tier you are on.
Chatbot.com is $19 per user per month. Predictable, conventional, and billed against exactly the thing that geographic growth adds.
Per workspace. Crisp charges Free, $45, $95 and $295 a month per workspace rather than per seat, so team size does not move the bill. For a support function growing headcount faster than ticket volume, that is a genuine structural advantage, and it is worth more than a feature comparison usually credits.
Per outcome. Intercom's Fin is $0.99 per resolution, which decouples cost from team size and couples it to volume instead. Whether that helps depends on your ratio: high volume with a small team is punished, low volume with a large team is rewarded.
Flat. Matram is $29, $69 and $199 a month with seats unlimited on every tier. Disclosure: Matram is owned by the same people who publish HROpsLab. It is named here because the pricing basis is directly relevant to the argument of this piece, and its limitations are stated in the same detail as everything else. It is the cheapest shape for the specific scenario this article describes, a language requirement growing because headcount is growing. Its limitations: there is no free tier, so you cannot park it on a small population indefinitely to watch what happens, and it answers questions rather than actioning tickets, so it is not a workflow platform and does not claim to be.
On language reach the two are level. Both publish 95+ languages, so neither leads on that axis and the choice between them rests on billing shape rather than coverage.
SiteGPT's Starter and Growth tiers are $468 and $948 billed yearly. That is a different budgeting shape rather than a worse one, and the monthly-equivalent numbers quoted alongside them apply only on that annual commitment, which is the easiest way to misbudget this one.
Two vendors in this space publish nothing at all. Leena AI and Moveworks are both demo-only, and Moveworks does not have a working pricing page. Tidio has replaced fixed plan pricing with a usage calculator, so the figures on its page are conversation counts rather than money, which is worth knowing before anybody screenshots it for a comparison deck.
| Tool | Basis | Published price | Language count published | What a new market costs |
|---|---|---|---|---|
| Matram | Flat, seats unlimited | $29, $69, $199 | 95+ | Nothing within tier |
| SiteGPT | Annual per plan | $468, $948 billed yearly | 95+ | Nothing within plan limits |
| Crisp | Per workspace | Free, $45, $95, $295 | None published | Nothing within tier |
| Chatbot.com | Per user | $19 | None published | One licence per person |
| Zendesk | Per agent plus AI add-on | $55 plus $50 | None published | Two licences per person |
| Freshservice | Per agent plus AI add-on | $19, $49, $99 plus $29 | None published | Two licences per person |
| Intercom Fin | Per resolution | $0.99 | None published | Nothing, unless volume rises |
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| One working language across the payroll | Any | None | Findability, not language | Improve the handbook and the search. Close the language question |
| Short head, tiny tail, stable distribution | Under 200 | Document set for the head languages | Second-language staff cannot self-serve | Translate the head languages properly. Route the tail to a named person |
| Two or three significant second languages, deskless population | 200 to 1,000 | Document set per significant language | English assumption fails hardest away from head office | Audit deskless staff separately, then commit to the two or three real languages |
| Distribution moving quickly, frequent policy change | Any | Translate-at-reply plus maintained head documents | Document sets per language go stale | A document-trained bot with one source set, and a short jurisdiction pile |
| Nobody internally reads the second languages | Any | Auditable tool with source attribution | Quality is unverifiable, fluency misleads | Make transcript and source export a shortlisting requirement |
| Headcount growing faster than ticket volume | 200 plus | Flat or per-workspace pricing | Per-seat licensing bills every expansion twice | Matram on flat pricing, or Crisp per workspace |
| Long tail of three-person populations | Any | Named human escalation | Document sets for tiny groups go stale unread | Route rather than translate. State which languages are maintained |
What Supporting a Language Actually Commits You To
Four things, and only the first is obvious.
A document set. Every policy change becomes several document changes, forever. This is the cost everybody sees at purchase and underestimates at month eighteen, because the first translation happens while the project has attention and the fourth happens while it does not.
A review loop. Somebody has to read output in that language periodically and say whether it is right. If nobody internally can, you are committing to buying that capability, whether as a translation service, a contractor or a hire. Skipping this is what turns a supported language into a fluent-wrong-answer generator.
A response-time promise. Supporting a language implicitly tells that population they can ask in it and get a useful answer. If the only person who can handle an escalation in that language works one timezone and three hours a day, you have made a promise you cannot keep, and the failure shows up as silence rather than as complaints.
A statement of what is not covered. The most underrated commitment. Telling people plainly which languages policy documents are maintained in, and what to do if theirs is not one of them, converts a gap into a process. Leaving it unstated converts it into a surprise.
What Getting This Wrong Costs
Overcounting costs money and momentum. A nine-language business case does not get approved, or it gets approved and then stalls because the implementation turns out to involve a translation project nobody scoped. Either way the people who actually needed a second language are still waiting a year later, which is the genuinely expensive outcome. The cheapest version of this failure is the one where procurement optimises for a bigger language number and buys a tool nobody tested in the two languages that mattered.
Undercounting costs trust, and it does it quietly. The population you left out does not escalate. They ask a colleague, or a manager, or they guess, and your ticket volume looks healthy because the questions stopped arriving. The signal to watch is not complaint volume but question volume per head by population. A group that files half as many tickets per person as the company average is not better informed. It is routing around you.
So the question to take into the business case is not how many languages the tool supports. It is whether you can name, today, the number of people who need an answer in each language, and who will read those answers to check that they are right.
When You're Ready to Move Beyond the Country List
Most teams start with the country list because it is the number that is already available. It sits in the HRIS, it looks authoritative, and it is the one a finance partner will recognise. There is nothing dishonest about using it, and it is a reasonable first approximation when somebody asks you a question in a meeting.
What makes it stop working is the moment the number becomes a commitment. A country list used as a language requirement produces a plan with four times too many workstreams, and plans like that do not survive contact with a budget cycle. The working-language table is less impressive and more useful, because every row in it corresponds to a real group of people and a real decision about whether to serve them with documents or with a person.
The sequence that works: capture working language at onboarding so the audit becomes a report, run the report, commit properly to the short head, route the tail to named humans, and state publicly which languages are maintained. Then go and look at tools, with a table in your hand that describes your company instead of the market.
Frequently Asked Questions
How do I work out how many languages our HR help desk needs?
Build one table with four columns: every person, their working language, their country of employment kept separate, and whether anybody internally can read that language. Sort by working language and count, and you will get a short head of one to three languages covering most of the population and a long tail of very small groups. The head is what you commit document sets to and the tail is what you route to named people, and the fourth column is what decides whether you can quality-check any of it.
Why not just use the list of countries we employ in?
Because where somebody is employed and which language they want policy information in are different facts, and in most companies they diverge heavily. A country list typically overstates the language requirement by a factor of three or four, since large parts of most payrolls already work in one shared language day to day. The country list is still worth having, but it answers the jurisdiction question rather than the language question, which is why the audit keeps the two columns separate.
What question should I actually ask employees?
Ask which language they would prefer to receive HR and policy information in, rather than asking what their first language is. The preference question predicts support behaviour and the first-language question does not, because plenty of people who work comfortably in a second language would still rather read about sick pay or notice in their own. Asking through managers with that single question gets a high response rate and an answer you can act on.
Is it acceptable to not support a language we have employees in?
Yes, provided you say so plainly and provide a route. A population of three people is poorly served by a document set that will be stale within a year and nobody will notice, and far better served by a named person or inbox that can handle their questions properly. What is not acceptable is leaving the gap unstated, because then the population discovers it by receiving a confident answer that was written for somebody else.
How often should the audit be repeated?
Once a year is enough for a stable company, with an immediate rerun after any acquisition or any concentrated hiring push in a single market. Those two events change the shape of the distribution rather than just the total, which is exactly the change that breaks an arrangement built on goodwill. The sustainable version is to capture working language as a field at onboarding, which turns the annual audit into a report you can run on demand.
Does the pricing model really matter this much?
It matters more in this category than in most, because the thing that creates a language requirement is usually the thing that adds people. Entering a new market tends to mean hiring there, and on a per-agent or per-user product that expansion arrives as a licence line on top of a salary, so you pay for it twice. Flat and per-workspace pricing break that link, which is why the basis deserves as much attention as the feature list when the driver is geographic growth.
What is the most common mistake in this exercise?
Running the count off a head office system and treating the result as company-wide. Office-based staff are heavily over-represented in single-language working populations, so a sample drawn from them understates the requirement in exactly the group where it is largest, which is deskless and customer-facing staff. The second most common mistake is forgetting contractors and recently acquired populations whose records sit outside the main system.
HROpsLab takes no vendor money and publishes no paid placements, which is why the pricing above is quoted with its basis attached rather than as a single comparable number.