LORDNINE guild boss-event preparation: a repeatable operations checklist

Members cannot make a fair attendance decision from a boss name and start time alone. State whether the session is progression, practice, a scheduled rotation, resource collection, or a limited-capacity attempt. Add server time, timezone, expected duration, and whether late arrival or standby participation counts.

Keep the event record in one durable location and use chat as the reminder layer. When the goal or time changes, update the record and point reminders back to it. This prevents copied announcements from becoming competing versions of the event.

The live caller, roster owner, attendance reviewer, loot recorder, and communication owner solve different problems. A small guild may assign several jobs to one person, but the jobs should still be named so a substitute knows what must be handed over.

Review role gaps before the ready check. Avoid publishing build mandates from a static guide; use the current game client and the guild's observed needs to decide who covers a mechanic. A requirement needs an owner, a backup, and a place where the final decision is recorded.

If the event expects consumables, guild-funded materials, or a contribution threshold, state the rule and any reimbursement boundary before members commit. Do not publish private balances or turn preparation into a public wealth comparison. Record only what the decision requires.

Link the loot, points, or contribution policy before the first eligible reward exists. A rule announced after a valuable drop cannot offer the same predictability. If the event needs an exception, label it, name the approver, and keep the reason with the event record.

A casual practice may only need a sign-up. A reward-bearing event may need a check-in window and officer verification. Decide how standby, disconnects, alternate characters, late arrivals, and approved absences are represented before the event begins, and apply the same rules to officers.

Give members a short correction window while the event is fresh. Keep screenshots, OCR output, and member histories inside the authorized workspace. The public checklist explains the workflow; it never needs to expose a real roster to prove that the workflow exists.

Immediately after the event, record the outcome, attendance exceptions, relevant awards, unresolved decisions, and the next expected follow-up. The factual record says what happened. A later review decides what to change. Keeping those steps separate makes corrections possible without rewriting history to match a conclusion.

Review repeated friction, not every imperfect moment. Three disputes about late arrival suggest the window is unclear; one disconnect may only need a correction. Change one process at a time, publish the effective date, and check whether the same failure recurs at the next event.