Counting RSVPs without errors: parsing free-text replies, what to do with maybe, changed answers, one guest replying on two channels, and closing the count.
Key takeaways
- Every inbound reply is stored as a new row carrying channel, timestamp and the original text. A reply never overwrites a reply, otherwise you cannot explain how the number changed.
- Predefined reply buttons - up to three in a WhatsApp message of that type - return an identified choice rather than a string, which is what shrinks the parsing workload.
- "Maybe" is not a third bucket. It is a temporary state with an expiry date. Without a moment at which it resolves to yes or no, it becomes half the list.
- Deduplication belongs at the guest level, not the phone-number level. Somebody who answered on two channels is counted once, on their most recent reply.
- Headcount is not the same as reply count. One invitation can declare four people, so the two counts are kept separately and reconciled at the end.
RSVP counting fails in three places: free text nobody parsed, an answer that changed and overwrote the earlier one, and a guest who replied on both SMS and WhatsApp and was counted twice. The fix is not a better-worded question. It is an append-only response record, with the final number derived from it at close.
What a reliable count actually requires
A reliable count is not the one that pleases the event manager. It is the one that can be reconstructed - meaning you can point at any guest and say exactly where their value came from.
- An invitation id and an event id on every outbound message. Without both, a "yes" arriving from an unrecognised number cannot be attributed to anyone.
- The reply text exactly as received. Not the normalised version, not the truncated version, and not only the conclusion drawn from it.
- A timestamp and a channel. Both are needed to adjudicate between two contradictory replies.
- A parse confidence. A reply read as "yes" with high certainty and one that was guessed are not the same thing, even when the outcome matches.
- Who edited it manually and when. An event manager correcting a record after a phone call is a legitimate source, provided it is recorded as such.
- The declared headcount as its own field. A real field, not a number somebody tries to pull out of a sentence.
The reply vocabulary, and the long tail behind it
Most replies land on a handful of patterns. The problem is not the majority - it is the tail, and the tail is exactly where the replies the event manager needs to see are hiding.
| Received text | Parsed as | Confidence | Action |
|---|---|---|---|
yes | Attending | High | Recorded, no follow-up |
2 | Attending, 2 guests | High | Recorded with headcount |
both of us will come | Attending, 2 guests | Medium | Recorded, confirmation sent with the number |
maybe, depends on work | Maybe | High | Recorded as provisional, enters the closing reminder |
sadly we cannot make it | Not attending | High | Recorded, no follow-up |
I am coming without my wife | Attending, headcount unclear | Low | Human queue |
congratulations!! | No RSVP intent | High | Not counted, does not stop the reminder |
yes but only for the ceremony | Attending, with a caveat | Low | Human queue |
The last two rows carry the weight. A reply that is not a reply - a greeting, an emoji, a question - has to be classified as such, otherwise it is either counted as agreement or it suppresses the next reminder. Both mistakes are equally common, and both are only felt on the day of the event.
Why is "maybe" not a third category?
Because it is not an answer, it is a deferred answer, so it needs a clock. A guest who wrote "maybe" three weeks out and one who wrote "maybe" two days out are not in the same state, even though the field says the same thing. The build walkthrough is in how to create a WhatsApp bot.
- Every "maybe" is given a resolution date, usually the date the list is locked with the caterer.
- The reminder sent to a "maybe" is worded differently from the one sent to a non-responder. Someone who already answered knows they received the invitation, and a message that ignores that reads as a mistake.
- At the resolution date, "maybe" closes under one rule set in advance - typically counted as not attending, clearly marked as a default resolution rather than the guest's own answer.
- The number given to the supplier always carries both versions: the confirmed count, and the count including the maybes still outstanding.
That rule sounds bureaucratic, but it is what prevents the familiar conversation where two people look at the same system and quote different numbers, because one is counting maybes and the other is not. For current build and running costs, see how much a chatbot costs.
A changed answer: which one wins
A guest who confirmed and then cancelled, or cancelled and then confirmed, is common rather than exceptional. The rule is to append, never overwrite:
- Every reply is written as a new row on that invitation's response record.
- Current state is computed from those rows and is not stored as a field somebody updates.
- The default is the most recent reply by receipt time.
- A manual correction by the event manager outranks an automatic reply from the same day, and is logged with who and when.
- A change received after the lock date does not move the number given to the supplier, but it is recorded - and it appears on the final list used at the door.
That last point is the difference between a list used for planning and a list used at the entrance. They do not have to be identical, but both must be derived from the same record.
Related: appointment reminders and reducing no-shows, SMS against WhatsApp against email for reminders, Israeli SMS gateways compared.
The same person replied on SMS and on WhatsApp - which counts?
The later one, and the person is counted once. The difficulty is that the system sees two channels and does not see a person, so the identification has to be made explicit:
- The identity key is the normalised phone number. An Israeli number stored once as
050-1234567and once as+972501234567is two different guests in every report until it is normalised to E.164 on entry. - A household is not a phone number. A couple with two handsets who received two invitations will double-count unless both are tied to one invitation id.
- A reply arriving on a channel you did not send on is still a reply. A guest who received an SMS and chose to answer on WhatsApp to the business number is not doing anything wrong, and the system should attribute them by phone number.
- Two channels in the same minute with contradictory answers is rare, but happens when two messages went out. Here it is better to flag for a human decision than to pick by an arbitrary rule.
The channel itself imposes a limit worth remembering: on WhatsApp, when a user messages you a 24-hour service window opens, and outside it only approved templates can be sent. So a follow-up question to a guest who said "maybe" two weeks ago is not a free-text message but a template - and that shapes both what you can ask and how.
Reconciling the final number: what has to add up
Before a number goes to the supplier, three counts have to close. From one real-shaped event: 380 invitations were sent, each representing one household.
| Measure | Number | Note |
|---|---|---|
| Invitations sent | 380 | The denominator for every percentage |
| Actually replied | 288 | 209 by button, 79 in free text |
| Free text parsed automatically | 61 | Out of 79 |
| Sent to the human queue | 18 | The remainder |
| Replied on two channels | 23 | Counted once, on the later reply |
| Attending | 214 | Invitations, not people |
| Not attending | 74 | Invitations |
| No reply at the lock date | 92 | 380 minus 288 |
| Declared headcount | 402 | Summed across the 214 attending invitations |
Two checks close the report: 214 plus 74 plus 92 equals 380, and 209 plus 79 equals 288. If either fails, a record is being counted twice or a reply lost its attribution - and it is always findable, because the original text was kept.
Sources
Frequently asked questions
Is it better to send a form link than to ask for a reply in the message?
A form gives clean data and removes most of the parsing, but it costs response rate because it demands an extra action. The compromise that works is buttons in the message for the basic answer, and a link only when you need extra detail such as headcount or dietary notes.
What do we do with replies arriving after the lock date?
Record them and mark them as late, but do not quietly update the number already given. The list used at the door can include them; the number agreed with the supplier is a commercial decision rather than a figure that updates itself.
How far can we trust automatic parsing of free text?
Far enough to save most of the work, not far enough to drop the human queue. The practical rule is that any reply that is not unambiguous, and any reply whose headcount was pulled out of a sentence, goes through human confirmation before it enters the count.
How do we stop reminders going to people who already replied?
By building the reminder from the state computed at send time rather than from a list prepared earlier. A list built in the morning and sent in the evening will chase people who answered in between, and that is the single most common complaint about RSVP systems.
Keep reading
Related service
WhatsApp Cloud API
Templates, a two-way inbox and reminders on the official Meta API.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.