The story in 30s
The problem. Entromy runs enterprise surveys across 62+ languages for private equity and enterprise clients, often launching 4 to 10+ languages simultaneously for companies with 1,000+ employees and assessments reaching 1,500+ participants. Translation happened entirely outside the product: export to Excel, translate in Google Translate, paste back into semicolon-separated cells, one language at a time.
What I did. I designed a centralized, user-triggered, in-platform translation workflow instead of scattered "AI magic" actions, and shipped it across three releases, sequenced by frequency and complexity: communications first, survey questions second, self-registration questions last.
What changed. Setup time for multilingual clients dropped by roughly 40 to 50%, the same share Customer Success estimated was previously lost to the manual process. A late change to the English source used to invalidate every existing translation without warning, that risk is gone.
The thinking: a system before any screens
Translation was treated as a one-time task bolted onto the outside of the product, not a workflow inside it. A late edit to the English source silently invalidated every translation already done, with no warning anything was now out of sync.
- → Made auto-translate destructive instead of non-destructive. A non-destructive approach seemed safer, but it let translations look complete while quietly going stale whenever English changed. Overwriting on every run keeps one honest rule.
- → Restricted structural editing to English only. Letting structure diverge by language breaks language-independent logic like conditional branching, and turns a one-to-many translation model into an unmanageable many-to-many one.
- → Chose a centralized, user-triggered workflow over inline, per-question "magic" AI actions. Per-question automation would have increased AI cost and created unclear overwrite logic.
- → Deferred partial-success handling to a later version. Rare translation failures are handled as close to all-or-nothing with clear messaging, rather than building complex partial-recovery logic clients hadn't asked for yet.
Solution overview
Shipped in three releases, one pattern reused across all of them:
- → Communications. A language selector, a single auto-translate action that translates every field into every enabled language at once, inline manual editing per language, and a warning icon when a language is missing translations.
- → Survey questions. The same pattern extended to handle multi-select answer options, with structural edits locked to English.
- → Self-registration questions. The same pattern again, removing the rigid Excel format and the engineer dependency entirely.
- → A targeted re-translate alert that triggers only when the English source actually changes, instead of leaving stale content unflagged.
Results
- → Eliminated an estimated 40 to 50% of survey setup time for multilingual clients
- → Removed developer dependency for self-registration translations entirely
- → Communications that used to take hours of copy-paste now take one click, plus optional manual refinement
- → Adoption was positive among large clients running high-scale, multi-region assessments (specific adoption figures limited by NDA)
Reflection
- 1 AI features in this kind of enterprise workflow succeed by being explainable and predictable, not clever. Users didn't want more automation, they wanted to know exactly what would change, when, and why.
- 2 The destructive-overwrite decision is the clearest example: it looks less safe on paper, but it's the one model that never lets a translation look done when it isn't.