Server Transfer Planning for Alliance Leaders
Transfer planning becomes difficult when requests arrive through chat, names change and leadership cannot see whether the available seats match the players being considered. A structured request list keeps the decision separate from the conversation.
Capture the minimum useful information
For each request, store player name, current server, current alliance, transfer points and requested seat type. Add a status or note only when it supports the decision.
Use a member dropdown linked to the selected server where your server member directory is available. This reduces spelling differences and can populate the current alliance automatically.
Keep requests and decisions separate
A request list records interest. It does not promise a seat. Use clear statuses such as new, reviewing, approved, reserve, declined and transferred. That prevents early conversations being mistaken for final approval.
Review capacity as a group
Sort or export the list so leadership can compare points, seat requirements and alliance priorities. Keep a dated export for the final decision meeting, but continue to use the platform as the live source.
Protect member information
Transfer lists are operational data and should remain behind login. Public pages can explain the process, but names, points and decisions should be visible only to authorised alliance leadership.
Close completed requests
After the transfer window, update successful moves and archive or clear stale requests under your retention policy. Carrying old requests into the next window can create duplicates and false capacity assumptions.
Leadership checklist
- Player, server, alliance, points and seat are captured.
- Request status does not imply approval.
- Leadership reviews one live list.
- Exports are dated.
- Old requests are closed after the window.