# How outbound email is addressed and signed

> Greetings resolve from fields that are semantically a person, never from a legal or trading name. Where no usable person name exists the greeting falls back to the contact's role, then to a generic. If your own note already opens with a greeting or ends with a sign-off, the platform's version is suppressed so the client never sees two.

URL: https://biloh.com.au/docs/explanation/addressing-and-signing-outbound-email
Category: Explanation | Audience: operator | Updated: 2026-08-20

## What problem does this solve?

Outbound documents go to whoever is flagged to receive them. Those contact records are created in all sorts of ways — typed during onboarding, imported from a previous system, auto-created when a client was first set up. Some have a person's name in the name field. Some have a company.

If the greeting simply uses "the recipient's name", a client eventually opens an invoice addressed to their own registered legal entity, brackets and all. It reads like a mail merge that went wrong, which is exactly what it is.

## The rule

**An entity name is never a candidate for a greeting.**

Only fields that are *semantically a person* are considered — a site contact's name, a contractor contact's name, a contractor's nominated contact person. Never a legal name, business name or trading name, even where the person field happens to contain one.

A person field filled with a company is treated as **empty**, not trusted. A string is rejected as a person name when it contains:

- a digit
- an ampersand, which marks a partnership rather than a person
- a bracketed clause, usually a note somebody left in the field
- more than four words after any honorific is stripped
- a company token such as `pty`, `ltd`, `limited`, `inc`, `llc`, `corp`, `co`, `group`, `trust`, `trustee`, `holdings` or `enterprises`

The heuristic is deliberately lopsided. Wrongly rejecting a real person means someone is called "team" — mildly impersonal. Wrongly accepting a company means shouting a registered entity at a paying client. The first is a far better failure, so the rules lean towards rejecting.

## What happens when there is no usable name?

The greeting falls back in order:

1. **Role-aware.** A contact whose role mentions accounts, billing, finance, payables or creditors is greeted as Accounts.
2. **Generic.** Everyone else gets a team greeting.

Both are configurable.

## Are names repaired before use?

Yes. Business registries store names in capitals, so a sole trader imported from one arrives shouting.

Where a name has letters but no lowercase at all, it is title-cased before use. A name that already carries mixed case is what a human typed, and is never "corrected". Honorifics — Mr, Mrs, Ms, Miss, Mx, Dr, Prof — are stripped before the first name is taken.

## How does my own note interact with this?

When you add a personal note to a send, the platform reads it before deciding what to put around it.

**If your note already opens with a greeting** — "Hi Sam," or "Morning all," — the platform's greeting renders as nothing. The client sees one greeting: yours.

**If your note already ends with a sign-off** — "Thanks, Jane" — the template's closing block is suppressed the same way. Your business name still appears in the header banner and the footer, so nothing about who sent it is lost.

Sign-off detection is deliberately strict, using two vocabularies:

- **Unambiguous closers** — Kind regards, Regards, Cheers, Many thanks, Sincerely, Yours faithfully, All the best — may carry a name on the same line.
- **Ambiguous ones** — Thanks, Thank you, Best — count only when alone on their own line.

That second rule is what stops a sentence like "thanks for your business this year" being read as a sign-off and silently removing your closing block.

## Can I override it?

Always. The greeting is an editable field on the send review screen and an editable slot through the API. What you type wins over every rule above, including suppression — an operator who typed a greeting meant it, even if their note also opens with one.

## What can be configured?

Six settings, all tenant-configurable, all available on every plan:

| Setting | Default | Effect |
|---|---|---|
| `comms.salutation.style` | `first_name` | First name or full name |
| `comms.salutation.fallback` | `role_then_team` | `role_then_team`, `team`, `there` or `none` |
| `comms.salutation.greeting_word` | `Hi` | The opening word |
| `comms.salutation.suppress_when_cover_greets` | `true` | Drop our greeting when your note has one |
| `comms.salutation.suppress_when_cover_signs` | `true` | Drop our sign-off when your note has one |
| `comms.salutation.signoff_word` | `Kind regards` | The closing word |

The comma is added by the platform in both cases, so do not include one in the word settings.

## Which documents does this cover?

Every send family that carries your own words: proposals, invoices, statements, credit notes, work orders, recurring work orders, contractor agreements, quote requests, and the invoice and proposal reminders.

## Related

- [Verify an email actually reached your client](/docs/how-to/verify-an-email-reached-your-client)
- [How to send a proposal](/docs/how-to/send-a-proposal)