AI email assistants: keep your tone when drafting replies

An AI email assistant does not replace your voice: it imitates it, sometimes badly. For a bilingual FR/EN B2B support team, the question is not whether the tool can write, but whether it writes like you, in both languages, without inventing a commercial promise or a missing attachment. The answer lies in a written reply charter, application-level controls and a structured human review.

Why tone gets lost in generated drafts

A language model produces text that is correct by default but generic: standard politeness formulas, identical structure from one email to the next, formal or informal address depending on the mood of the context. In B2B support, this uniformity is immediately visible. A customer familiar with your replies may notice a change of tone. Check that consistency during review, without assuming how many messages they receive.

The problem worsens in a bilingual setting. A Gmail assistant generating an English draft from a French request often applies American conventions: direct opening, plural apologies, formulas like "Hope this helps". If your house style writes "Dear Ms Laurent" and signs with a first name only, the gap weakens the business relationship. Tone is not an aesthetic detail: it is the continuity of your identity across two languages.

Finally, a generated draft can be factually right and tonally wrong, or the reverse. That is why the reply charter must handle both dimensions separately, with distinct controls for each.

Writing the reply charter: the seven essential blocks

A charter an AI assistant can actually use fits on two pages. It should contain, in this order:

1. Identity and register: systematic formal address in French, first-name-only signature, target length (for example 120 to 180 words for a simple reply).
2. Product terminology: a closed list of module names, features and their official FR/EN translations. A module called "portail client" never becomes "customer portal dashboard" in an English draft.
3. Allowed and forbidden promises: what support may announce (an indicative response time, the availability of documentation) and what it may never announce (a delivery date, a discount, a contractual commitment).
4. Unauthorized decisions: commercial agreement, acceptance of liability, warranty extension, scope change. The assistant proposes; it does not decide.
5. Handling missing facts: when information is missing, the draft must ask a precise question, never fill the gap with an assumption phrased as a fact.
6. Template structure per scenario: complaint, quote request, technical question, follow-up.
7. Thread update rules: how to quote history, when to reply in the language of the client's last message, how to flag a language switch.

Each block should be written with examples, not abstract principles. "Stay courteous" helps no model; "open by restating the client's request in one sentence" helps everyone, including the AI.

Bilingual terminology: the most frequent breaking point

In FR/EN B2B support, many tone mistakes are actually terminology mistakes. Your English client does not say "delivery" but "go-live"; your French client says "environnement de recette" where English says "staging environment". If the charter does not fix these equivalences, every draft becomes a lottery.

Build a glossary of 30 to 80 terms actually used in your exchanges. For each entry: FR term, EN term, usage context, terms never to use. This glossary must be injected into the generation context, not left in a document nobody rereads. A custom AI assistant allows this level of control; a generic tool rarely does.

Watch out for business false friends too: "facturation" and "billing" do not always cover the same scope, and "support" can mean the team or the service provided. When a term is ambiguous, the charter requires rephrasing rather than word-for-word translation.

Main before/after example: a bilingual complaint

Fictional context: a client writes in English to report that an expected monthly report was not sent to them. They mention three files attached to their first message. Your support has not yet verified the cause.

Draft before correction (generated without a charter):

"Dear customer, we are very sorry for the inconvenience. The issue has been escalated to our technical team and will be resolved within 24 hours. Please find attached the report. Best regards."

Three problems. First, the "within 24 hours" promise is an unauthorized decision: nobody validated that deadline. Second, "Please find attached the report" implies a report is attached when nothing has been verified, and the client had sent three files, which are nowhere mentioned. Third, the tone is that of a template, not of your house.

Draft after applying the charter:

"Hello Ms Turner, thank you for your message and for the three files you shared (contract addendum, invoice of 12 October, screenshot of the missing report). We have opened an internal ticket and our team is checking why the October report was not sent to you. I will come back to you before the end of tomorrow with either the report or a clear explanation of what happened. In the meantime, could you confirm the report should go to [email protected] and not to your address? Kind regards, Marc"

What the charter changed: all three files are named one by one (none omitted, none invented), no contractual deadline is promised, a commitment to reply is made by a named person, and a precise question replaces an assumption. Verifying attachments before replying is a control in its own right, covered in our guide on automating emails with attachments.

Unauthorized decisions: drawing the line

The most important boundary in a reply charter is the one around decisions. A generated draft can sound authoritative while having no mandate. List explicitly what the assistant may never write, even when the context suggests it:

• granting a discount, a credit note or a contractual deadline extension;
• confirming a delivery or fix date;
• acknowledging a fault by your company before internal validation;
• changing a service scope or support level;
• committing to a price or a renewal.

For each forbidden decision, provide the substitution sentence: instead of confirming, the draft acknowledges receipt and announces an escalation. This handover mechanism is the same as for a chatbot, and our article on chatbot to human handover details the escalation criteria that apply to email as well.

Missing facts: ask rather than fill in

A language model dislikes gaps. Faced with an incomplete request, it tends to write a reply that assumes an answer. This is the mechanism behind the costliest support hallucinations: not a wrong date, but an implicit confirmation of a scope the client never requested.

The charter must enforce a simple rule: any information absent from the thread becomes a numbered question in the draft, placed before the conclusion. Cap it at three questions; beyond that, the draft signals that the case must be qualified by a human before drafting even starts. Our method for triaging inbound requests with a Gmail AI agent is precisely how to qualify these cases upstream.

Technical constraints: drafts, not sends

On the architecture side, one design point matters more than the others: restrict the assistant's behavior to draft creation. Gmail scopes such as gmail.compose or gmail.modify can also authorize sending messages; a scope label is not a permission boundary. Your application must refuse any direct send and leave the last step to a human. The official documentation on Gmail API authorization scopes describes these access levels; adding the corresponding application controls is up to you.

Two useful details if you handle drafts via the API: a Gmail draft ID is stable, but the ID of the message it contains changes when the draft is modified. If your tool caches message IDs to track a conversation, plan for that switch. The draft management guide for the Gmail API documents this behavior.

Thread updates and reply language

The language rule deserves to be explicit. Default: reply in the language of the client's last message. But if a thread starts in English and switches to French at the third message, the charter must decide: either follow the last message, or keep the language of the first contact for file consistency. Pick a single rule and document the exception.

For thread updates, impose three habits on the draft: restate the client's request in a one-sentence opening, quote the attachments and dates mentioned, and never repeat the full history as a nested quote. A clean thread makes human review easier and reduces misunderstandings when several people on your side are involved.

Decision table: publish a draft or escalate to a human

Situation observed in the draft	Decision	Why
Simple factual reply, compliant terminology, no promise	Quick review then send	Low risk, real time saved
Pricing or discount mentioned	Escalate to the sales manager	Decision not authorized for support
A piece of information is missing	Draft with numbered questions, review	Avoid an assumption phrased as a fact
Acknowledgment of fault written	Escalate before any send	Liability commitment needs validation
Three or more questions needed	Human qualification before drafting	Case exceeds the standard reply
Thread switches language mid-conversation	Apply the documented language rule, review	Client file consistency
Product terminology off the glossary	Fix via the glossary, then review	Module names are contractual in the client's mind

Four-step human review procedure

Review is the final control, not a formality. A four-step procedure, one to two minutes per draft:

1. Check the thread's facts: every mentioned attachment exists, every quoted date is accurate, no amount is invented. This is the same reflex as evaluating chatbot answers against business criteria: explicit criteria, not a gut feeling.
2. Check the promises: no deadline, price or commitment outside the charter's allowed list.
3. Check tone and language: compliant register, glossary terminology, reply language consistent with the thread rule.
4. Check the structure: client request restated, files quoted, numbered questions at the end of the body, compliant signature.

If the same mistake recurs across several drafts, that is not a review problem but a charter problem: update the rule instead of correcting by hand indefinitely. Finally, test the charter itself: our guide on testing a conversational AI agent offers an approach you can transfer to email drafts, and our reference article on AI assistance for email drafts covers the technical foundations.

If you would like to structure a reply charter for your bilingual support team, you can define a mission with Edeverse.

Frequently asked questions

Do I need a separate charter for each language?

No, a single charter with two columns of conventions is enough in most cases. Separate what is universal (forbidden items, missing-fact handling) from what is language-specific (register, opening formulas, signature). This avoids two charters silently drifting apart.

Can the assistant reply on its own to the simplest requests?

It is possible, but only after a period when everything goes through reviewed drafts. If you open up automatic sending, restrict it to a single scenario, with no promise and no attachment, and keep a sample under continuous review. The initial caution costs little and protects your client accounts.

How do I technically prevent direct sending?

By giving the application only the permissions needed for drafts and blocking sending at the code level, not just in the interface. A useful reminder: some Gmail scopes also cover sending, so the restriction must be enforced by the application. Regularly testing a direct-send attempt completes the setup.

What if the client switches language mid-thread?

Apply the rule written in the charter, whatever it is, but flag the switch in your internal tool so the team follows. The worst scenario is not the wrong language choice; it is inconsistency between two consecutive replies from your side of the thread.

How often should the charter be updated?

At every new product module, at every tone issue raised during review, and at least once a quarter. A charter that never evolves becomes a dead document, and the assistant will eventually reproduce phrasing your house no longer uses.