Most guild rosters are wrong in the same way. They count characters and call it headcount. A 60-character roster can be 34 humans. A 40-character roster can be 40 humans. The number on the sheet does not tell you which one you have, and every downstream decision — raid slots, recruitment targets, role coverage, who to ask about next tier — inherits that error.
This is not a discipline problem. It is a schema problem. The fix is to key the roster to the person and record characters as attributes of that person. Below is the argument, the minimum viable schema, and a copy-paste layout you can drop into Sheets or Excel today.
The failure mode: character-keyed rosters inflate headcount
When each character gets a row, three things happen quietly.
Headcount inflates. A member with a main, a healer alt, and a PvP alt occupies three rows. If your recruitment target is “we need 25 for mythic,” you may believe you are at 25 when you are at 14 humans. The gap only becomes visible on raid night, when the same five people log in on their alts and the roster still shows full.
Attendance double-counts. If you track attendance per character row, a player who swaps between two characters across a tier appears as two partially-attending members rather than one consistently-attending member. Your retention signal is now noise.
Role coverage lies. A character-keyed sheet shows three tanks. A person-keyed sheet shows one tank player with two tank alts and one tank main. Those are different operational facts. The first says you are covered. The second says you have a single point of failure.
None of this requires bad faith from anyone. It is what happens when the row unit is the character and the decision unit is the human.
The design principle: one row per person
State the rule plainly and enforce it in the schema: one row per human, alts as attributes of that row. This is a design choice, not a game rule. No game enforces it for you. But it is the only structure that answers the question officers actually ask, which is “how many humans will show up, in which roles, at which hours.”
The character-keyed sheet answers “how many characters exist.” That question is almost never the one that matters.
Minimum viable schema
These are the columns I would defend as the floor. Add more only when a specific decision needs the data.
- Person ID — a stable internal key. Not the character name. Not the Discord handle. A short opaque string like
P014. This is what survives a name change, a server transfer, or a Discord rename. - Display name — what officers call this person in conversation. Usually the Discord handle or the name they use in voice.
- Discord handle — the current one. Record it as data, not as the key, because handles change.
- Timezone — IANA format (
Europe/Berlin,Europe/London,Europe/Warsaw). Not “CET” and not “evenings.” DST transitions break anything else. - Languages — comma-separated, with a rough level if it matters for voice comms. This is the column that makes a multilingual roster legible instead of aspirational.
- Roles they can fill — the roles this person can actually play in a raid or group, not the roles their alts are geared for. One person can list two roles. That is fine and useful.
- Alt list — see the next section.
- Commitment signal — a coarse label, not a score. Something like core, regular, casual, on break. Keep the vocabulary small and define it in a header note.
- Notes — free text. The place for “works late Tuesdays,” “prefers text comms,” “returning in 7.3.”
That is nine columns. It is enough to run a 20–200 person roster. It is not enough to run a surveillance program, which is the point.
How to record alts without duplicating the person
Two workable patterns. Pick one and stay with it.
Pattern A: a single alts field. One cell per person, characters separated by a delimiter. Example: Krallwyn (main); Krallheal; Krallpvp. Simple, sortable, no second tab. The cost is that you cannot query “who has a geared healer alt” without parsing the cell.
Pattern B: a linked Alts tab. The People tab holds one row per person. A second tab holds one row per character, with a Person ID column that points back. This is the structure you want if you ever plan to filter by role, item level band, or class across alts. It costs one extra tab and one extra discipline: every alt row must carry a valid Person ID.
Both patterns require a primary character convention. Pick one character per person to display in the People tab. Treat this as a label, not a statement about which character the member values most. It exists so the sheet sorts and reads cleanly. If someone changes mains, you edit one cell. If someone changes mains and you are on Pattern B, you edit one flag.
Copy-paste starter layout
Paste these headers into row 1 of a new sheet. The example row is hypothetical — it shows the shape, not a real member.
| Person ID | Display name | Discord handle | Timezone | Languages | Roles | Primary character | Alts | Commitment | Notes |
|---|---|---|---|---|---|---|---|---|---|
| P014 | Mira | mira_ | Europe/Berlin | DE (native), EN (fluent) | Healer, Ranged DPS | Mirathiel | Miraheal; Mirabolt | Core | Prefers text comms on progression nights |
If you use Pattern B, the Alts tab looks like this:
| Person ID | Character name | Role | Primary? | Notes |
|---|---|---|---|---|
| P014 | Mirathiel | Healer | Yes | |
| P014 | Miraheal | Healer | No | Gear behind main |
| P014 | Mirabolt | Ranged DPS | No |
Two tabs, one join key, no duplicated humans.
Governance: who edits, who resolves conflicts, who leaves
A schema without an owner decays. Name one officer as the roster editor. Everyone else submits changes through a single channel — a Discord form, a pinned message, a weekly thread. This is not bureaucracy; it is the difference between a sheet that is current and a sheet that was current in March.
Three rules cover most conflicts:
- The member’s own statement wins on identity. If someone says their primary is now a different character, you update the primary flag. You do not argue about it.
- The officer’s judgment wins on commitment label. Members do not self-assign core. That label is a guild decision, and it should be revisited on a stated cadence, not in the moment.
- Leaving is a status change, not a deletion. Set commitment to departed and keep the row. If they return in six months, you have their history. If you delete, you rebuild from memory.
The test of a person-centric schema is exactly this: when someone changes mains or leaves, the edit should be one cell or one flag. If it requires rebuilding rows, the schema is still character-centric wearing a person-centric label.
What this sheet deliberately does not do
It is not a performance scoreboard. It does not rank members by output, parse logs, or assign a number to contribution. Those are different artifacts with different governance, and mixing them into the roster sheet is how you get members who stop updating their own data.
It is also not a substitute for a conversation. If someone’s commitment label is drifting, the sheet tells you to have the conversation. It does not have it for you.
Automation is optional, and it is bounded
You can layer API pulls on top of this schema. You do not need to. The schema works fine maintained by hand, which is the point — automation should be convenience, not a dependency.
Where automation is documented, it is narrow. The XIVAPI Ruby client documents a free_company request that can return member data for a free company, a character request that can return additional data for various fields, a character_search method that accepts a character name and server, and a servers method that can group servers by data center. Those are the documented capabilities. They do not, on their own, tell you which characters belong to the same human. That association is the part you maintain.
For WoW, the Blizzard EU forums include a dedicated Recruitment category for finding a guild or community or advertising your own, and list many individual EU realm subforums including Argent Dawn, Draenor, Ravencrest, Silvermoon, and Tarren Mill. Those are useful places to source candidates. They are not roster APIs.
For Lost Ark, the Western news page lists a July 8, 2026 team update that mentions inactive guild cleanup details, and a 2026 server merge announcement stating servers across both regions would be consolidated in two phases beginning August 26. Both are reminders that external events — cleanups, merges — can invalidate character-keyed data. A person-keyed sheet absorbs them as edits. A character-keyed sheet absorbs them as a rebuild.
For FFXIV, the Lodestone lists a known issue following the release of Patch 7.57. Patch notes and known-issue pages are worth watching because they are the moments when character-level data can shift under you.
We cannot verify alt-association behavior across all datacenters and all games from public documentation alone. Our reasoning: the documented APIs expose characters and free companies, not the human behind them. Treat any tool that claims to infer alt ownership as a convenience with a failure mode, not as ground truth.
Why this matters more on EU multilingual rosters
A 20–200 person EU roster is not just larger than a single-timezone roster. It is structurally different. Members span Europe/London to Europe/Helsinki, speak different first languages, and often play on different schedules within the same week. The person is the stable unit across all of that. The character is not.
When you key to the person, three operational questions become answerable in one filter: who can fill this role, who is awake at this hour, and who speaks the language the group is using tonight. When you key to the character, you answer none of them cleanly.
FAQ
Should I use a spreadsheet or a database?
Spreadsheet until the roster exceeds what one editor can maintain in a sitting. The schema above ports to a database without redesign, because the join key is already the person.
What if a member refuses to list their alts?
Record what they give you and mark the alt field as incomplete. Do not pressure. The sheet is a governance artifact, not a surveillance tool. An incomplete row is more useful than a coerced one.
How often should the sheet be reviewed?
On a stated cadence tied to your tier or season, plus on any server merge or major patch. The cadence matters more than the interval.
Can I automate the alt association?
Not reliably from documented public APIs. The documented methods expose characters and free companies, not the human behind them. Maintain the association by hand and treat any inference as a suggestion.
What about data protection?
If you are storing personal data about EU members — Discord handles, timezones, language — check your obligations under the GDPR. The official regulation is available on EUR-Lex, and the EDPB publishes guidance on data subject rights, including the right to erasure. Keep the sheet minimal, restrict access to officers who need it, and have a process for deletion requests.
The roster is not a list of characters. It is a list of people who have agreed to show up. Build the sheet around the second thing and the first thing stops lying to you.