What a shared Gmail account cannot prove

Nearly every volunteer ensemble runs on one email address that four people know the password to. It is usually the ensemble's name at gmail, it was set up by someone who left in 2019, and it works. Rehearsal cancellations go out from it. Dues reminders go out from it. It is, functionally, the organisation's front door.

It works right up until somebody says “I was never told,” and then it fails in a way that cannot be argued with.

Three things it cannot establish

Who sent it. A shared password produces messages attributed to the mailbox, not to a person. When the board needs to know who sent the fee increase notice that upset half the horn section — not to punish anyone, just to find out what was actually said — the answer is genuinely unavailable. Everyone remembers it differently and the record is silent.

Who received it. This is the one that costs money. Send to 80 people in a BCC field and you know the message left. You do not know that Row 34 of the spreadsheet was typed with a transposed letter, that the address belonged to a member who changed jobs in October, or that one recipient's mail server rejected it. Bounces come back to a mailbox nobody is watching, because the mailbox is a shared resource and watching it is nobody's specific job.

So when a member misses the call time and says they never got the email, both statements are true simultaneously. The email was sent. They never got it. There is no mechanism in a shared inbox that surfaces the difference.

What the members' address list currently is. The BCC list is pasted from somewhere — a spreadsheet, or worse, the previous email. Every send is a copy of a copy. A member who updated their address with the membership secretary in November is still receiving nothing in February, because the secretary's list and the emailer's paste buffer are different artefacts that nobody reconciles.

The failure that ends a season badly

Play this out. A treasurer sends a dues reminder to the full roster by BCC. Eleven addresses are stale. Those eleven members hear nothing, and are subsequently listed as delinquent. Two are embarrassed at rehearsal about money they did not know they owed. One does not come back.

Nothing in that chain was anyone's fault, and all of it was preventable by knowing which of the eighty messages actually arrived. That single piece of information is the gap.

It is also fragile in ways nobody plans for

A shared consumer mailbox is not built to be an organisation's communication system, and it shows in small ways that compound.

• Recovery is personal. Password resets and verification codes route to whatever phone number and backup address were set years ago. If those belong to a former officer, the ensemble can lose its own front door permanently. This is not hypothetical; it happens to a handful of community groups every year.
• There are hard sending limits. Google states plainly that Gmail limits the number of emails you can send or get per day and the number of people you can add as recipients. A 90-piece ensemble mailing a roster plus a patron list on the same evening can hit a wall with no warning and no clear indication of which messages went.
• Nothing is filed. Two years later, proving what notice was given about a rehearsal-attendance policy means someone searching a personal-feeling inbox by memory. If that person has left, the answer is gone.
• Replies vanish into one pile. A member's reply about a medical leave lands next to a vendor invoice and a spam message, in a mailbox with no owner. The reply that most needed a person is the one least likely to get one.

What “good” looks like

This is not really a plea to buy software. It is a plea for four properties, however you get them:

1. One list, and it is the roster. Not a copy of the roster. When the membership secretary corrects an address, the next mailing uses it, with no human step in between. Every duplicate list is a future missed notice.
2. Attribution. Each message records who sent it, to whom, and when. Not for surveillance — so that a question about what was communicated has an answer rather than a debate.
3. Delivery visible to the sender. The person who sent the cancellation should be able to see that four addresses failed, and to fix them, that night. Bounces that go somewhere unwatched are the same as no bounces at all.
4. A durable archive tied to the organisation. Not to an account whose recovery phone belongs to a person. The test is whether next year's secretary can read this year's notices without asking a favour.

You can build a decent version of this with a Workspace account owned by the organisation, real per-person logins, delegated access instead of a shared password, and a mailing list that reads from a single canonical roster. It requires ongoing discipline from unpaid people, which is why most ensembles start there and drift back.

“I sent it” and “they got it” are different claims. A shared inbox can only ever support the first one.

The five-minute audit

Ask these at your next board meeting and write down the answers:

• Whose phone receives the verification code for our email account?
• How many copies of the member address list exist right now, and which is correct?
• When a mailing bounces, who sees it?
• Can we produce the notice we sent about dues in September, today, without contacting a former officer?

If any answer is a name rather than a system, that is where next season's avoidable argument is going to come from.

Rehearsal Letter sends member and board notices from the roster itself rather than from a pasted list, records who sent what to whom, and shows the sender which addresses failed. That is the whole reason it exists rather than being a nicer spreadsheet.