GuildOps — guild management in one app

Discord stores the night's conversation. It does not reliably store who is in the guild, who missed Thursday's raid, and which piece went to whom. When that information lives in pins, officer notes, and one person's memory, the guild breaks the day that person leaves. GuildOps is Battlehorns' app for that layer: members, events, loot, and resources, in one place.

Separate the names. Battlehorns at battlehorns.net is web hosting for gaming communities — guilds, clans, and esports — not the metal band. GuildOps lives at guildmanager.battlehorns.net. One is the public site you publish over FTP. The other is the internal panel. They are not the same page, and they do not need to be.

The problem with Discord as the only record

Chat is good at waking people up and bad as an archive. Search "loot" in a two-year-old server and you get hundreds of messages, half of them jokes. The member list depends on roles nobody updated since last season. The calendar is one bot event stacked on a hand-made one.

• Recruits should not read internal history to learn loot rules. That short text belongs on the site. The operational detail is not theirs yet.
• Officers argue the same absence three times because there is no event record, only "I came today" messages.
• Whoever leaves takes the spreadsheet or the hidden channel where the truth lived. The guild starts over.

This is not about leaving Discord. It is about taking away its role as the only source of truth. Chat notifies. GuildOps records. The site, on hosting, shows the public only what is public. That split is also in the web hosting guide.

What GuildOps does

Battlehorns describes the product in four blocks: members, events, loot, and resources. It is not a site builder, not a forum, and not a replacement for hosting. It is the panel where an MMO guild stops depending on loose messages for those four things.

Members. The list that matters is who actually plays with you, in which role, and in which state: trial, member, officer, inactive. Discord roles approximate this and fail when someone changes class and the role stays. In the panel, the record is the reference.

What it does not promise. Do not sell the guild an automatic armory importer, a bot that does everything, or a DKP formula the product page does not describe. Check inside GuildOps what is actually available before you announce it as a complete addon. The core — people, events, loot, resources — already fixes the usual mess.

Events and attendance

An event has a date, a time, a type (raid, scrim, practice, officer meeting), and a list of who said they would come. On Discord that is an emoji reaction. It works until the emoji is reused or the event is edited and the reactions stay on the wrong message.

1. Create the event in the timezone the guild actually uses, written out the first time ("22:00 Lisbon").
2. Mark who confirmed and who missed after the session, the same day. The next day nobody remembers.
3. Do not open a new chat argument for every absence. The record answers. Chat only announces time changes.

Attendance stops being a mood and becomes a count. That matters when there are more applicants than spots, or when a trial says they "always showed" and the calendar says otherwise.

Loot and resources

Loot without a record produces the same argument in every MMO: who received the piece, whether it was main or alt priority, whether a guild resource was spent on a repair or a craft. Chat keeps the version of whoever spoke last.

A minimum record per event is enough: item or resource, who received it, under which rule (need, priority, roll, guild bank). You do not need to publish that table on the site. You need two officers to see the same line a week later. Resources — guild gold, materials, season credits — follow the same logic: in, out, balance. If that lives in a sheet only one person edits, it does not belong to the guild.

The public site can carry three sentences of policy. The ledger stays in GuildOps. Applicants read the policy in recruitment and the member panel. Members see the detail after they join.

How it links to the Battlehorns site

• On the site, a "member area" button points at GuildOps, visible to people who already joined. Applicants see "Apply", not the panel.
• In GuildOps, the guild description can repeat the site address, with https://, so nobody shares a Discord invite as the official home.
• Do not copy the full roster into HTML you will forget to update. Either the public roster is short and reviewed, or it is not on the site.

Hosting is what you use when you want the page a league and a search engine can open: rules, hours, and a PHP application saved in MariaDB if you need that. That is the plan on hosting, explained in free hosting and built in the tutorial. If you are still choosing between writing that site and using a builder, read hosting versus builders and the comparison with Guildtag, Shivtr, and Guildwork.

First steps

1. Open GuildOps and create the guild with the name you already use in game.
2. Add active members, with a role. Inactive people are marked as such, or they stay out.
3. Create the next real event, not a test named "asdf".
4. After that event, record any loot or resources that actually dropped. One true line beats an empty system.
5. When the site exists, add the button. Until then, Discord announces the panel with a fixed link, not a screenshot.

If what you still lack is the public page, registering for hosting is a separate step, not a prerequisite for GuildOps. You can run the guild in the panel and publish the site the following week. The mistake is thinking one replaces the other.

In this series: free guild hosting, hosting or a builder, the hosting guide, GuildOps, the setup tutorial, the platform comparison, and recruitment that converts.