How Discord Communities Can Track Real Attendance

Discord Communities & Events August 22, 2026 15 min read By the Ontaym Editorial Team

Someone from the venue is on the phone asking how many, and your Scheduled Event says forty-three are Interested. Here are the six ways to turn a server into a number you can say out loud, what each one costs, and how much you can actually trust the result.

The number you have to say out loud

At some point a person on the phone asks you how many. Not roughly how many. How many.

The restaurant needs it to hold the long table. The board game cafe needs it because they have eleven chairs in that corner and no more.

You are standing in your kitchen with Discord open, looking at a Scheduled Event that says forty-three people are Interested. You know, with total certainty, that forty-three is not the number.

You just do not know what is.

This article is about getting that number. Not about why Discord makes it hard, which we have already written up in the piece on why Discord is excellent for communities and complicated for offline plans. This one assumes you have accepted the problem and want a working method by Thursday.

There are six ways to do it. They are not equally good, and the best one for you depends on how much work you are willing to do and how much you are willing to ask of people.

The honest ladder

Every method for counting attendance sits somewhere on a trade. The more reliable the number, the more it costs somebody.

Usually it costs the organiser. Sometimes it costs the member, which is worse, because members can just decline to pay.

Here is the whole ladder before we take it apart rung by rung.

Read that fourth column carefully. Nothing in it says "perfect", because attendance is a prediction and predictions have error bars.

What changes as you climb the ladder is the size of the error bar. At the top it is plus or minus everything. At the bottom it is plus or minus two people who got food poisoning.

Rung one: the Interested list, and what it is genuinely worth

Start here, because everyone starts here and most people stop here too.

Discord's documentation for the guild scheduled event object is clear about what the button produces. It increments a field called user_count, defined as the number of users subscribed to the event.

Subscribed. That word is precise and it is not the word you want.

A subscription is a request to be told things. It is what you do to a newsletter, not what you do to a dinner reservation.

Which does not make the list worthless. It is genuinely useful for three things, and you should use it for those three things.

• Reach. Forty-three Interested means at least forty-three people saw it and did not hate it. That is a real fact about your announcement.
• Notification. Those people get told when the event goes live, which is free distribution you do not have to organise.
• A shortlist to ask properly. This is the big one and almost nobody uses it. The Interested list is the best possible pool to send a real question to.

That third use turns a bad number into a good starting point. You are not trying to make forty-three into your headcount. You are trying to find which eleven of the forty-three are the actual answer.

There is one detail worth knowing if you have any developer on your server. The same documentation defines a Get Guild Scheduled Event Users endpoint, which returns the list of subscribed users, up to one hundred per request, with pagination and an option to include guild member data.

So the names are retrievable, not just the total. That matters later, when we get to bots.

We have written the full anatomy of this button in why Interested and attending are different numbers. For now, treat it as your top of funnel and nothing else.

Forty-three Interested is not a headcount. It is a list of people worth asking a real question.

Rung two: the reaction tally

The next thing every organiser tries is a message with an emoji on it. React with the tick if you are coming.

It is fast, it is free, and it works better than its reputation suggests. It also fails in a specific way that is worth understanding before you rely on it.

A reaction, in Discord's message resource documentation, is modelled as an emoji with a count attached. Not as an answer from a named person to a named question.

The count is the whole record. Everything else, including what the tick meant, lives in the wording of your message and in each person's memory of reading it.

Why wording decides everything here

Compare two messages that produce the same emoji and completely different numbers.

"Drinks on the 4th, react if you're keen" gets you enthusiasm. People who are keen and busy will still react, because they are being asked whether they like the idea.

"React with the tick ONLY if you will be at The Fox on Thursday the 4th at 8pm" gets you something much closer to a commitment. It is a worse message socially and a far better message practically.

The tick did not change. The question did.

The deeper issue is that a reaction cannot express a change of mind gracefully. Removing a reaction is silent, so a person who un-ticks on Wednesday tells you nothing you will notice.

Your count quietly drops by one and you never find out why, or when, or who. We take this apart properly in the article on why emoji reactions are not attendance records.

Use reactions when the stakes are low. A park meetup where three extra people cost nothing is a perfect reaction event. A deposit on a private room is not.

Rung three: a sign-up channel with a format

Now we reach the first method that produces something a venue would accept.

The idea is simple. One channel, one meetup, and everyone who is coming posts a single line in a fixed shape.

The format is the entire trick. Without one you get a chat, and a chat is what you were trying to escape.

Pin an example at the top of the channel and make it a real one, not a template with angle brackets. People copy what they see.

Then comes the part nobody warns you about. You have to police it, forever, and politely.

Somebody will reply to a sign-up with a question. Somebody will post "same" underneath a friend. Somebody will sign up, change their mind, and post a second line saying "actually can't" that sits fourteen posts below the first.

That last one is the real cost. A sign-up channel is append-only, exactly like the group chat it replaced, so cancellations do not delete anything.

You end up scrolling the whole channel and reconciling it by hand. Which is fine for eleven people and quietly horrible for sixty.

Rung four: a bot that keeps the roster

This is the first method where the counting stops being your problem.

The pattern is the same across every RSVP bot worth using. The bot posts a message with buttons, people press one, and the bot edits its own message to show the current list.

What makes that work is a Discord feature most members never think about. A button press is an interaction, and the bot can answer it privately, so nobody else sees who pressed what unless you want them to.

If you need more than yes or no, Discord supports modals. Its message components documentation describes text input components that live inside a modal and let a person enter free-form text, in a short single-line or a longer paragraph style.

So a button can open a small private box asking for a first name and a plus one count. That is as close as Discord gets to a form, and it is closer than most organisers realise.

What this actually costs you

The effort is front-loaded and it is real. Someone has to choose a bot, check what permissions it wants, invite it, and configure the question.

Servers with a technical person in them find this trivial. Servers without one find it a genuine barrier, and there is no shame in stopping at rung three.

There is also a trust question that deserves a straight answer. You are inviting third-party software into a server and it will hold a list of who is going where.

Read what permissions it asks for and be suspicious of anything asking for more than it needs. A bot that maintains a roster does not need to read your entire message history.

The configuration that matters most

Most people install an RSVP bot and accept the default buttons. The defaults are usually Yes, No and Maybe.

Delete Maybe. Genuinely, if the bot lets you, remove it.

Maybe is a comfortable button and it produces an uncountable answer. Every person who presses it has moved their decision onto you, and two days out you will be chasing them individually anyway.

A member who would have pressed Maybe will press Yes or No if Maybe is not there. Either answer is more useful to you than the one you removed.

The other setting worth changing is the reminder. A bot that pings your yes-list two days before the event does the single highest-value job on this entire list.

Rung five: a separate form

Forms are the reflex answer for anyone who has organised anything before. Post a link, collect proper fields, read a tidy list at the end.

Everything about the resulting data is good. Everything about getting people into it is not.

The problem is the transition. Your member is inside Discord, in a place they are comfortable, with an identity they chose.

The link takes them out of that. Now they are in a browser, often being asked to sign in to an account attached to their actual name, filling in fields designed by someone who thinks of them as a respondent.

Drop-off between the click and the submit is the whole story of forms, and it is invisible to you. You see the people who finished. You never see the twelve who opened it, saw a sign-in screen, and went back to the game.

Forms also do the wrong thing when the plan changes. A form is a collection device, not a record, so moving the event to 8:30pm means posting an update somewhere else entirely and hoping the right people read it.

They earn their place in exactly one situation. When you genuinely need structured information beyond a yes, such as dietary requirements, accessibility needs, or which of three activities somebody wants, a form is the right tool and the friction is worth paying.

Rung six: an event page beside the server

The last rung is a proper event record that lives outside Discord and gets linked into it.

The distinction from a form is that a page persists. It is not a collection funnel that closes, it is an object that keeps being true, and changes to it are visible to everyone who already answered.

That is the difference between capturing answers and holding a record. We go through it in detail in the comparison of Discord events and dedicated event pages.

The reason this sits at the bottom of the ladder is that it costs the member almost nothing. Open a link, see the plan, press yes. No account, no install, no leaving their pseudonym behind in a database somewhere.

It is also the only method on this list that survives a change of plan without any work from you. Edit the time once and everyone who said yes is looking at the new time, because they were looking at the record rather than a copy of it.

Its weakness is that it is one more thing. If your server is eleven people who all know each other, a reaction tally is genuinely fine and a page is overkill.

The identity problem, which is not a form field

Now the part that no amount of tooling fixes, and the part most guides skip.

The venue needs a name. Not a handle. A name that a host can call out across a room without either of you being embarrassed.

Your member is called something like voidhamster or Kel_. That is not an obstacle they put in your way. It is a thing they chose, and for a lot of people it is a large part of why they enjoy being in your server.

Asking for a real name is therefore not a data collection step. It is a social request, and it lands like one.

What you are actually asking for

Break the request down and it is bigger than it looks. A physical meetup usually needs three separate pieces of information that Discord deliberately does not hold.

A usable name

Something a venue can write on a booking and a stranger can say at a door. This is the smallest ask of the three and still not nothing.

A rough location

Confirmation that the person can physically reach the place. Stated in public, this tells a room of strangers roughly where somebody lives.

A way to reach them on the day

A phone number, or at minimum a promise that they will read Discord while travelling. This is the most invasive one and the one people refuse most often.

Notice that only the first is really about the booking. The other two are about your anxiety on the night, which is legitimate but should be recognised for what it is.

How to ask without making it weird

There are a few moves that reliably lower the temperature. None of them are clever, they are just considerate.

Ask privately, or at least not in the main channel. A public request for someone's city is a request made in front of an audience. The same question in a modal or a private page is just a question.

Ask for the minimum and say why. "The bar needs one name for the booking, so I just need a first name from one of you" is a complete and reasonable explanation. People comply readily with requests that come with reasons.

Let one name cover several people. Nobody needs eleven names. The booking needs one, and the rest can stay handles right up until they walk through the door.

Do not make a real name the price of coming. If someone will only give you a handle, take the handle and count them anyway. A person who shows up as voidhamster still eats a pizza.

That last principle is the one that separates organisers who grow their meetups from organisers who do not. The full case for it is in the piece on running events without collecting contact details.

The method, start to finish

Here is the whole thing as a procedure. It assumes a server of any size and a real venue with a real capacity.

1. Fix the plan before you ask anybody anything. One date, one time, one address with a street number. A question about a half-formed plan gets a half-formed answer, and you will have to ask again.
2. Create the Scheduled Event and treat it as an advert. Set the entity type to external so you can type a real venue in, and put the full address in the description. Its job is reach, not counting.
3. Pick your counting rung honestly. If the venue takes a deposit or holds a capacity, you need rung four or six. If nothing breaks when the number is wrong, a reaction tally is a perfectly respectable choice.
4. Ask one closed question, with the date in it. "Are you coming to The Fox on Thursday 4 September at 8pm, yes or no." Not "who's up for drinks". The date must appear in the question or people answer about the idea instead of the evening.
5. Make no as easy as yes, and private. A visible no in a public channel feels like a rejection of the organiser, so people go silent instead. Silence is the only answer you cannot plan around, so buy nos by making them cheap.
6. Send the real question to the Interested list, not the whole server. Those are the people who already raised a hand. Asking four thousand people a second time produces noise, and asking forty-three produces answers.
7. Collect one name and the plus ones. One name for the booking, and a number from anyone bringing somebody. Plus ones are where a confident eleven turns into an awkward fifteen.
8. Re-confirm two days out, individually. Go back to everyone who said yes and ask them to confirm once more. The drop between the first yes and the second yes is real, it is usually large, and it is the number you give the venue.
9. Publish the final number where the yes people will see it. Update the event, update the record, and post the change once. If your only copy of the truth is in your own head, you have become the database again.

Step eight is the one people skip and the one that pays for itself. It feels like nagging and it is the difference between booking for twenty and booking for twelve.

What the numbers usually look like

A word of warning about expectations, because the drop-off surprises first-time organisers.

You do not lose people because your event is bad. You lose them because each rung of the ladder asks slightly more than the last, and every ask has a cost.

An Interested count is measured in taps. A confirmed yes with a name attached is measured in decisions, and people make far fewer of those.

Plan for the shape rather than the exact figures. Expect the confirmed number to be a fraction of the Interested number, expect a further drop between the first yes and the second, and book against the second one.

Then, on the night, expect one or two more to vanish. That is not a planning failure, that is a Thursday.

The mistakes that cost real money

A few specific errors show up again and again, and each one has a cheap fix.

Booking against the Interested count. The classic. Somebody sees forty-three, tells the bar thirty, and pays a deposit on a room that ends up holding eleven people and a lot of echo.

Counting a poll as a headcount. A poll answers which date suits people, which is a question about calendars rather than a promise about attendance. The difference is the entire subject of what polls measure versus what commitments measure.

Leaving the venue name in the description only. Two bars in the same city have similar names more often than you would think. Put the street number in, every time.

Assuming an edit notifies anybody. Editing the Scheduled Event is the correct action and it is not a broadcast. If the time moves, say so where your yes people are, in words.

Running the count in your head. If the real number lives in one person's memory and nowhere else, that person cannot get ill, and that is not a plan.

Choosing your rung, honestly

Most servers do not need the most reliable method. They need the most reliable method they will actually keep using.

A bot that nobody maintains is worse than a reaction tally somebody actually runs. Pick for the organiser you are on a busy week, not for the organiser you are on the weekend you set it up.

Notice that the top two rows are not failures. Choosing a low-effort method for a low-stakes event is good judgement, not laziness.

The error is using a park-picnic method for a deposit-paid event, which is the specific mistake that costs money.

Where Ontaym fits

This is the one part where we talk about what we make, and then we go back to being useful.

Ontaym is rung six. An event is a record at one address, and you paste that address into your announcement channel like any other link.

Guests answer yes or no without an account, without installing anything, and without their details being visible to everyone else on the server. When the time moves, you change it once and everyone who said yes sees the change.

Your server keeps doing what it is good at. The conversation, the hype, the arguments about which bar, all of that stays exactly where it already is.

It is deliberately narrow. A ticketed convention wants a ticketing platform, and a Sunday voice chat wants a Scheduled Event and nothing more.

The one habit that fixes most of this

If you take one thing from all of the above, take this. Separate the announcement from the guest list, and never let one object try to be both.

The announcement wants to reach as many people as possible. Post it in the channel, make it a Scheduled Event, let it be seen by everyone.

The guest list wants the opposite. It wants a small number of named people, a real yes or no from each, and no public record of who lives where.

Those are opposite requirements, which is why no single button can satisfy both. Every method on this ladder is really just a different way of admitting that.

Do that, ask a closed question with a date in it, and re-confirm two days out. You will not get a perfect number, because nobody does.

You will get a number you can say out loud on the phone without lying. On a Thursday in a bar with eleven stools, that turns out to be the whole job.

Frequently asked questions