DWIRC:Staff Training/User Support

DarkWorld IRC Staff Training
Module 6: User Support and Communication

Program	DarkWorld IRC Staff Training Program
Module	6 of 10
Difficulty	Intermediate
Estimated study time	3–4 hours
Assessment	Knowledge check, roleplay, and support-case exercises
Prerequisite	Module 5 — IRC Services

Module Overview

User support is one of the most important responsibilities of DarkWorld IRC staff.

A staff member may understand IRC commands and policies but still be unsuitable for support if they cannot communicate patiently, clearly, neutrally, and securely.

This module teaches candidates how to:

• Receive and understand support requests.
• Ask effective diagnostic questions.
• Provide clear instructions.
• Protect passwords and private information.
• Assist inexperienced users.
• Handle angry or frustrated users.
• De-escalate disagreements.
• Recognize project boundaries.
• Escalate unresolved or high-risk cases.
• Record support activity appropriately.

The purpose of support is to help the user reach a safe and correct outcome—not merely to send commands or close the conversation quickly.

Learning Objectives

After completing this module, the candidate should be able to:

1. Greet and assist users professionally.
2. Identify the user’s actual problem.
3. Ask focused diagnostic questions.
4. Provide one clear troubleshooting step at a time.
5. Avoid requesting passwords or unnecessary private information.
6. Explain technical concepts in accessible language.
7. Recognize when a request belongs to another DarkWorld project.
8. Handle complaints and frustration without escalating conflict.
9. Distinguish support cases from abuse reports.
10. Recognize emergencies and security incidents.
11. Escalate cases with a useful summary.
12. Confirm that a problem is resolved before closing the case.

1. Purpose of User Support

DarkWorld IRC support should help users:

• Connect securely.
• Register and authenticate accounts.
• Configure SASL.
• Recover nicknames through approved procedures.
• Register and manage channels.
• Understand channel and user modes.
• Find official policies.
• Report abuse safely.
• Resolve ordinary IRC client problems.
• Locate the correct DarkWorld project team.
• Understand network notices and errors.
• Use official resources.

Support staff should also help the network by:

• Identifying recurring problems.
• Reporting outdated documentation.
• Recognizing widespread service failures.
• Detecting phishing and impersonation.
• Directing policy cases correctly.
• Preventing unsafe advice from spreading.
• Recording unresolved incidents.

2. Official Support Channels

DarkWorld IRC may use channels such as:

Channel	General purpose
`#Help`	IRC connection, accounts, channels, Services, and network help
`#Support`	Support relating to applicable DarkWorld services or projects
`#Abuse`	Abuse reports and policy-related concerns
`#DarkWorld`	General network and community discussion

Restricted staff channels may be used for escalation and coordination.

Staff must not move private evidence into a public channel merely because the conversation began there.

3. The Support Workflow

Use the following process:

1. Acknowledge the user.
2. Understand what they are trying to do.
3. Collect only the necessary information.
4. Classify the issue.
5. Provide a safe troubleshooting step.
6. Confirm the result.
7. Continue or escalate as required.
8. Summarize the outcome.
9. Document the case where necessary.

Step 1: Acknowledge

A simple acknowledgement tells the user that someone is listening.

Examples:

Hello. I can help you check that.
Please provide the exact error message you receive.
I understand the issue. Let us check your connection settings first.

Avoid:

What?
It works for me.
You configured it wrong.
Read the website.
That is not my problem.

Step 2: Understand the Goal

Ask what the user is trying to accomplish.

For example:

Are you trying to register a new account or identify to an existing one?
Are you unable to connect to IRC, or can you connect but not join the channel?
Are you asking about a channel ban or a network-wide restriction?

Solving the wrong problem wastes time and may create additional risk.

Step 3: Collect Necessary Information

Useful information may include:

• IRC client and version.
• Device or operating system.
• Server address.
• Port.
• Whether TLS is enabled.
• Exact error message.
• Nickname or registered account.
• Relevant channel.
• Approximate time.
• What changed before the problem began.
• Troubleshooting already attempted.

Do not collect private information merely because it might be interesting.

Step 4: Classify the Issue

Common categories include:

• Connection problem.
• TLS or certificate problem.
• SASL or NickServ problem.
• Channel access problem.
• Services problem.
• Channel-management issue.
• Policy question.
• Abuse report.
• Project-specific request.
• Network incident.
• Security emergency.

Step 5: Provide a Safe Step

Give one or a small number of clear steps.

Example:

Please confirm that the server is irc.darkworld.network, the port is 6697, and TLS is enabled. Do not disable certificate verification. Tell me the exact error after trying again.

Avoid sending a large block of unrelated commands before identifying the problem.

Step 6: Confirm the Result

Ask:

Did the connection complete successfully?
Does WHOIS now show your registered account?
Can you join the channel after identifying?
What exact response does NickServ give now?

Step 7: Escalate When Required

Escalate when:

• The issue is outside your authority.
• Normal troubleshooting has failed.
• Multiple users are affected.
• A security problem may exist.
• Administrative Services action is required.
• A policy decision is disputed.
• Confidential evidence must be reviewed.
• The action could affect many users.
• You are uncertain and a wrong action could cause harm.

4. Clear Communication

Good support communication should be:

• Clear.
• Respectful.
• Short enough to follow.
• Accurate.
• Relevant.
• Secure.
• Free from unnecessary jargon.
• Appropriate to the user’s experience.

Use Plain Language

Instead of:

Your SASL PLAIN negotiation failed during CAP authentication.

Try:

Your client could not authenticate your registered account while connecting. Let us check the saved account name, password, and SASL settings.

Technical details may be added when they help the user understand or troubleshoot the issue.

Give Commands Separately

Prefer:

Open a private NickServ window and enter:

/MSG NickServ INFO YourAccount

Avoid placing several password-sensitive commands into a public-channel message.

Explain Expected Results

Do not only provide a command. Explain what should happen.

Example:

Run /WHOIS YourNickname. In the response, look for a line showing that you are logged into your registered account. Do not paste any private connection information publicly.

5. Supporting New IRC Users

New users may not understand:

• What a nickname is.
• How channels work.
• Why a nickname is already in use.
• The difference between IRC and a website.
• How to send a command.
• What NickServ is.
• Why TLS matters.
• How to open a private query.
• Why they must identify.
• How SASL works.

Staff should not embarrass users for lacking this knowledge.

A helpful sequence is:

1. Confirm their IRC client.
2. Help them connect securely.
3. Help them choose a nickname.
4. Explain channels and private messages.
5. Direct them to official NickServ help.
6. Help them register privately.
7. Explain email confirmation.
8. Help configure SASL.
9. Help them join official channels.
10. Point them to current documentation.

6. Asking Good Diagnostic Questions

Good questions are specific and easy to answer.

Examples:

What exact error appears when you connect?
Which IRC client are you using?
Are you connecting to irc.darkworld.network on port 6697?
Is TLS enabled?
Does the problem happen before or after you join the network?
What does NickServ say after you identify?
Are you identified to the same account that has channel access?
Does this affect only one channel?
Approximately when did the problem begin?

Avoid vague or accusatory questions:

Why did you break it?
What did you do?
Are you sure you know how IRC works?
Why did you forget your password?

7. One Change at a Time

When practical, ask the user to make one meaningful change and report the result.

This helps identify the cause.

For example:

1. Confirm the server and port.
2. Attempt the connection.
3. Record the exact error.
4. Verify the device time if TLS fails.
5. Check SASL only after the secure connection succeeds.

If several settings are changed simultaneously, it becomes difficult to know which change solved or worsened the problem.

8. Password and Credential Safety

Staff must never ask users to provide:

• NickServ passwords.
• SASL passwords.
• Email passwords.
• Confirmation codes.
• Password-reset codes.
• Two-factor secrets.
• IRC operator passwords.
• API tokens.
• Server credentials.
• Private keys.

If a user posts a credential publicly:

1. Do not repeat or quote it.
2. Tell the user to change or revoke it immediately.
3. Explain which saved clients or services must be updated.
4. Limit further exposure where authorized.
5. Escalate if an account or system may be compromised.
6. Document the security incident appropriately.

Staff reminder: A legitimate DarkWorld staff member does not need a user’s password to provide account-support instructions.

9. Public and Private Support

Suitable for Public Support

Public channels may be used for:

• General connection settings.
• Public commands.
• Links to official documentation.
• Non-sensitive client instructions.
• General explanations of policy.
• Service-status information approved for publication.

Move to an Approved Private Process

Use an approved private method for:

• Account ownership evidence.
• Private-message abuse logs.
• IP or hostname information.
• Email-account details.
• Security vulnerabilities.
• Staff complaints.
• Compromised accounts.
• Confidential project applications.
• Sensitive relay or advertising evidence.

A private message is not automatically an approved permanent evidence system. Important evidence may still need to be transferred to an authorized case record.

10. Handling Frustrated or Angry Users

Users may be upset because:

• They cannot connect.
• They lost account access.
• They were banned.
• They believe staff treated them unfairly.
• They have repeated the same problem.
• They do not understand the instructions.
• They feel ignored.
• The issue affects an important event or project.

Staff should:

• Remain calm.
• Acknowledge the inconvenience.
• Focus on verifiable facts.
• Avoid matching the user’s tone.
• Explain what can and cannot be done.
• Give a clear next step.
• Set boundaries if abuse continues.
• Escalate serious complaints appropriately.

Example:

I understand that losing access before your event is frustrating. I cannot change channel ownership without verification, but I can collect the required information and escalate it to the Services team.

Avoid:

Calm down.
Stop complaining.
I am staff, so do what I say.
If you continue asking, I will ban you.

11. De-escalation

De-escalation means reducing conflict while still enforcing necessary boundaries.

Useful techniques include:

• Use the person’s current nickname respectfully.
• Acknowledge the concern without automatically agreeing.
• State verified facts.
• Avoid blame-focused language.
• Give clear choices.
• Explain the next step.
• Avoid arguing about unrelated issues.
• Move sensitive discussion away from public channels.
• Request help from another staff member when needed.

Example:

I understand that you disagree with the ban. I will not debate private evidence in the public channel. Please provide the channel, approximate time, and ban reason so the authorized team can review it.

De-escalation does not require staff to tolerate threats, flooding, or continued abuse.

12. Language and Accessibility

DarkWorld is an international community. Users may:

• Speak English as a second language.
• Use translation tools.
• Have difficulty with technical terminology.
• Use a mobile client.
• Have visual or other accessibility needs.
• Require additional time to follow steps.

Staff should:

• Use short sentences.
• Avoid unnecessary slang.
• Avoid mocking spelling or grammar.
• Give commands in copyable form.
• Explain one step at a time.
• Confirm understanding.
• Use screenshots only when text instructions are insufficient.
• Provide official translated material where available.
• Request help from another staff member if language prevents accurate support.

13. Cultural and Personal Neutrality

Staff must not discriminate based on:

• Nationality.
• Race or ethnicity.
• Religion.
• Gender.
• Disability.
• Sexual orientation.
• Language.
• Age.
• Political views.
• Social or economic status.
• Technical ability.

Personal disagreement does not justify denying support.

Staff may enforce applicable channel or network rules neutrally without endorsing a user’s beliefs.

14. Project Boundaries

Not every question in `#Support` belongs to DWIRC staff.

Examples:

Request	Appropriate destination
Cannot connect to IRC	DWIRC support
NickServ account problem	DWIRC support or Services staff
Channel ban appeal	Channel management or authorized DWIRC review
Increase shell disk quota	DWShells staff
Create or modify ZNC account	DWBouncers staff
Game-server issue	Relevant game or DWGames staff
Advertising application status	Policy team
Relay registration status	Relay team
Website account problem	Relevant website or project administrator

A DWIRC staff member may help identify the correct team but must not make unauthorized changes in another project.

15. Support vs Abuse Reports

A support request asks for help using the network.

An abuse report alleges harmful or prohibited conduct.

Some cases contain both.

Example:

A user cannot join a channel because another person is repeatedly evading bans and taking their nickname.

The connection or nickname aspect may be support, while the evasion and impersonation aspect may require an abuse investigation.

Support staff should:

1. Help with the immediate safe issue.
2. Preserve relevant information.
3. Avoid conducting an unauthorized investigation.
4. Move sensitive evidence to the approved process.
5. Escalate the abuse component.

16. Support vs Policy Decisions

Support staff may explain public policy, but not every support staff member is authorized to:

• Approve advertising.
• Register a relay.
• Decide a complex policy appeal.
• Suspend an approved project.
• Revoke a verified presence.
• Change an account owner.
• Impose a permanent network sanction.

A useful response is:

I can explain the policy and help you locate the application status. The final decision must be made by the authorized policy team.

17. Handling Staff Complaints

A user may report misconduct by a staff member.

The receiving staff member should:

1. Remain neutral.
2. Avoid defending or condemning the staff member immediately.
3. Identify the action being reported.
4. Preserve the relevant information.
5. Protect the complainant from retaliation.
6. Avoid discussing private staff matters publicly.
7. Escalate to an appropriate senior or independent reviewer.
8. Record the complaint through the approved process.
9. Inform the user of the next available step.

A staff complaint must not be sent solely to the person being accused when independent review is required.

Criticism of staff is not automatically a policy violation.

18. Recognizing Network-Wide Problems

A report may indicate a wider incident when:

• Multiple users cannot connect.
• Many users report SASL failures.
• NickServ and ChanServ are unavailable.
• Users on one server disconnect together.
• Several channels report the same flood.
• Certificate warnings affect multiple users.
• Server links repeatedly fail.
• Network latency becomes widespread.
• Many users receive similar phishing messages.

When this occurs:

1. Record the approximate start time.
2. Identify the affected server or service.
3. Determine whether multiple users are affected.
4. Notify authorized operational staff.
5. Avoid telling every user to change unrelated settings.
6. Provide an approved status message.
7. Confirm when service is restored.

19. Security Emergencies

Escalate immediately when support reveals:

• A compromised staff account.
• Services impersonation.
• Credential phishing.
• A serious vulnerability.
• A leaked password or token.
• A network attack.
• Widespread malicious activity.
• Unauthorized administrative access.
• Exposure of private user information.
• Threats involving immediate danger.

Do not investigate high-risk systems beyond your authorization.

Preserve essential information and notify the correct senior staff.

20. Giving Safe Commands

Before giving a command:

1. Confirm that it matches the current Services or server version.
2. Confirm the target nickname or channel.
3. Explain what the command will do.
4. Identify whether it is reversible.
5. Warn about any destructive effect.
6. Keep credentials out of the example.
7. Confirm that the user has authority.
8. Use official help where possible.

Do not provide destructive commands casually, such as commands that:

• Drop a channel.
• Delete an account.
• Clear access lists.
• Remove all bans.
• Change channel ownership.
• Expose a channel key.
• Disable security.
• Disconnect many users.

21. Handling Unknown Problems

Staff are not expected to know everything.

When uncertain:

I am not certain which setting is causing this. I will summarize what we have checked and escalate it to the appropriate team.

This is better than guessing.

A useful escalation summary prevents the next staff member from repeating every troubleshooting step.

22. Escalation Summary Template

Date and time:
Support channel:
User nickname:
Registered account, if relevant:
Affected service or channel:
User’s goal:
Exact error:
Client and version:
Server and port:
TLS enabled:
SASL enabled:
When the problem started:
Steps already attempted:
Results:
Number of affected users:
Security or privacy concern:
Evidence location:
Recommended next team:

Do not include passwords, tokens, private keys, or unnecessary personal information.

23. Closing a Support Case

Before closing, confirm:

• Whether the original problem was resolved.
• Which action solved it.
• Whether the user understands the result.
• Whether any security follow-up is required.
• Whether saved passwords or configurations need updating.
• Whether the case must be documented.
• Whether documentation should be improved.

Example:

Your connection is now using TLS on port 6697, and WHOIS confirms that SASL authenticated your account. Please update the same saved password on any other IRC clients or bouncers you use.

If unresolved:

We confirmed that the issue affects multiple users and is not limited to your client. It has been escalated to the network operations team with the relevant time and error details.

24. Support Documentation

A recurring issue should be documented when:

• Many users report it.
• The solution is not obvious.
• Existing instructions are outdated.
• A client uses unusual settings.
• A new Services behavior affects users.
• Staff repeatedly give inconsistent answers.
• A safe recovery process needs clarification.

Documentation should include:

• Problem symptoms.
• Supported environments.
• Safe diagnostic steps.
• Expected results.
• Known limitations.
• Escalation conditions.
• Last verification date.

Passwords, tokens, private logs, and confidential system details must not be included.

25. Example Support Conversations

Example 1: Connection Failure

User:

I cannot connect. IRC is not working.

Staff:

Hello. Which IRC client are you using, and what exact error appears? Please also confirm that the server is irc.darkworld.network, the port is 6697, and TLS is enabled.

Example 2: SASL Failure

User:

SASL authentication failed.

Staff:

Please confirm privately in your client that the SASL username is your registered NickServ account, not necessarily your current nickname. Also confirm that TLS is enabled and that the account has completed email confirmation. Do not post your password here.

Example 3: Channel Access

User:

ChanServ did not give me operator status.

Staff:

Please identify to your registered account and run WHOIS on your nickname. Confirm which account is shown and the channel involved. We can then check whether the issue concerns your ChanServ access or only the current live channel mode.

Example 4: Project Request

User:

Increase my DWShells account storage.

Staff:

That request belongs to the DWShells team rather than DWIRC staff. I can direct you to the approved DWShells support channel or request process.

Example 5: Ban Complaint

User:

Your staff are corrupt. Remove my ban now.

Staff:

I can help you request a review. Please provide the affected channel, approximate time, nickname used, and the ban reason. Private evidence should be submitted through the approved process rather than posted publicly.

26. Common Support Mistakes

Providing Too Many Steps

The user receives a large block of commands and cannot determine which one matters.

Asking for Credentials

Staff request a password when only the error message is required.

Assuming User Error

A wider Services or server outage is incorrectly blamed on the user.

Giving Outdated Commands

Commands are copied from another network or Anope version without checking current help.

Solving the Wrong Project’s Issue

DWIRC staff attempt to modify DWShells or DWBouncers resources without authority.

Arguing Publicly

A support discussion becomes a personal conflict.

Promising an Outcome

A trainee promises that an account, channel, or approval will be granted.

Closing Too Early

The staff member gives a command but never confirms whether it worked.

27. Practical Exercises

Exercise 1: New User Assistance

Guide a trainer acting as a new user through:

• Connecting to `irc.darkworld.network`.
• Using port `6697`.
• Enabling TLS.
• Choosing a nickname.
• Joining an approved channel.
• Finding NickServ help.

Do not ask for or handle the user’s password.

Exercise 2: SASL Troubleshooting

The trainer will provide a simulated SASL error.

The candidate must:

1. Ask for the exact error.
2. Confirm TLS.
3. Confirm the account-name field.
4. Confirm account registration.
5. Identify saved-password problems.
6. Escalate if the issue affects multiple users.

Exercise 3: Channel Access Problem

A simulated user is identified but does not receive channel operator status.

The candidate must distinguish between:

• Current nickname.
• Registered account.
• ChanServ access.
• Live channel status.
• Mode lock.
• Possible Services outage.

Exercise 4: Angry User

The trainer acts as an angry user disputing a ban.

The candidate must:

• Remain calm.
• Avoid arguing.
• Collect relevant details.
• Explain the review process.
• Protect private evidence.
• Avoid promising removal.

Exercise 5: Project Boundary

The trainer requests a DWShells or DWBouncers administrative action.

The candidate must direct the request to the correct team without claiming authority.

Exercise 6: Escalation Summary

Using one of the simulated cases, prepare a complete escalation summary without including sensitive credentials.

28. Practical Scenarios

Scenario 1: New User Posts Password

A new user includes their NickServ password while asking why authentication failed.

Recommended response:

Do not quote the password. Tell the user to change it immediately, update saved SASL credentials, and follow the approved compromised-account procedure if necessary.

Scenario 2: Widespread Certificate Error

Five users report the same TLS certificate error.

Recommended response:

Treat it as a possible network-side issue. Record the hostname, error, and time; notify operations; and do not advise users to disable certificate verification.

Scenario 3: Repeated Question

A user asks the same question several times because they do not understand the answer.

Recommended response:

Rephrase the instruction in simpler language, provide one step at a time, and confirm the result after each step.

Scenario 4: Staff Complaint

A user says an IRC operator banned them after a personal argument.

Recommended response:

Preserve the report, avoid prejudging either side, and escalate it for independent review. Do not send the complaint only to the accused operator.

Scenario 5: Unknown Client

A user uses an IRC client the staff member has never seen.

Recommended response:

Ask for the client name, version, available connection fields, and exact error. Use protocol-level settings and official client documentation rather than guessing.

Scenario 6: Multiple Project Issue

A user can connect to IRC but their DWBouncers account no longer connects automatically.

Recommended response:

Confirm that DWIRC itself is reachable, then direct the bouncer-specific account or configuration issue to authorized DWBouncers support.

29. Knowledge Check

Answer the following questions in your own words:

1. What is the primary goal of user support?
2. What are the main stages of the support workflow?
3. Why should staff first understand the user’s goal?
4. What information is useful for an IRC connection problem?
5. What information should never be requested publicly?
6. Why should troubleshooting normally proceed one step at a time?
7. What makes a support response easy to follow?
8. How should staff explain technical terminology to beginners?
9. What should staff do if a user posts a password?
10. Is a private message automatically a suitable permanent evidence system?
11. How should staff respond to an angry user?
12. What is de-escalation?
13. Does acknowledging frustration mean agreeing with every claim?
14. How should language barriers be handled?
15. Can personal disagreement justify denying support?
16. Why must DWIRC staff respect other project boundaries?
17. What is the difference between support and an abuse investigation?
18. May ordinary support staff approve advertising or relay applications?
19. How should a staff complaint be handled?
20. What signs may indicate a network-wide problem?
21. When must a security matter be escalated immediately?
22. What should staff verify before providing a sensitive command?
23. Why is guessing dangerous in support?
24. What information belongs in an escalation summary?
25. What must be excluded from an escalation summary?
26. What should be confirmed before closing a case?
27. When should recurring problems be documented?
28. Why should staff avoid promising a particular administrative outcome?
29. What should happen if an issue remains unresolved?
30. How should a candidate respond after giving incorrect guidance?

30. Written Assignment

Write approximately 700–1,000 words responding to this case:

A new user cannot connect to DarkWorld IRC. They say their client shows a certificate warning and SASL failure. They publicly paste their account password while asking for help. At the same time, three other users report the same certificate warning. The user becomes angry and accuses staff of ignoring them.

Your answer must explain:

• How to acknowledge the user.
• What immediate password-security action is required.
• Which diagnostic questions should be asked.
• Why certificate verification should not simply be disabled.
• Why multiple reports change the incident classification.
• How to handle the user’s frustration.
• What must be escalated.
• What information should be recorded.
• What information must not be repeated.
• How the case should be closed or handed over.

31. Module Completion Requirements

To complete this module, the candidate must:

• Read the complete lesson.
• Complete all six practical exercises.
• Correctly answer at least 23 of the 30 knowledge-check questions.
• Complete the written assignment.
• Pass the angry-user roleplay.
• Demonstrate safe credential handling.
• Prepare an acceptable escalation summary.
• Receive trainer approval.

32. Trainer Evaluation

Evaluation area	Maximum points
Understanding the user’s problem	15
Diagnostic questioning	15
Accuracy of guidance	15
Communication and clarity	15
De-escalation and professionalism	15
Privacy and credential security	15
Escalation and documentation	10
Total	100

Recommended passing score: 75 points.

A candidate should not pass if they:

• Request or expose credentials.
• Insult or threaten users.
• Repeatedly provide unsafe instructions.
• Ignore project boundaries.
• Hide mistakes.
• Fail to escalate serious security issues.
• Use support access for retaliation.

33. Quick Support Checklist

1. What is the user trying to do?
2. What exact error occurred?
3. Which client, server, and port are involved?
4. Is TLS enabled and verified?
5. Is the issue limited to one user?
6. Is any password or private information exposed?
7. Does this belong to DWIRC or another project?
8. What is the safest next step?
9. Do I have authority to handle it?
10. Does it require escalation?
11. Has the result been confirmed?
12. Does the case require documentation?

34. Next Module

After passing this module, continue to:

Module 7 — IRC Moderation

---

Previous: Module 5 — IRC Services Program: DarkWorld IRC Staff Training Program Next: Module 7 — IRC Moderation