Drafting client emails in plain language

Facts first. Tone second. Generation last.

The single most common mistake an accountant makes with a chatbot is asking it to write before telling it what is true. “Draft an email to my client about their TDS” produces something fluent, polite, and detached from any real situation. The model has no facts, so it invents plausible ones. This is how a client receives a draft mentioning a deadline of “the 25th of next month” when the actual deadline was last week, and how the accountant ends up apologising for an email they did not even write.

The pattern that works, every time, is fact-first prompting. Before you ask for a single sentence of prose, give the model the entire factual skeleton in a short structured block: who the client is (only the role and business type, never the PAN or TIN), what happened, what the numbers are, what the deadline is, what action you need them to take, and what tone you want. Only then ask it to draft. The model’s job is to wrap your facts in language, not to supply the facts themselves.

A working template looks like this, and you can paste it into Claude or ChatGPT tomorrow morning:

Draft a short client email in English. Use only the facts below. Do not invent any number, date, or name not provided.

Client: a mid-sized cement dealer in Bhairahawa, family-run, owner speaks limited English. Situation: their TDS deposit for Jestha is short by Rs. 18,400. Reason: the courier-services bill from Rara Logistics was paid as 1.5% TDS instead of 10%. Action required: deposit the shortfall by 25 Ashadh and send proof. Tone: respectful, not alarming, explain briefly why this matters. End the email with the action in a single bold line.

The output, with any of the current frontier models, will be a clean, copy-ready draft you spend ninety seconds reviewing instead of fifteen minutes writing. Crucially, because every number and date came from you, there is nothing for the model to get wrong.

Three real examples, three different shapes

The same fact-first structure adapts to almost every email you send. The shape of the facts changes; the discipline does not.

1. The shortfall notification. A client under-deducted TDS, or under-paid VAT, or filed a return with a wrong figure. The facts block must contain: the period, the head of tax, the correct amount, the deposited amount, the difference, the reason, and the deadline to correct. Tone is calm, not accusatory — the client almost always thinks you are blaming them when in fact you are protecting them. Ask the model to lead with the fix, not the failure: “Here is what we need to do this week” is better than “There has been an error.”

2. The document chase. You need bank statements, sales registers, expense vouchers, or VAT credit invoices before you can close the books or file the return. The facts block lists what is missing, why it matters, and the date by which you need it. Important: ask the model to enumerate the missing items as a checklist, not bury them in a paragraph. A Nepali SME owner who reads the email on a phone at a construction site will skim. A bulleted list of seven missing items has perhaps a forty-percent chance of being acted on. The same seven items in flowing prose has perhaps a five-percent chance.

3. The escalation. You have asked three times. The return is now blocked. The client must understand that the consequence is real. The facts block here must include: what you have already asked, when, and what specifically will happen if the deadline is missed (interest, penalty, a return that has to be filed nil and amended later). Ask the model for a tone that is “firm and respectful, not threatening.” The model handles this register surprisingly well — better than most accountants do under stress.

In each case the input takes a minute to assemble and the output takes another minute to check. The full email cycle that used to take fifteen minutes is now two.

Register, audience, and the family-business problem

Nepali clients are not one audience. A second-generation owner of a fifty-year-old trading house in Asan wants warmth: a sentence acknowledging the relationship, a polite opening, perhaps a line about Dashain or the recent puja. A thirty-two-year-old CFO at a fintech in Naxal wants the email compressed to four bullets and a deadline. A cooperative manager in Dang wants the Nepali version, formal, with the honorifics intact. The same factual content, three different envelopes.

The model handles this the moment you tell it. Add a single line to the prompt: “Tone: warm and personal, this is a long-term family client” — or — “Tone: compressed, bulleted, no pleasantries, this is a corporate CFO who reads dozens of emails a day.” The output changes completely. What you must not do is leave the tone unspecified and hope. An unspecified tone defaults to a generic mid-Atlantic professionalism that lands wrong on almost every Nepali client — too cold for the family business, too soft for the CFO, too English-corporate for the cooperative.

The action paragraph rule

Every client email ends with one ask. Not two. Not “let me know if you have any questions and also please send the statements and we should probably catch up.” One. The model will, if you let it, end every email with three or four parallel asks and the client will do none of them.

Make the model put the single action in a bold line, by itself, at the bottom of the email. The prompt instruction is literally one sentence: “End the email with the required action on its own line, in bold.” This single line is the highest-leverage change you can make to your client correspondence. Clients who scroll past the body and read only the bottom — which is most of them, most of the time — see exactly what they need to do, by when. The follow-up rate visibly improves. The number of clarifying replies drops.

If you genuinely need two things from the client, send two emails. The cost of one extra email is much smaller than the cost of one ignored email containing two requests.

What never goes into a public chatbot

This rule does not bend. Do not paste a client’s full PAN, TIN, bank account number, citizenship number, or any other identifier into a public chatbot. Do not paste a full ledger with names. Do not paste an unredacted bank statement. The free tiers of these tools may use your inputs for training; even the paid tiers route data through servers outside Nepal that you cannot audit. The professional confidentiality obligation does not pause because the tool is convenient.

The practical workaround is simple. In the facts block, write “Client: a mid-sized cement dealer in Bhairahawa” rather than the name. Write “the TDS shortfall is Rs. 18,400” rather than pasting the entire challan. Write “VAT period Jestha” rather than uploading the return PDF. The model needs the shape of the situation to draft the email; it does not need any identifier that would let a stranger reconstruct who the client is. If you find yourself wanting to paste a full document, that is a signal to stop, redact, and re-prompt.

For firms that handle sensitive material at scale, the right answer is an enterprise account with a no-training data agreement, or an on-premise model. For everyone else, the discipline of redaction at the prompt is the protection.

Check your understanding

Quick check

—

You need to email a client about a TDS shortfall of Rs. 18,400 for Jestha. Which is the best way to use AI to draft the email?

1. AType: "Write an email to my client about their TDS issue" and use whatever the model produces.
2. BPaste the full client PAN, TDS challan PDF, and ledger into the chatbot, then ask for a professional email.
3. CGive the model a structured facts block — period, head of tax, correct amount, deposited amount, shortfall, deadline, tone — with no client identifiers, and ask it to draft the email ending with the action in a bold line.
4. DAsk the model to "make the email sound nicer" after writing a rough draft yourself.

Check answer→

Quick check

—

An accountant asks the model: "Make this email sound more professional." The output reads more smoothly but the underlying request to the client is just as vague. Why is this prompt weak?

1. AThe model cannot understand the word "professional".
2. BA vague instruction produces nicer-sounding language wrapped around the same unclear ask — the client still does not know exactly what to do or by when, so the email still fails.
3. CProfessional tone is always wrong for Nepali clients.
4. DThe model adds too many bullet points by default.

Check answer→

What comes next

Even a perfectly drafted English email is the wrong tool for a Nepali SME owner whose working language is Nepali, Newari, or Maithili. The next section is about using AI to translate accounting language into something a monolingual client can actually act on — and the specific reason pure translation, on its own, is almost never enough.