KoltrixSupport email in plain English for non-native readers
Many customers read your replies in a second language. Write shorter sentences, avoid idioms and format steps so translation tools and people get it right.
On this page(13 sections)
- Why plain language matters here
- Rule 1: one idea per sentence
- Rule 2: use common words
- Rule 3: remove idioms and metaphors
- Rule 4: be exact about times, dates and numbers
- Rule 5: format steps so they survive translation
- Rule 6: say what you need, in order
- Rule 7: keep a polite tone that is not too casual
- Rule 8: check how it reads after translation
- Add visual help carefully
- What not to change
- A quick checklist
- Key takeaways
If your product has customers in more than one country, a large share of them are reading your support replies in their second or third language. They may be very good at it. They may also be pasting your message into a translation tool, reading it slowly on a phone or sharing it with a colleague to check.
Writing for those readers is not about dumbing anything down. It is about removing the things that get in the way: long sentences, idioms, ambiguity and layout that falls apart in translation. The result is better for everyone, including native readers who are tired, busy or stressed.
This guide gives concrete rules and examples. It complements writing support emails people actually read, which covers structure, and AI for non-English email, which covers translation tools.
Why plain language matters here
- Understanding is slower in a second language. Each long sentence costs more effort.
- Translation tools make mistakes with idioms. "We will circle back" can come out as something about circles.
- Customers act on instructions. A misread step can turn a simple fix into a new problem.
- Tone is fragile. A casual phrase may read as rude or confusing in another language.
- Trust. A clear reply feels respectful. A confusing one feels like the company does not care.
Rule 1: one idea per sentence
Short sentences translate better and read faster.
Instead of: "Once you've confirmed that the export has completed, which can take a few minutes depending on the size of your account, you should be able to download the file from the page that appeared."
Write: "Wait for the export to finish. It can take a few minutes. Then download the file from the same page."
Aim for 15 to 20 words per sentence, and break any sentence that has more than one verb doing a different job.
Rule 2: use common words
Prefer the simple word when you have a choice.
| Instead of | Write |
|---|---|
| utilise | use |
| commence | start |
| in the event that | if |
| prior to | before |
| ascertain | find out |
| subsequently | then, later |
| assistance | help |
Keep the technical terms your product uses, and use the same word for the same thing every time. If you call it a "workspace" in one sentence, do not call it an "account" or "organisation" in the next.
Rule 3: remove idioms and metaphors
Idioms rarely survive translation. Replace them with plain statements.
| Instead of | Write |
|---|---|
| We will get back to you | We will reply by Thursday |
| Let's touch base | Let's talk |
| This is a bit of a gray area | The rules are not clear here |
| We'll loop in the team | I will ask the team |
| It's on our radar | We know about it, and we are looking at it |
| Reach out if you need anything | Reply to this email if you need help |
| Bear with us | Please wait a little longer |
| Out of the box | By default |
Sports, weather and war metaphors are common offenders ("ballpark figure", "storm in a teacup", "at the eleventh hour").
Rule 4: be exact about times, dates and numbers
- Dates: write them in full, such as "14 November 2026", not "11/14" or "11/12". Slashed dates mean different things in different countries.
- Times: include the time zone, such as "10:00 UTC".
- Deadlines: "by Friday 15 November" is clearer than "by the end of the week".
- Numbers: avoid mixing decimal separators. Write "1,000" only if your readers use it, or use "1000". For money, add the currency code, such as "USD 25".
- Vague amounts: replace "a few days" with "two to three working days".
Rule 5: format steps so they survive translation
Steps are where mistakes cost the most.
- Use a numbered list, one action per line.
- Start each step with a verb: "Open Settings." "Select Domains."
- Write the exact label of buttons and menus as it appears in the product, in quotes or bold.
- Add the result after a step when it helps: "You will see a green tick."
- Keep a single instruction per step.
An example:
To change your sender address:
1. Open Settings.
2. Select "Domains & addresses".
3. Click the three dots next to the address.
4. Select "Edit".
5. Type the new name and click "Save".If your interface is available in several languages, say which language the menu names are in, or include both.
Rule 6: say what you need, in order
Customers often reply with the wrong information because the request was unclear.
- Ask one question at a time where you can, or number them.
- Say why you need it: "Please send the order number. I need it to find your payment."
- Give an example of the format: "Order number (example: 10452)".
- Say what to do if they cannot provide it.
Rule 7: keep a polite tone that is not too casual
Warmth is good. Slang, jokes and sarcasm are risky.
- Be polite and direct. "Thank you for your message." "I am sorry for the problem."
- Avoid jokes, puns and cultural references.
- Skip long apologies and filler. A short, sincere sentence is enough.
- Use "please" with requests, but do not stack them.
Rule 8: check how it reads after translation
You do not need to speak the language to test.
- Paste your reply into a translation tool and translate to another language you use or can check.
- Translate it back to English.
- If the meaning changed, simplify the original sentence that failed.
Do this for your saved replies once, not for every message. Good templates repay the effort many times. See reusable reply snippets for teams.
Add visual help carefully
- A short screenshot with an arrow can replace several sentences, but add a text description too, for people who use screen readers or cannot load images.
- Link to a help article rather than pasting a long explanation. Make sure the article is also written in plain language.
- Use plain text or a simple layout. Complex tables and nested bullet points break in translation.
What not to change
Plain writing does not mean being vague, over-explaining or talking down.
- Keep the information complete and accurate.
- Do not remove necessary technical detail. Define a term once if the reader may not know it.
- Do not use all capitals or lots of exclamation marks to be clear.
A quick checklist
- Sentences are short, with one idea each
- Common words, and one name for each thing
- No idioms or metaphors
- Full dates, time zones and clear numbers
- Steps are numbered, start with a verb and use exact labels
- Requests say what, why and in what format
- Polite, direct tone without jokes
- Tested with translate-and-back on important templates
Key takeaways
- Many customers read in a second language, so clarity beats cleverness.
- Use short sentences, common words and the same term for the same thing.
- Replace idioms with plain statements, and write dates, times and numbers exactly.
- Format steps as numbered actions with the real button labels.
- Test key templates by translating them and back, and revise what breaks.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
