Free email username generator for a stronger first draft.

Take a four person bookkeeping practice called Brackenhill, working mostly with independent business owners, wanting addresses that sound steady and unfussy when read down a phone line. The domain is brackenhill.co.uk. The people are Priya Raman, Tom Ellis, Sara Ellis and Daniel O'Sullivan.

The convention that comes out of that, written down in one place so the next hire does not have to guess: personal addresses are firstname.lastname, all lower case, with accents stripped and apostrophes removed. That gives [email protected], tom.ellis@, sara.ellis@ and daniel.osullivan@. Collisions are broken with a middle initial and never with a digit, so a second Tom Ellis would become tom.j.ellis@. Three role aliases sit alongside the personal addresses and belong to nobody: hello@ for general enquiries, accounts@ for invoices and statements, and payroll@ for client submissions. hello@ is the only address that goes on the website, the invoice template and the van. When someone leaves, their personal address forwards to hello@ for twelve months, then bounces with a message naming their replacement.

What makes that hold up is mostly what it avoids. Dictating priya dot raman at brackenhill dot co dot uk takes no spelling out and no repetition. The apostrophe in O'Sullivan is dropped because apostrophes break a surprising number of web forms and CRM imports, and a client who types it faithfully gets a bounce. Everything is lower case because the local part is treated case insensitively by every mainstream provider anyway, so mixed case only creates doubt about whether the capital mattered. The middle initial rule exists before the collision does, which is the whole point of writing a convention down. And because the printed material carries a role alias rather than a person, none of it has to be reprinted when the person changes.

The version most small practices end up with arrives one hire at a time instead: [email protected] for the owner, then t.ellis@ when Tom joins, then s.ellis@ for Sara, then dan2@ because dan@ felt too short.

Four hires, four patterns, and no way for anyone to guess a colleague's address without asking. t.ellis and s.ellis are one character apart, which is how a payroll file ends up in the wrong inbox via an autocomplete that remembered the wrong one. dan2 has to be said aloud as dan, the number two, and immediately raises the question of who dan one was. Worst of all, priya@ is a personal address printed on every invoice, so the moment she takes a fortnight off, every payment query queues behind her rather than reaching someone who can answer it.

If you do not own the domain yet, the usernames are the wrong end of the job. The pattern you can live with depends on what sits after the at sign: a long or easily misheard domain makes firstname.lastname unbearable to dictate, and a short one makes it comfortable. Settle the domain, say a full address out loud twice, and then pick the pattern.

If you already have live mailboxes, generating a tidier pattern takes a minute and migrating to it does not. Before you decide, list what actually carries the old addresses: invoices already issued, directory listings, two factor recovery addresses, software licences bound to a login rather than a person, your Google Business Profile, bank and insurer contact records, and every email signature in every thread a client can search. A migration is worth doing once, as early as possible, with the old addresses forwarding indefinitely rather than for a polite ninety days. Past a certain size, or once a few years of printed material exists, the honest answer is to keep the inconsistent personal addresses and fix only the role aliases, which is where nearly all the practical benefit sits anyway.

If you are part of a group, a franchise or anything with a shared IT directory, the convention is not yours to choose. Inherited patterns exist so that address books, single sign on and mail routing stay predictable across the whole estate, and a locally invented scheme creates support tickets rather than clarity.

Some naming problems are not naming problems. A legal name that differs from the working name, a person who has changed their name and wants the old address retired quietly, or two people who genuinely share a full name all need a decision about policy and privacy, made by someone who knows the situation. And if you are simply setting up an address to apply for jobs from, your own name is already the answer and no tool is required.

An address gets used in four hostile places, and one that works in only three of them fails. It gets spoken down a phone line, often to someone writing on a pad. It gets read off a business card in poor light. It gets typed by someone who heard it once. And it gets pasted into a form that may or may not accept every character you chose.

The technical latitude is wider than the practical latitude. The local part, meaning everything before the at sign, permits letters, digits, full stops and several other characters, and can run to sixty four characters. None of that means you should use it. Keep to letters and single full stops, keep the whole address short enough to read in one breath, and strip accents, apostrophes and hyphens even when they are correct in the person's name, because those are the characters most likely to be rejected by a form or mistyped by a client. Case is not worth thinking about: mainstream providers treat the local part case insensitively, so a capitalised address only makes people wonder whether the capital was load bearing.

First name only is comfortable and fails fastest. In a team of ten, two people sharing a common first name is likely rather than unlucky, and the second Sarah is the one who has to accept a worse address forever. That asymmetry is what makes improvised collision handling feel unfair to the people it lands on.

Decide the tie break before you need it and apply it to everyone, including the founder. A middle initial inserted in the same position each time is the cleanest option, because it stays pronounceable and does not need spelling out. Digits are the worst option: they carry no meaning, they have to be read aloud as numbers, and they imply an earlier version of the person somewhere. Plan for names that change, too. People marry, divorce, anglicise, revert and transition, and a convention built on surnames will meet all of those. The workable policy is that a new address is created on request, the old one forwards to it silently and permanently, and nothing about the change is announced company wide unless the person asks for it.

These get muddled constantly, and the difference matters most when someone leaves. A personal address is a mailbox belonging to one member of staff, usually a licensed seat you pay for. An alias is an extra name pointing at an existing mailbox, costing nothing and owned by whoever the mailbox belongs to. A shared mailbox is its own inbox with its own history that several people open, so replies come from the shared name rather than from an individual.

The practical rule is that anything printed, published or typed into a form should be a shared mailbox rather than an alias on a person. An alias pointed at Priya still dies with Priya's seat, and the conversation history goes with it. A shared accounts@ keeps the thread, the attachments and the audit trail when the bookkeeper changes. Reserve aliases for convenience variants of a real person, such as catching a common misspelling of a surname. And leave the catch all setting off: an address that accepts anything at your domain collects spam sent to invented names, and hides genuine typos that you would rather see bounce so the sender knows to try again.

A convention that lives in one person's head is not a convention. Write it as four lines in whatever document new staff are given: the pattern, the collision rule, the list of role addresses with who monitors each, and what happens to an address when someone leaves. It takes ten minutes and removes the entire class of decisions that otherwise gets made badly at nine in the morning on somebody's first day.

The leaver policy is the part most often skipped and the most expensive to skip. Immediate deletion loses enquiries in flight and produces bounces to clients who did nothing wrong. Indefinite forwarding to a colleague quietly reassigns someone else's private correspondence. A reasonable middle path is to convert the departed mailbox to a shared one that a manager can open, forward new mail to the relevant role address for a fixed period, then set an explicit bounce message naming the person to contact instead. Whatever you pick, decide it before the first resignation rather than during one, and check the address is not the recovery contact on any account before you touch it.