KB localization prioritization matrix for support

Most localization decisions get made backwards. Someone on the leadership team notices support volume spiking in Germany, or a big enterprise deal needs French, and suddenly the whole KB is getting dumped into a translation vendor's queue — 400 articles, five languages, a quote with a lot of zeros on it. Six months later nobody can tell you whether it moved a single metric.

The problem isn't translating. It's translating the wrong things in the wrong order. A KB has a long tail, and in most support orgs maybe 15–20% of articles drive 80% of self-serve deflection. Translate the dead weight first and you've spent real money localizing pages that got 11 views last quarter.

This post lays out a scoring matrix that combines four signals you already have access to — ticket volume by locale, ARPU of the affected segment, churn risk, and search CTR — into a single ranked list. Plus rollout templates and the measurement windows that actually tell you whether it worked.

Why gut-feel localization keeps failing

The usual trigger for localization is anecdotal. A sales rep complains that a prospect in Japan couldn't find docs. A support lead sees a cluster of English-language tickets from Brazilian customers. Both are real signals, but they're single data points, and single data points produce lopsided decisions.

The pattern that keeps showing up: teams translate the articles that are easy to translate rather than the ones that matter. Short FAQ-style pages get localized because they're cheap. The dense troubleshooting article that actually deflects tickets gets skipped because it's 2,000 words and full of screenshots. You end up with a localized KB that looks complete on a dashboard but doesn't move deflection in that locale at all.

The second failure mode is treating all locales as equal. Translating a billing article into Spanish (huge, high-ARPU customer base) and into a language with 40 total customers gets the same priority in a naive "translate everything" plan. One has a payback period of weeks. The other never pays back.

A scoring matrix fixes both problems by forcing every candidate article-locale pair to earn its place.

The four inputs and why each one matters

You're not scoring articles. You're scoring article × locale pairs. "Reset password" in German and "Reset password" in Portuguese are two separate line items with two different scores. This is the single most important mindset shift — a lot of prioritization efforts collapse because they rank articles globally and then pick a language later.

1. Ticket volume (localized demand) Count tickets from customers in that locale that map to the topic of the article. Not global ticket volume — locale-specific. If 320 German customers opened tickets last quarter about something your English article already covers, that's a strong translate signal. If three did, it isn't.

2. ARPU of the affected segment A ticket from a customer paying $4/month and one from a customer paying $900/month are not worth the same. Weighting by ARPU keeps you from over-indexing on high-volume, low-value consumer segments while enterprise locales quietly churn. Use the average revenue per account in that locale, not a blended global number.

3. Churn risk This is the input most teams skip, and it's the one that changes rankings the most. A topic tied to onboarding friction, failed payments, or a feature customers rage-cancel over carries more weight than a cosmetic how-to. If you have churn-reason tagging, map articles to the reasons. If you don't, a rough proxy works: articles about setup, integration, and billing almost always carry higher churn risk than articles about preferences or theming.

4. Search CTR (the discoverability multiplier) Even a high-demand article won't deflect anything if nobody clicks it. If your English version of a topic already pulls strong click-through from internal KB search, localizing it is a reasonably safe bet — the demand pattern is proven. If the English version gets impressions but low CTR, you have a discoverability problem that translation won't fix. Solve the title and snippet first; translating a page nobody clicks just produces a page nobody clicks in another language. If this is where you're stuck, the mechanics of fixing it are covered in diagnosing KB discoverability with query signals and CTR-to-ticket heuristics.

Building the score

Keep the formula simple enough that anyone on the team can reproduce it in a spreadsheet. Complexity is a trap here — the moment the scoring becomes a black box, people stop trusting it and go back to gut calls.

Normalize each input to a 0–10 scale within the set of candidates, then weight: Priority Score = (Ticket Volume × 0.35) + (ARPU × 0.25) + (Churn Risk × 0.25) + (Search CTR × 0.15)

The weights aren't sacred. A self-serve SaaS with low ARPU variance might push churn risk up to 0.35 and drop ARPU to 0.15. An enterprise product where every account is six figures might invert that. Pick weights once, apply them to every pair, and argue about rankings using numbers instead of opinions.

Here's what a scored shortlist looks like in practice:

Here’s a quick visual of the scoring workflow.

Notice "Theme customization — Spanish" lands near the bottom despite decent volume. Low churn risk and modest ARPU drag it down — exactly the kind of article a naive "translate the popular stuff" plan would have shipped first.

Turning the ranked list into rollout waves

A ranked list isn't a plan. You need to batch it into waves that are small enough to measure and large enough to matter. Dumping all 60 top-scored pairs into translation at once means you can't tell which ones worked.

1. 1
   Wave 1 — Proven demand, high stakes (scores 7.5+). Payment, onboarding, and setup articles in your highest-value locales. These are the pairs where you're most confident of payback. Keep the wave to 8–15 article-locale pairs so measurement stays clean.
2. 2
   Wave 2 — Strong but secondary (scores 5.5–7.5). High-demand articles in mid-tier locales, or lower-churn topics in top locales. Translate these once Wave 1 proves the model.
3. 3
   Wave 3 — Fill-in (below 5.5). Only localize these if Waves 1 and 2 hit their targets and you have budget left. Honestly, many of these should never get translated.

A rollout template for each wave should specify: the pairs included, the translator or vendor assigned, the expected deflection lift, the baseline metric snapshot, and the measurement window. Writing the expected lift before you translate is what keeps the whole program honest — it turns every wave into a testable prediction instead of a sunk cost.

1. 1
   List the article-locale pairs included
2. 2
   Assign translator or vendor
3. 3
   Document baseline metrics (ticket volume, CTR, deflection rate by locale)
4. 4
   State the expected deflection lift
5. 5
   Set the measurement window (start date → review date)
6. 6
   Schedule the review and assign who owns it

A rollout template for each wave should specify: the pairs included, the translator or vendor assigned, the expected deflection lift, the baseline metric snapshot, and the measurement window. Writing the expected lift before you translate is what keeps the whole program honest — it turns every wave into a testable prediction instead of a sunk cost.

Measurement windows that actually close the loop

This is where most localization programs quietly die. The pages ship, everyone moves on, and nobody checks whether German ticket volume on payment issues actually dropped. Without a measurement window built in, you're just spending.

1. 1
   Locale-specific ticket volume on the topic — the headline metric. Did tickets from that locale on that subject fall?
2. 2
   Localized article CTR and views — confirms people are actually finding and clicking the translated page.
3. 3
   Self-serve resolution / deflection rate for that locale.
4. 4
   Downgrade or churn signals in the affected segment, if churn risk was a major scoring driver.

On windows: give it 4 weeks minimum before you read anything, and 8–12 weeks before you call it. Localized pages need time to get indexed by internal search, accumulate views, and change customer behavior. Reading the data at two weeks will make good translations look like failures. A realistic expectation for a well-scored Wave 1 is somewhere in the 15–30% drop on that topic's locale tickets — not an overnight collapse to zero.

“

Give localized pages at least 4 weeks before judging their impact.

One thing worth watching: if a localized page gets views but tickets don't fall, the translation might be technically correct but unhelpful — a literal translation that misses how customers in that locale actually describe the problem. That's a content problem, not a localization gap, and it's fixable by rewriting rather than re-translating.

A real scenario

A mid-sized B2B SaaS company, roughly 2,800 paying accounts, had a growing customer base in Germany and the Netherlands but an English-only KB. Support was seeing a steady drip of German-language tickets, and leadership wanted "the KB translated." The vendor quote for the full KB in two languages came in around $30k.

Instead they scored the article-locale pairs. Out of roughly 380 articles, only 22 German pairs and 14 Dutch pairs scored above the Wave 1 threshold — mostly billing, SSO, and data-import topics. They translated those 36 pairs for a fraction of the full quote, snapshotted baselines, and set a 10-week window.

By the end of the window, German tickets on the translated topics were down about a quarter, and two enterprise accounts that had flagged documentation gaps during renewal calls went quiet on the issue. The remaining 340-odd articles stayed in English, and nobody missed them. The lesson wasn't "translation works" — it was that most of the KB didn't need translating at all.

When this makes sense — and when it doesn't

This is worth doing when:

1. 1
   You have measurable support volume in more than one locale
2. 2
   ARPU varies meaningfully across your customer base or regions
3. 3
   You have at least rough churn-reason or topic tagging
4. 4
   Translation budget is real enough that waste actually hurts

This is a bad idea when:

1. 1
   You have one dominant market and a negligible non-English customer base — you're adding process overhead to a decision with an obvious answer
2. 2
   Your KB itself is a mess. Translating poorly structured articles just multiplies the problem across languages. Fix the structure first — structuring KB articles for search-first discovery is the prerequisite step here.
3. 3
   You don't track locale on tickets at all. Without that, three of your four inputs are guesses.

The teams that get the least out of a matrix like this are the ones that build it, run it once, and never update the scores. Ticket patterns shift, new features ship, locales grow. Re-score quarterly and let the matrix retire old assumptions as fast as it creates new ones.

The takeaway

Localization budget is finite and KBs are mostly long tail, so the only decision that matters is order. Scoring article-locale pairs on volume, ARPU, churn risk, and CTR — then batching into measurable waves with real windows — turns a vague "translate the KB" mandate into a ranked, defensible plan where every translation has to earn its slot.

Done right, you usually translate far less than you expected and deflect far more than you would have by translating everything. Most of the KB doesn't need to exist in five languages. A small slice of it really does — and that's the slice worth finding first.

Localization budget is finite and KBs are mostly long tail, so the only decision that matters is order. Scoring article-locale pairs on volume, ARPU, churn risk, and CTR — then batching into measurable waves with real windows — turns a vague "translate the KB" mandate into a ranked, defensible plan where every translation has to earn its slot.

Done right, you usually translate far less than you expected and deflect far more than you would have by translating everything. Most of the KB doesn't need to exist in five languages. A small slice of it really does — and that's the slice worth finding first.