S6 Department – Ticket Handling Procedures
| This is the Document Release Information | |
| Article Number: | 7CAV-S6-005 |
| Scope: | S6 Department – Ticket Handling Procedures |
| Version: | Version 1.1 |
| Effective Date: | 06SEP26 |
| Last Modified Date: | 06SEP26 |
| Approving Authority: | S6 1IC |
| Point of Contact: | S6 2IC |
Purpose and Scope
This Standard Operating Procedure establishes how S6 receives, assigns, documents, escalates, resolves, and closes support requests.
It applies to all S6 personnel handling tickets.
Support Channel and Categories
Every request for S6 assistance must begin as a ticket submitted through the designated ticketing system:
This requirement applies to Game Staff, Forum Staff, and Development requests, including software bugs and requests for new development work.
Members must not directly contact individual S6 clerks for technical assistance. Requests received through Discord direct messages, forum private messages, or other unofficial channels must be redirected to the ticketing system.
Private messages may be used for internal coordination, escalation, or notification after a ticket has been created.
S6 uses the following categories:
- Game Server Support: Game services and authorized Game Staff functions.
- Forum Support: Forum accounts, permissions, configuration, structure, and features.
- Development Requests: Software bugs, features, automation, integrations, and website development.
- S6 Information Systems: An internal catch-all queue used when no specialized queue applies or S6 Headquarters must determine the proper handling.
Review and Routing
The first S6 staff member reviewing a ticket must confirm:
- The category is correct.
- The priority reasonably reflects the impact.
- Enough information is available to begin.
- The request belongs to S6 or can be routed appropriately.
A reviewing clerk may move a ticket to the correct category without prior approval but must document the change.
When additional information is required, the clerk must request it through the ticket.
Requests belonging to another department should be transferred to the appropriate queue. The clerk must notify the receiving department and document the transfer.
If no appropriate queue exists, the ticket must be placed in S6 Information Systems for Headquarters review rather than closed.
Priority and Assignment
The requester selects the initial priority. The assigned clerk or S6 leadership may change it when necessary and must document the reason.
Priorities are:
- Immediate Action Required: Critical operational disruption, serious security concern, or another issue requiring prompt attention. The reviewing or assigned clerk must notify the S6 1IC and S6 2IC.
- Majority of the Cav Affected: Most of the Regiment or a broadly used service is affected.
- Large Group Affected: A substantial group, unit, event, or service population is affected.
- Small Group Affected: A limited group or team is affected.
- Single User Affected: One member is affected.
- Other: The request does not fit an impact-based priority.
Game Server Support and Forum Support tickets are handled on a first-come, first-served basis. An authorized clerk may claim an available ticket by assigning it to themselves.
If a Game Server Support or Forum Support ticket remains unclaimed for 48 hours, S6 Headquarters may assign it.
S6 Headquarters assigns Development Requests according to priority, personnel availability, current workload, and Regimental need. Development work may be tracked in GitHub, but the related issue or project must be referenced in the XenForo ticket. The ticket remains open until the work is completed and the requester is notified.
Before beginning work, the accepting clerk must:
- Assign the ticket to themselves.
- Verify the category and priority.
- Review the request and supporting information.
- Set the appropriate status.
- Post an acknowledgment or request the information needed to begin.
Ticket Statuses
The assigned clerk must keep the ticket status current.
- Open: Awaiting initial review or assignment.
- Assigned: Assigned to a responsible staff member, but active work has not begun.
- In Progress: Work is actively being performed.
- Awaiting Response: S6 requires information or action from the requester.
- Awaiting Review: Work is complete and awaiting requester review.
- Scheduled: Approved work is scheduled for a future date or implementation window.
- Approval REQ: Work cannot proceed until required approval is received.
- HOLD: Work is temporarily suspended because of a documented blocker or dependency.
- Backlog: Accepted work is awaiting prioritization or scheduling, primarily for Development work.
- Past Due: A required response, action, review, or milestone has passed without completion.
- Resolved: The ticket reached its support conclusion because work was completed or S6 could not continue after requester inactivity.
- Closed: The ticket ended for an administrative reason without completing the normal support process.
Any status change that is not self-explanatory must be accompanied by a ticket entry explaining the reason.
Statuses must not be used to conceal inactivity, avoid requester updates, or delay escalation.
Communication and Documentation
Relevant actions, troubleshooting, requests for information, status changes, delays, escalations, related records, and final outcomes must be documented in the ticket or its associated internal record.
Credentials must never be included in a ticket.
Clerks must communicate professionally and provide clear instructions.
The requester must receive an update at least once every 72 hours while a ticket remains active. An immediate update is required when the clerk becomes aware that work will be delayed.
The normal progress-update requirement does not apply while a ticket is in HOLD status. Awaiting Response and Awaiting Review are governed by the response periods in Section 8.
HOLD and Escalation
An assigned clerk may place a ticket in HOLD when work cannot continue because of a documented blocker, dependency, or required external action.
The clerk must:
- Document the reason for the HOLD.
- Identify what must occur before work resumes.
- Notify their Senior or Lead.
- Notify the S6 2IC if neither billet is filled.
A ticket must not be placed on HOLD to avoid required work or requester updates.
When a ticket remains on HOLD for seven days, the S6 1IC and S6 2IC must consult the assigned clerk and determine whether the HOLD remains necessary.
A clerk must escalate work that exceeds their ability, access, responsibility, or authority.
The escalation chain is:
The ticket must document the reason for escalation, work already completed, relevant findings, and the action required from the next level.
Resolution, Closure, and Requester Inactivity
A 72-hour response period applies when a ticket is placed in Awaiting Response or Awaiting Review status. The period begins when the clerk changes the status and notifies the requester of the required action and deadline.
Awaiting Response
When S6 requires information or action before work can continue, the clerk must identify what is required, place the ticket in Awaiting Response, and inform the requester that the ticket will be marked Resolved if no response or update is received within 72 hours.
If no response or update is received, the clerk may mark the ticket Resolved. The final entry must state that S6 could not continue without the requested information or action and that the requester did not respond within 72 hours.
Awaiting Review
When work is complete, the clerk must explain the result, ask the requester to review it, place the ticket in Awaiting Review, and inform the requester that the ticket will be marked Resolved if no response or update is received within 72 hours.
If the requester confirms the result, or no response or update is received within 72 hours, the clerk may mark the ticket Resolved.
If the requester reports that the issue remains unresolved, the clerk must return the ticket to the appropriate active status and continue or escalate the work.
A ticket must not be placed in Awaiting Review until the requested work is complete.
Administrative Closure
A ticket may be marked Closed when it is withdrawn, duplicated, invalid, submitted in error, or otherwise administratively concluded.
The final entry must document the reason and reference any related or replacement ticket.
Closed must not be used for completed work or requester inactivity. Those tickets must be marked Resolved.