Lead times by event
| Event | Send | Ask for a reply by | Why |
|---|---|---|---|
| Spontaneous local plan | 1–3 days ahead | The same day | You are competing with whatever they already had on. Speed is the whole point. |
| Casual drinks | 1–2 weeks | 2–3 days before | Enough for a diary, short enough to still feel live. |
| Dinner party | 2–4 weeks | 4–5 days before | You need a fixed number before you shop or book a table. |
| Milestone birthday | 4–6 weeks | 2 weeks before | Venues want numbers, and guests may need childcare or travel. |
| Ticketed outing | The moment tickets are announced | Before the sale opens | Availability and price tiers move faster than people reply. |
| Weekend away or destination event | 3–6 months | 6–8 weeks before | Guests are booking transport, accommodation and leave. |
What pushes the date earlier
- December. Diaries fill from mid-November and a first-choice date is gone by early autumn.
- School holidays, half-terms and inset days, if any guest has children.
- Summer weekends, which compete with weddings, festivals and everyone else’s barbecue.
- Anything requiring a train, a flight or a night away.
- Anyone who needs to book childcare - that is a separate arrangement with its own lead time.
- Anything ticketed, where waiting costs money rather than just goodwill.
- Guests who work shifts and submit availability weeks ahead.
When a save-the-date earns its place
A save-the-date is worth sending when the date is genuinely fixed but the details are not, and when guests need to make an arrangement - leave, travel, childcare - long before you can tell them the venue. Below that bar it is an extra message that trains people to skim.
The rule is that a save-the-date must be a commitment from you, not a hope. Send it only once the date cannot move, because a moved save-the-date costs far more trust than never sending one. Keep it to the occasion, the date, the rough shape of the day and an explicit promise that details follow.
Save the date - Saturday 18 October, for my 40th. Evening, in south London, and it will run late. Nothing to do yet and nothing to book, just don’t let anyone else have that Saturday. Proper invitation with all the details in September.
The information checklist
- What the occasion is, and who is hosting it.
- A confirmed date or a clearly labelled poll if it is not settled yet.
- Start time and an honest indication of when it ends.
- Venue or the area plus when the exact address will follow.
- Whether partners, friends or children are included.
- What it costs, including “nothing”, and how to pay if it is not nothing.
- Whether there is food and whether it is a meal.
- Dress, if it genuinely matters - and say nothing if it does not.
- Accessibility: steps, lifts, loos, seating, how loud it will be.
- The reply-by date, and one obvious way to reply.
When the plan changes
Changes are normal; losing people to them is not. The failure is almost always the same - the new detail is announced once, in a thread, and half the guest list is still working from the version they read three weeks ago and saved.
Announce a change in a message that leads with what changed, in the first line, rather than restating the whole plan and hoping people spot the difference. Then update the invitation itself so that the link you originally sent shows the current version. If the change is significant - a different date, a much later start, a venue across town - ask people to re-confirm rather than assuming a previous yes still holds.
One change for Saturday: we’re starting at 8, not 7.30. Everything else is exactly the same. I’ve updated the details at [link] if you want to double-check anything nearer the time.
Bad news - the room fell through, so we’ve moved to The Junction on Bell Street. Same date, same time, about fifteen minutes further east. I know that won’t work for everyone, so can you re-confirm even if you’d already said yes? I’d rather have an accurate count than assume.
Keeping one version of the truth
The reason changes cost so much is that a sent message is frozen and a plan is not. Every update creates another version, and guests are left to work out which one is current from timestamps.
A Status Social event keeps the details, the guest list and the replies in the same place, so an update changes what everybody sees rather than adding another competing message to the pile.