Kunark Era Customer Service Guidelines

This document originally came from [1] (if that link doesn't work Google has a cached version). For other eras of the same document see Customer Service Guidelines.

The exact date/revision of this version is unknown. Another version (possibly the same?) can be found at[2], and that version is dated 3/15/99.

Customer Service Guidelines for EverQuest

Scope: This document covers all of the policies for all members of the EverQuest Customer Service Program and the procedures for them to follow to enforce these policies.

The term “Customer service” includes all interactions with players/testers, and includes everything from first-level technical support to public relations. The goal is to support and enhance the playing experience for customers, and to provide an interface between the customers and Verant Interactive. Although there are defined customer service groups (Guides and certain GMs), any employee of Verant Interactive or member of Guide Program interacting with a customer for any reason is performing customer service and should be following these same guidelines.

The customer service organization is the “face” that Verant Interactive presents to the customer. As such it is very important that all actions taken by customer service be ethical and professional and avoid even the appearance of favoritism or conflict of interest. These guidelines provide customer service personnel with a way to handle customer situations that will ensure consistent and professional behavior.

Mission Statement:

"To support, educate, and direct the customers of EverQuest to create an enjoyable and immersive Role Playing experience."

1. Customer Service Roles and Responsibilities

1.1 Avatar Levels

There are six levels of participation in the EverQuest Customer Service Program: Candidate, Apprentice Guide, Guide, Senior Guide, Elder Guide, and Game Master (GM.) Within the GM caste, there are three levels of Verant Interactive employees performing CS services: GM-Admin, GM-Lead Admin, and GM-Mgmt.

1.2 Candidates

Candidates are those who have expressed an interest in becoming part of the program. They have passed the application process; after having their age verified they are awaiting further contact for entrance into the program. In the tradition of “walking a mile in his moccasins”, no player can be considered a candidate for Apprentice Guide until they have played a minimum of 2 characters up to at least 10th level. Without this experience, it is not possible to understand the frustrations a customer can feel. A Candidate will not be assigned to a server on which they have a play character. Should the candidate play on the server to which they are assigned, they should contact the EQ CS Program member who sent them their invitation e-mail to be reassigned. No member of the Guide Program should ever have a play character on any server on which they also have a Guide Avatar.

1.3 Apprentice Guides

Apprentice Guides are Members of the guide program who have been chosen from the list of Candidates and are under review by the Server Team to determine their suitability for the program. They have no powers and are mostly relegated to answering questions and learning. The Apprentice period has no minimum length, but shall last no longer than 1 month. During this time, a seasoned Guide mentors the Apprentice until they are comfortable addressing customer issues on their own.

1.3.1 The Senior Guides and other experienced Guides on a server will mentor the Apprentice Guides on that server, providing guidance and assessing their performance.

1.3.2 New Apprentice Guides must choose a name they have not used previously either as an EverQuest character or in any public association with EverQuest. The name must conform to the Naming Policy. (ref. 8.3 The EverQuest Naming Policy)

1.3.3 Since Apprentices serve on a probationary basis, they are not fully "guided" when they join the program. They are partially buffed, made non-aggressive to all monsters, and given some basic Guide tools.

1.3.3.1 Apprentices are allowed to explore freely any area, with the exception of zones listed below as "apprentice-restricted zones." They are forbidden from exploring these more difficult areas of the game to reduce the amount of knowledge they can take with them should they not become guides. Apprentices may not be bound to any restricted zone. The list of restricted zones is as follows:

Arena					Najena
Befallen				Nurga
Cazic-Thule				Old Sebilis
Chardok				        Permafrost
City of Mist				Plane of Fear
Crushbone				Plane of Hate
Dalnir					Plane of Sky
Droga					Skyfire Mountains
Howling Stones (Charasis)		Solusek A
Kaesora				        Solusek B
Karnor’s Castle				Split Paw
Kedge Keep				Unrest
Kurn’s Tower				Upper Guk
Lower Guk				Veeshan’s Peak
Mistmoore

For easy reference, the apprentice-restricted zone list is simply the list of dungeon zones shown in the Appendix C, plus Skyfire Mountains and City of Mist.

1.3.3.2 The following zones are also apprentice-restricted, with the following exception: an Apprentice may, after informing the CS staff online via /pr, travel through the following zones for the sole purpose of reaching the zone on the other side. Apprentices may not explore these zones and may not be bound to these zones.

Blackburrow 				Runnyeye

1.3.4 The responsibilities of the Apprentice Guides are to:

• Answer /petitions
• Explore the world to learn it as much, if not more, than the players
• Participate in Answer Circles (an informal question and answer session in a safe area)
• Assist the other Guides as needed

1.3.5 The things an Apprentice does not do (in addition to the restrictions of the Guides below) are:

• Explore apprentice-restricted zones as listed in 1.3.3
• Handle exploitation, abuse, or any other exception calls as anything more than a witness to a Guide
• Be online without a full Guide
• Be anonymous. Exception: an Apprentice may use /anon right before camping. When the Apprentice logs in again and verifies that a full Guide is online, he or she must go un-anonymous again. This exception is to prevent the Apprentice from receiving /tells for help when he or she is not allowed to remain online. As well, they may also go /anon at the direction of a Senior Guide or mentoring Guide.

1.4 Guides

Guides are the mainstay of the Guide Program and are the most numerous rank. When all members of the Server Management team approve an Apprentice on their server, they are promoted to Guide. Once a Guide, it is possible to remain one indefinitely, as this is the most critical function of the Guide Program. Guides are expected to contribute a minimum of 10 hours per week to the program. There should be no fewer than 40 Guides per server.

1.4.1 Guides are the first line of contact for the customers. As such, they are responsible for the first level of escalation for problems and issues. They handle the immediate issues, answer game play questions, and in general are responsible for resolution of first level problems.

1.4.2 Problems that are not resolvable in a reasonable amount of time or those that involve an angry customer who cannot be placated should be escalated to the Server Management Team (the Senior Guides and GM-Admin assigned to that server.) It is anticipated that the overall volume of petitions will be high. If a Guide finds that one petitioner is monopolizing them to the extent that the incoming petitions are not being handled, the Guide should pass the call to a member of the Server Management Team if one is available.

1.4.3 In situations that are covered by the Incident Policies and Procedures below, the Guide’s primary role is investigator. Guides are not agents of enforcement. They gather information and make sure the Server Management Team has enough information to make the correct decision. Any Guide involved in an emergency situation, which is not covered by these policies, should escalate to a member of the Server Management Team if one is online. If no member of the Server Management Team is online, the Guide should handle the situation using whichever of the policies below most closely suits the situation to the best of their judgment. This action should be followed up by an email notification to the Server Management Team for review.

1.4.4 The responsibilities of the Guides (in addition to the duties of an Apprentice) are to:

• Perform CRs (Corpse Retrievals) and unstick players
• Mentor, train, and supervise the Apprentices
• Assist in event administration as authorized by this document and the Guide’s Server Management Team
• Handle escalations
• Investigate candidates for the Guide program.

1.4.5 The things a Guide does not do:

• Run or create dynamic quests and quest characters independently
• Reprimand Apprentices (to include any form of hazing)
• Chastise Customers or Apprentices
• Speak for the Guide Program as a whole in a public forum (Bulletin Boards, Newsgroups, etc.)

1.5 Senior Guides

Senior Guides are proven Guides who have shown good judgment and are willing to invest extra time in the program. They handle the more difficult problems, the administration of the program and most of the escalations for their server. Senior Guides answer questions along with the Guides when the load becomes excessive, but are primarily responsible for working together with the server GM-Admin to administer their server.

1.5.1 Senior Guides train, mentor, and audit the Guides and Apprentices on their server, and coordinate the dynamic quests and events for their server. The Senior Guides for a particular server are responsible for the success of the Guide Program on that server, in all aspects. Senior Guides are created from the ranks of the Guides when there is a suitable candidate, and when a review of the workload makes it a reasonable action.

1.5.2 Senior Guides are not losing responsibility, but gaining additional responsibility, and as such are expected to contribute at least 4-6 hours per week in additional time, though not all of this time needs to be spent online. There will be at minimum 1 Senior Guide for every 20 Guides, although this number may increase depending on the types of work to be done and the pool of available candidates. Creating a Senior Guide requires the approval of all of the Elder Guides and at least one GM-Admin.

1.5.3 Senior Guides handle all escalations from their Guides and provide another level of customer service, especially to angry or dissatisfied customers. They support the Guides in all aspects of their job, taking referrals from the Guides when any petition becomes overly long, or a customer refuses to be satisfied.

1.5.4 During an Exception Incident (described below), Seniors are detectives, but can also engage the customer and attempt to defuse the situation. However, this is only done if the accused customer is not a recidivist. In the event of a repeat offender, the Senior does nothing more than gather information and await the arrival of a GM or Elder Guide.

1.5.5 The responsibilities of the Senior Guides for their particular server (in addition to the duties of a Guide) are:

• Manage the Guide Program on their server
• Assist Elders as needed
• Provide the communication focal point for their server, passing information from the Elders, Guide Liaison, and Verant Interactive to their Guide population and reporting status and Exception Incidents from their server to the Elders and Verant Interactive.

1.5.6 Senior Guides also have duties that are program-wide, in addition to the responsibilities for their assigned server. Seniors should have a clear understanding of when they are acting on behalf of their assigned server, and when they are acting in a program-wide capacity, and should be able to represent both of these views appropriately. The following roles will be handled by a Senior Guide or a team of Senior Guides, according to the volume of work required. In some cases, Seniors may coordinate these types of work, delegating parts of it to a Guide or Guides. This can be particularly useful when the workload is heavy and when the Senior team for a server would like to evaluate a Guide wishing to become a Senior Guide.

Note: Each of these teams is comprised of at least 5 Senior Guides, 2 Verant Interactive employees, and 1 Senior Guide acting in the role of Chairperson. This structure was implemented for the Customer Service Program Reorganization to streamline the decision making process for the upcoming changes to the Program.

• Personnel Team: Responsible for all issues pertaining to personnel, this team is formed of several distinct parts, all of which work closely together.  Admin, Training, SWAT, Graders, and Webmaster.  They manage server levels, initial apprentice training, emergency response, candidate interviewing, and the EverQuest Customer Service web site at http://guide.everquest.com.
• Communications Team: This team handles the matters of intra-program communication; channels of communication, reporting, and any templates for communicating. They facilitate all levels of communication within the Customer Service Program. The team will also be tasked with providing the Guide Program a unified voice to the public.
• Quest Team: Responsible for all things that are dynamic quest or event related. They will review and implement quest policy. They review, revise and test quests submitted for performance. They work closely with Verant Interactive on any quest performance related problems which occur and will provide assistance with the running of quests where required.
• Policy Team: The group responsible for collecting input on, drafting, ratifying, and interpreting the Policies and Procedures of the Customer Service Program. They maintain all of the core documents of the Program.

1.6 Elder Guides

Elder Guides are the consulting and management arm of the Guide program. They are responsible for the welfare of the Guide program as a whole. Elder Guides are the highest escalation point in the Guide Program.

1.7 Verant Interactive Game Masters

The Game Masters are split into several categories, each with different responsibilities and levels of authority, though all must follow these guidelines while in-game and wearing a GM flag:

• GM-Admins are the GM’s that work within Verant Interactive and are responsible for providing customer service. These GM’s answer /petitions as needed (i.e. when the load is excessive) and use their expanded abilities to provide support to the Guides on duty in addition to customer service responsibilities outside the game. These GM’s are also responsible for monitoring the EQ Chat area and answering questions there, as well as email support.
• GM-Lead Admins are the managers of the GM-Admins.
• GM-Mgmt are the highest authority of GM’s in the game and the final arbiters in all disputes, escalations, and issues of policy and discipline.
• GM-Testers, GM-Coders, GM-Areas, and GM-Art - While these GM’s have no customer service responsibilities, should remain /anonymous and should avoid unnecessary customer contact, they are Verant Interactive employees and should be treated accordingly.

2. The Customer Service Interface and Tools

2.1 The Customer Service Interface

2.1.1 The /PRivate Channel GM/Guide internal communications are handled through the use of the GM-only channel, /PRivate. Guides and GMs also use this channel to speak privately among the group across all zones.

2.1.2 The /Petition Queuing Tool When a customer types /petition <msg>, an entry is created at the bottom of the /petition queuing system. These entries are sorted in reverse chronological order, the oldest entries being at the top.

2.1.2.1 To access the Queuing tool, press “G” to access the GM menu, then press “PETITION”. This brings up the list of account names on the right side of the primary viewing screen, translucent over any terrain or NPCs that is viewed. The list has the oldest dozen entries that are in need of attention, sorted first in urgency order, then chronological order.

2.1.2.2 At the very top will be any calls that have been escalated as emergency. Emergency queue entries are escalations to Seniors, Elders, and GMs and are red in color.

2.1.2.3 Next will be the urgent ones, which are yellow in color and are escalations for any powered Guide, usually from an Apprentice that is not able to service the call.

2.1.2.4 Below the urgent petitions are the normal priority calls colored in green. All petitions enter the queue in this state and will remain a normal priority until they are escalated for more immediate handling.

2.1.3 Taking a Call It is the desire of the Guide program to answer every petition, no matter how trivial, even if the answer is “I’m sorry, but we’re not able to do that.” All customers are important and all need to feel like we care and listen to them.

2.1.3.1 To take a call, simply click on it in the /petition queue. This “checks it out” and the Guide now “owns” this entry. The entry is no longer in the queue but only in the hands of the Guide that checked it out. The screen changes to the “Open Item” screen, which has the following items in it:

2.1.3.2 Interface Buttons (along the left hand side)

User Text		Displays the customer’s /petition text into the Guide’s text box
GM Text			Displays any text appended by a Guide/GM into the Guide’s text box
Append Text		Appends text to the GM Text section (see below)
Downgrade		Reduces the urgency of the /petition
Escalate		Increases the urgency of the /petition
Unavailable		Increases the unavailable counter (for player offline or not responding)
Log Bug			Logs the call into the /bug database
Log Feedback		Logs the call into the /feedback database
Log Guidelog		Logs the call into the Guide Logbook (currently not functional)
Check In		Puts the /petition back in the queue
Undo Checkout		As Check In, but undoes any text added to the /petition
Delete Petition		Removes the petition from the queue

2.1.3.3 Interface Fields (down the center)

Urgency			Normal/Urgent/Emergency
User handle		Station name of petitioning player
Last Guide		Station name of last Guide to handle the call
Zone			Zone the player petitioned from
Character		Character name of the petitioning player
Level			Level of the petitioning player
Class			Class of the petitioning player
Race			Race of the petitioning player

2.1.3.4 The Append Text button To append GM text to a petition, type the text into the text area as if you were speaking, then press the Append Text button instead of the Enter key. Unfortunately, appended text is currently buggy: the first time the petition is checked back in the appended text changes to “IllegalDta.” To get around this bug, you must type some random word, press Append Text, check the petition in, check it back out, and then type the actual message and press Append Text again. Escalate the petition before doing this to avoid losing it in a large queue.

2.1.3.5 Normal Calls Most calls fall into the “Normal” category. To handle a normal call, check the call out and contact the customer. Follow any of the procedures listed elsewhere in this document to handle the call until it is completed. Once completed, press “Delete Petition” and move on to the next call.

2.1.3.6 Bug Calls If a call turns out to be a bug report, then investigate the bug as quickly as possible to gather whatever additional information is necessary to file a bug report. The types of information needed are pertinent to the bug in question:

• Zone where the problem occurred
• Description of the location, as specifically as possible
• Name of any NPCs involved
• Specific steps to recreate

2.1.3.6.1 Use “Append Text” to add all the information to the queue entry, then press “Log Bug”. This will put the bug into the /bug database. Once the call is complete, press “Delete Petition” and move on to the next call.

2.1.3.7 Feedback Calls If a call turns out to be customer feedback, gather as much additional information as possible to make the request complete, use “Append Text” to add the information to the queue entry, then press “Log Feedback” to put the request into the /feedback database. Once the call is complete, press “Delete Petition” and move on to the next call.

2.1.3.8 Unusual or Problem Calls If there is a problem with a call that does not fall into any of the above categories, or that a Guide feels is noteworthy, the Guide needs to record the pertinent details and include an accurate account of the incident in their Shift Report. If escalation is not necessary, and the call is complete, click the Delete Petition button and move to the next call.

2.1.3.8.1 Verant Interactive Customer Service reviews this log regularly and issues that are placed here can be resolved offline as needed.

2.1.3.9 Calls from other sources The customer service staff will frequently receive tells or in-person communications from players. The order in which communications should be handled is petitions, in-person conversations, then tells. Any customer service calls that come in via /tell should be encouraged to utilize /petition to ensure the customer has an avenue of support when the Guide they are speaking to is not online.

2.1.3.9.1 Customer service staff should not respond to /shout and /ooc communications. When the staff is involved with in-person communications, it should be handled in as personable a manner as possible. This includes role-playing whenever it is possible to do so, as well as making an effort to show an interest in the player, enthusiasm in the game, and encouraging good gaming behavior.

2.1.3.9.2 Unavailable Petitioners - Whenever a petitioner does not show on /who all <station name> for one minute or fails to answer two consecutive tells and they have been given at least 2 minutes to respond, the petitioner is considered unavailable. If there are 25 or fewer petitions in the queue, the petition should be marked as UNAVAILABLE with the UNAVAILABLE button and CHECKED IN so that the petition can be answered later. If there are more than 25 petitions in the queue, after a reasonable attempt has been made to contact the customer, the petition may be deleted. Whenever a petition has an UNAVAILABLE COUNT of three or more and a reasonable attempt to contact the petitioner has been made, the petition should be deleted.

2.2 Customer Service Commands

2.2.1 The following commands are available to all full Guides:

/find <playername> or <NPCfirstname_ NPClastname##> or <playername>’s corpse<#> - Used to find the location of a player, player’s corpse or NPC. Intra-zone command.

G - Brings up the GM menu/Queuing Tool.

/goto <playername> or <NPCfirstname_ NPClastname##> - Used to go to a player or NPC. Inter-zone/Intra-zone command. If the parameters are left out, /goto will take the Guide to the targeted PC/NPC/corpse.

/hideme –the GM version of hide. Used for investigations. It will synchronize your /anonymous status with your visibility state. Note: you must target yourself to use this command. The command does not work on anyone but yourself, even though you will receive messages saying that it did. You will no longer be hidden upon zoning, as well. There have been reported anomalies with Area of Effect spells and tracking.

/kill - kills the targeted NPC, leaving no corpse. Only used to clear out stuck/broken NPCs, and only after attempting all other avenues of resolution (i.e. Wand of Memory, etc.)

/private - used to speak on the private channel

/servers – This will show the availability of all zones on a server. The list is ordered with the most recently available zones on top.

/summon <playername> - Used to bring a player to you. Inter-zone command. /Summon without a parameter summons the player or corpse currently targeted.

/summon <playername>’s Corpse<#> - Used to summon a player’s corpse. Intra-zone command. Always use the summoning procedures when using this tool.

/toggle <on/off> Used to toggle your availability to receive /tells on and off at the server .

/zone <zonename> – see Appendix B> - Used to go to any zone. Takes you to a “safe point” in the zone. Always use the summoning procedures when using this tool.

/searchcorpse <playername>- used to verify the existence of a corpse and to discover the zone in which it is located

2.2.2 The following commands are available to all Senior and Elder Guides:

/becomenpc <race#> [<gender=M, F, N> <material#> <head#> <height#>] - Change the form of the targeted PC or NPC, converting them into an NPC (full PvP) Not all <race#> are available in every zone. Some are “global”, such as the PC races, and others are local and only appear in some zones. Used discretely, never in front of players, and usually in conjunction with Quest preparations.

/broadcast <message> Will send that notice message to all players who are online on that server.

/height <#> -used to change the height of the target PC or NPC. /height 0 returns the targeted player to the default height for the player’s current race. DO NOT EXCEED /height 98, as that will corrupt the character’s file and require external repairs before the character can log back in again.

/kick - used to kick a player from the game and send them back to the character selection screen. This is only used to remove players that are hung and are unable to log in, and usually only at the players request (i.e. they log in with another character that has the same account, or ask via the chat server, to have their character logged out.)

/name <oldname> <newname> [b] - Used to change player’s names. The b is optional and will dump the original name to the name filter when used. This command cannot be used to add last names or titles. Always follow the naming procedures in using this tool.

/lastname - used to grant last names to players who have reached 20th level

2.3 Customer Service Tools

2.3.1 The following Tools are available to all Guides of Apprentice level and up:

Staff of Guidance – Creates a gate effect when used, returning the CS Representative to their bind point.

2.3.2 The following Tools are available to all full Guides and up. Unless otherwise noted in this document, all of these tools are to be used on CS Representatives only, not on customers. CS armor comes in three varieties: Armor of the Righteous, Armor of the Malign, and Verdant Armor. Except for appearance and name, there is no difference between the three types of CS armor.

• Robes of Guidance and Breastplates - This armor has the Guide Health effect, allowing Guides to regen health faster and to breathe underwater. This armor only needs to be worn for its effect.
• Helm - When activated it clears the memory of the targeted MOB making it forget at what or whom it is angry.
• Earring of Shifting Sight - Allows the CS Rep to see approximately what another PC or NPC is seeing. To activate the CS Representative should first target the PC or NPC and then right click on it. The item does have a spell effect, therefore the CS Representative will become visible at the time of activation. An anomaly can occur that will lock-up the view. The workaround is for the CS Representative to [TAB] to target themselves, cast it on themselves, move and then re-cast it. This tool also causes the user's stamina to drain.
• Ring of Escape - Will make you impervious to all attacks for 1 minute of real time, though no attacks are possible during this minute. Used primarily for fire and lava exploration.
• Ring of Banishing - Casts Cancel Magic (at 2x power), Cure Poison and Cure Disease.
• Earring of Life - Boosts the CS Representative's resistances considerably. Also will emit light when equipped (even when the CS Representative is invisible).
• Guide Telescope - Allows a CS Representative to zoom in approximately 20 feet. Also will emit light while equipped (even when the CS Representative is invisible).
• Collar - Casts shrink. The CS Representative must be in a dungeon zone for the item to cast successfully.
• Guise - While equipped the CS Representative will have Avatar Sight giving them ultra-vision and see invisible.
• Vambraces - While equipped the CS Representative will be under the influence of Troll's Essence, boosting strength, stamina, and health regen, but reducing intelligence.
• Gauntlets - Casts the spell ResurrectionGM. Currently there is a 2-hour limit on all resurrect spells, making it impossible for a corpse to be resurrected after 2 hours.
• Cape - Casts Bind Affinity on the targeted PC.
• Belt - Creates a gate effect when used, returning the CS Representative to their bind point.
• Greaves - Casts Spirit of Norrath on Self only. This provides a significant increase in movement speed.
• Boots - Casts Levitation on Self only. Allowing CS Representatives to safely travel on treacherous landscapes.
• Ceremonial Gown - A cosmetic piece without function.
• Words of Ceremony - A cosmetic piece without function

NOTE about all Guide Tools: All of the Guide tools are both “No Rent” and “Radioactive”. The Guide should not and can not drop, sell, or transfer any of these items. If, for some reason, one of these items should fall into the hands of a non-Guide/non-GM character, that character would be struck dead instantly.

2.4 Getting Equipped

2.4.1 Once a Guide is accepted into the Guide Program as an Apprentice, they must be outfitted for the job. When they are promoted to full Guide, further outfitting is required. If a Guide should lose their tools, usually due to a corpse loss, they need a way to re-acquire their tools.

2.4.2 The procedure an Apprentice follows to be robed, equipped and brought online is as follows:

• The Apprentice attends their training meeting prior to being robed.
• They then go to the server assigned to them by the Personnel Team at the time indicated in their buffing schedule, received from the Training Team.
• When they arrive, they create the character they selected, using the name they told their Server Management Team they would use, and log that character in.
• They do a /who all GM, locate a member of the Server Management Team or their trainer and send them a /tell, indicating they are present to be robed.
• The Apprentice is summoned to Sunset Home and waits for a GM-Admin.
• The GM-Admin shows up, turns on their GM flag, buffs them to 20th level, and gives them a Staff of Guidance.

2.4.3 When an Apprentice is promoted to full Guide, their powers are generally given to them before their tools or trappings. The process is as follows:

• A GM-Admin arrives on the server and /tells the Apprentice they are there to buff them.
• The GM /summons the Apprentice to Sunset Home.
• The GM buffs the Apprentice to 50th level and gives them a Guide Note.
• The new Guide takes the Guide note and gives it to the Quartermaster, who gives them a small amount of money in exchange. The Quartermaster explains to the Guide that he is there to serve them, providing them the tools they need to do their job.
• The Guide right clicks on the Quartermaster, buys the items available to them, and equips them.
• In addition, they must also purchase the Verdant Armor, Armor of the Righteous, or Armor of the Malign. They may substitute the breastplate for one of the Robes of Guidance available from the Erudite NPC, Dorala Kerlian if the robes are equip-able by their race, or, if they are a monk, they may replace the breastplate, greaves, and boots for Tranquil armor available from the Verdant armor merchant

2.4.4 The NPCs in Sunset Home only respond to the appropriate level of Guide, and only when they have given the Quartermaster their note. Once they are trading with the NPC, the Guide is free to return and re-purchase their tools at any time. This is particularly important when the tools are lost due to corpse loss or other such anomalies.

2.4.5 Apprentices and Guides may not make use of any spells or equipment from normal vendors or the GM-Admin vendors, and may not accept gifts of such items from players. If normal equipment is purchased as part of a bug investigation, it should be destroyed as soon as the investigation is complete. (Reference Section 5.4.7 No Hunting/Questing/Looting)

2.4.6 Once a newly promoted guide has verified that their name is blue in chat, they will change their chat name so that it is identical, or as close as possible to the name of their Guide Avatar. They may then cancel their account payment to receive their free account status.

2.5 Soulmarking

2.5.1 Soulmark Commands

All Full Guides+ have access to the following commands:

/praise – Adds a good soulmark to a player’s account.

Syntax: /praise {character’s name} {player’s Station ID#} {text}

Example: /praise Soandso 123456789 Player reported their duped corpse so that it could be removed.

/warn – Adds a warning soulmark to a player’s account.

Syntax: /warn {character’s name} {player’s Station ID#} {text}

Example: /warn Soandso 123456789 Was harassing Newbievictim (newbie_vic:555456789). Nature of abuse and warning of consequences of failure to desist were explained.

/inquire – Will bring up a graphical display of the soulmarks on an account on the server.

Syntax: /inquire {character’s name} {player’s Station ID#}

Example: /inquire Soandso 123456789

2.5.2 Soulmark Display

NAME	Character name of the Player on which the soulmark was placed

ID	Station ID number of the Player on which the soulmark was placed

GM NAME	Name of the CS Representative who placed the soulmark

GM ID	Station ID number of the CS Representative who placed the soulmark

DATE	Date the Soulmark was placed

TYPE	PRAISE/WARNING/NOTE

TEXT	Notation as entered by the CS Representative who placed the soulmark

DONE	Checks the Soulmark file back in

NEXT	Will display the next Soulmark in the file

PREV	Will display the previous Soulmark

2.5.3 Soulmark Procedures

2.5.3.1 Viewing a Player’s Soulmarks

Soulmarks can not be viewed by a CS Rep while they have a GM menu open or if the Name Approval dialog is up. The CS Rep should clear any such menus dialogs or menus before attempting to view a player’s soulmarks.

The CS Rep should then use the /who all command on the player to attain the correct spelling of the player’s character name as well as the player’s Station ID#.

The CS Rep should then use the /inquire command according to the format above to view the player’s soulmarks.

2.5.3.2 Adding a Praise/Note

Before adding a praise soulmark the CS Representative should use the /inquire command as described above to view any previous soulmarks to ensure that the soulmark has not already been filed by another CS Rep.

The CS Rep should then click on the DONE button to close the player’s soulmark file.

Finally the CS Rep should use the /praise command according to the format above to add a praise soulmark. If the /praise is to serve as a note, the text of it should start with ‘NOTE:’

After making the soulmark the CS Rep should use the /inquire command again to be certain that it was entered correctly.

2.5.3.3 Adding a Warning

Before adding a warning soulmark the CS Representative should use the /inquire command as described above to view any previous soulmarks to ensure that the soulmark has not already been filed by another CS Rep and so that the CS Rep will know if the player is a recidivist.

The CS Rep should then click on the DONE button to close the player’s soulmark file.

When appropriate as dictated by Exception Incident policy, the CS Rep should use the /warn command according to the format above to add a warning soulmark.

After making the soulmark the CS Rep should use the /inquire command again to be certain that it was entered correctly.

2.5.4 Soulmark Technical Issues

2.5.4.1 Saves – Whenever a CS Rep clicks on the DONE button on the Soulmark Display it will close the player’s soulmark file. The CS Rep may also receive a message that the Soulmark file is being saved. Unless the CS Rep is a GM+ this message is inaccurate. This is a noteworthy issue as more than one CS Rep may view the same player’s Soulmark file and soulmarks may be added to a file while it is being viewed.

2.5.4.2 Static Interface – If a CS Rep has a Soulmark file opened, the CS Rep will not see any soulmarks which are added until the file is closed and re-opened with the /inquire command.

2.5.4.3 TYPE – A CS Rep may be able to click on the Type button and the designated type of soulmark will cycle through the four possible types: PRAISE, WARNING, NOTE, and NULL. Except for GM+ none of these changes will be saved to the Player’s soulmark file.

2.5.4.4 GM+es Saves – While it will rarely be relevant, GM's+ should be aware that they can save older Soulmark files and effectively erase newer soulmarks if they check out the file while it is in use by another CS Rep. (ie: the GM clicks on DONE after another GM or Guide uses the /praise or /warn commands, or another GM clicks the DONE button).

2.5.5 General Soulmark Policy

2.5.5.1 Note

2.5.5.1.1 Making a Note – Sometimes it can be important to make a notation on a player’s account for the server and the notation is neither a praise nor a warning. If making the notation can be beneficial to tracking serious issues such as reimbursements, resurrections, CRs, etc, the /praise command should be used. The text of such notations should start with the word ‘NOTE:’ CS Reps should be selective about adding notes to player’s accounts and should add notes according to direction provided by their Server Management Team.

2.5.5.2 Praise

2.5.5.2.1 /Praise Restraint – We do want to keep track of good deeds of players, however the /praise command should be used sparingly when only being used to say what a wonderful player a person is. WARNINGs and NOTEs (or PRAISEs used as a note) can be beneficial to tracking undesirable behavior on a server. If soulmark files are cluttered with unnecessary PRAISes, this effect is reduced. CS Reps should be selective about adding PRAISEs to player’s accounts and should add praises according to direction provided by their Server Management Team. As mentioned above, CS Reps can add PRAISEs to an account to function as a NOTE. This praise policy does not apply to such notes.

2.5.5.3 Warnings

2.5.5.3.1 /Warn Restraint – Each WARNING in a player’s Soulmark file is considered an official record of that warning. Therefore CS Reps should only use the /warn command on a player’s account after they have warned the player.

2.5.5.3.2 Concurrent Use with Abuse Database – Soulmarking has the benefit of allowing CS Reps to immediately know if escalation is necessary in Exception Incident Investigations by letting us know if the player is a recidivist (repeat offender). Soulmarks do not follow players from server to server. Nor are soulmarks searchable. The Abuse Database is not server-specific and is searchable. Because of this, anytime a CS Rep makes a /warn soulmark, they must also file a report in the Abuse Database.

3. Communications

3.1 Communications between Verant Interactive and Customers

3.1.1 The official communication channels between Verant Interactive and EverQuest customers are the EverQuest web site at http://www.everquest.com, and the EverQuest_manual.txt file which is resident on every customer’s PC in the EQ directory and is also accessible by pressing the Help button below the EverQuest chat screen. Additions to the EverQuest_manual.txt file may also be seen on the patch screen. Customers should be told to check these sources on a regular basis for any information that the Verant Interactive staff wishes to communicate to the entire user base.

3.2 Communications between Customer Service Personnel and Customers

3.2.1 Communications between Customer Service personnel and EverQuest customers should be handled in as professional and courteous manner as possible. This is not to say that we must be serious and short with the customers. On the contrary, customer service personnel should attempt to roleplay their encounters with customers, portraying some personality and using humor where appropriate. We should at all times show good communications skills, speaking to the customer in correct English or a suitable role-play variant. Commonly used slang associated with hackers/cheaters/warez sites, etc. should not be used, as it is unprofessional. Foul language should never be used when speaking to customers.

3.2.2 Revealing your Guide identity

3.2.2.1 All players should be treated alike, regardless of whether they happen to also be Guides. The following rules are designed to avoid as much as possible the chance of guides showing favoritism to one another or using their Guide status to get favorable treatment from other players.

3.2.2.2 Guides are prohibited from having a player character on the same server they Guide on.

3.2.2.3 When you're logged in as a Guide, don't tell anyone who your non-Guide characters are.

3.2.2.4 When you're logged in as a non-Guide, don't tell anyone that you're a Guide or who your Guide characters are. The only exceptions are if a GM specifically asks you (since they could look it up anyway), or if you need to look for a Guide or GM on a server other than your own to help in an emergency on your own server. In the latter case you may create a new character on that server specifically for the purpose of talking to the staff.

3.2.2.5 Out in the real world, you can identify yourself with any of your characters. However, any time you identify yourself as a Guide, you are bound by the same rules as if you were Guiding in game. You should present yourself courteously and professionally, keeping in mind that those you are speaking with will see you as a Verant Interactive customer service representative. Remember also that confidential information (such as bug, exploit, or quest details) should never be revealed. (ref 3.5 Guides Posting to Public Boards)

3.3 Input to Customer Service Policies and Procedures

3.3.1 Customers as well as members of the CS staff will hold many opinions of what the customer service policies and practices should be. These opinions tend to surface at inappropriate times, such as when a customer is having a problem. Customers should be informed that the CS team follows any policies that are currently in place, and does not have the power to change them “on-the-fly” at the request of individual customers. Customers may provide input to the Guide Program by e-mailing the eqcs@verant.com address. All such submissions are reviewed by CS management. Members of the Guide program wishing to have input to the program policies should send such input to their Senior Guide.

3.4 Communications Among the Customer Support Staff

3.4.1 The official method of communication for the customer support staff is the EverQuest Guide web site, located at http://guide.everquest.com. Email communications may also be used less formally, or for communications between subsets of the staff (all CS staff on one server, all Senior CS staff, all new apprentices, etc.)

3.4.2 The EverQuest Guide web site consists of several message areas. Posts made to these areas will be mindful of the others reading them- no ranting, no non-constructive criticism, no profanity. Personal play issues should not be addressed on any of these boards; however general play issues and game mechanics may be addressed on the Laboratory. These message sections are:

• Server boards. Each server has its own message section. Apprentices and Guides can only see the board for their own server; Seniors and above can see all servers. All guides should post a report here for each shift they work (see The Nightly Report below).
• News. This is where the Customer Service Management will post important announcements. All guides should check this area on a regular basis.
• GM/Swat Help. Place all requests for emergency action response from the SWAT team and covering GM-Admins on this message board.
• The Common Hall. This is an open area for Guides to discuss any topics of interest. Newly discovered bugs and player issues are usually posted here.
• Backstage. This area is for discussing dynamic quests, from design through post-quest reports. Apprentices cannot see this board.
• Laboratory. This area is for discussing game mechanics, game balance, and technical problems.
• The Rumpus Room. This area is for guide humor and general fooling around.
• The Library. This area is for roleplaying and stories.
• The Senate: The area set aside for the Server Management Teams to discuss and provide a focal point for issues that need to be directed to Customer Service Management.

3.4.3 The EverQuest Guide web site also contains tools for scheduling Guide shifts and dynamic quests, submitting quest ideas, and filing abuse reports.

3.4.4 In addition, the Guides on a particular server may hold meetings on a regular basis to provide a forum for handling pressing issues and airing concerns. These meetings will either occur on an IRC server in a channel designated by the meeting chairperson, on the game server, or in a private EverQuest chatroom. IRC meetings should be set to +private to prevent unwanted eavesdroppers in the proceedings. Meeting announcements will be placed within the appropriate message area.

3.4.5 Insider information, which includes but is not limited to information disseminated and subjects discussed on the EverQuest Guide web site, CS Program e-mail, and in private CS Program meetings, is NOT to be relayed to the general player population. Disclosing this information to unauthorized parties can result in dismissal from the Program and permanent banning from EverQuest.

3.5 Customer Service Representatives Posting to Public Boards

3.5.1 As CS Representatives travel about outside the game, they can frequent news groups, bulletin boards, and other messaging media where players congregate and discuss the game. CS Representatives (with the exception of members of the Communication Team) are free to post to these boards as they wish with a few restrictions:

• They may not indicate they are CS Representatives
• They may not answer questions specific to CS policy
• They must adhere to the Policies and Procedures of the Guides when discussing in-game material

3.5.2 In short, CS Representatives do not speak of things out of game that they can not speak of in-game. CS Representatives maintain the mystery always.

3.5.3 Under the direction of the Communication Team and the Public Relations Guidelines the members of the Communication Team openly represent the Guide Program on web sites and bulletin boards during the course of their duties but always conduct themselves as Guides, even out of EverQuest.

3.5.4 In the event that a CS Representative encounters a poster that is specifically attacking the Guide Program or a specific CS Representative (even if they are the target), they should not post, but instead send an email to the Communications Team (eqcomm@verant.com) with a link to the post. The reason for this is that one of the roles of this Team is to be the voice of the program. How the program is represented to the public is of paramount importance so it is necessary that it speak with one voice and one consistent message.

3.5.5 Under no circumstances should a CS Representative “fight” with another player on a public board, nor should a group of CS Representatives “gang up” on a player simply because they all disagree with them. The Guide Program has no true authority outside of EverQuest, and at all times our goal is to present ourselves professionally and maturely.

3.5.6 Quests are coordinated by the Server Management Team and implemented by the Guides as scheduled. These Quests come from the Approved Quest Pool board, complete with histories, storylines, and background. Designated writers will disseminate some information outside the game. This is to ensure the correct information is made available, both in content and amount. Too much information can spoil the Quest, and incorrect information creates inconsistency between the servers. Consequently, CS Representatives are prohibited from posting information, stories, background, announcements, or anything else related to a Quest without first getting approval from the Communications and Quest Teams.

3.6 The Nightly Report

3.6.1 Guides and Apprentice Guides will post a nightly report covering highlights of their shift on their server discussion board. Highlights should include severe problems and problems affecting a large number of players. These reports should be very concise, containing brief summaries of only those events of the evening believed to cause the most impact to the game.

3.6.2 Every week a Senior Guide for each server will pull together the highest priority items from the reports and post these as the report for that server. Verant Interactive staff checks the weekly reports to quickly assess the current issues.

3.6.3 The first Guide or Apprentice Guide to file the report for the day creates a post with the date in the title.  Each subsequent addition by a Guide or Apprentice Guide for that day's activities is added as a response to that post, not a new post.  There should be a section of the report dedicated to that evening's incidents, including such things as Abuse and Exploitation (detailed below).  Each incident should contain all pertinent information to the incident, particularly the character and account names of the players involved.

The EverQuest Guide web site is located at http://guide.everquest.com.

4. Customer Service Personnel Policy and Practices

4.1 Customer Service Personnel Policy

4.1.1 The Customer Service staff maintains constant exposure to the EverQuest customer base and our actions are under constant scrutiny. We must exhibit the highest standards of behavior and avoid even the appearance of impropriety.

4.1.2 Reports on the performance of the customer service staff are expected to come from many sources, not all of which are reliable. It is to be expected that some unhappy customers will file reports concerning customer service people simply for not giving them what they want. Conversely, it is expected that some people who are not good candidates for the program will join the staff.

4.1.3 Any staff members who cannot follow the policies and procedures, or who are found to not be a “good fit” for the program will be released from the Customer Service program. It is much preferred that we keep our own house clean than allowing the customer to do this for us.

4.2 Customer Service Personnel Procedures

4.2.1 Members of the Customer Service staff deserve at least as much consideration as an average player when an incident report is filed against them. All such reports are handled privately involving only the reporting party and the Senior Staff member investigating the complaint. The following procedures are used to ensure a fair review.

4.2.2 A report of misconduct may occur in a public forum or as part of a private conversation with a customer. Reports may also be generated directly by Customer Support Representatives. These reports will not be posted to the message boards or disseminated to anyone other than the appropriate escalation point.

4.2.3 Whichever staff member receives the report should try to ensure that basic information is included. (Char name of the CS person involved, server, date and time, and incident details) This information should then be forwarded privately to the appropriate escalation point:.

• Complaints about a Guide or Apprentice should be taken to that Guide or Apprentice’s Senior, who will evaluate the issue with an Elder Guide.
• Complaints about a Senior Guide should be taken to an Elder Guide, who will then coordinate efforts with the Guide Liaison.
• Complaints about an Elder Guide should be taken directly to the Guide Liaison at mbutler@verant.com. The Guide Liaison will coordinate any action with the Customer Service Manager.
• Complaints about GM-Admins should be taken to a Senior on the server, who will then take it to an Elder Guide to coordinate with the Lead GM-Admin for that cluster.

4.2.4 The investigating staff member will look into the incident as thoroughly as possible, involving the subject of the report in their investigation. In the case of reports against Guides or Apprentices, the Senior Guide will then inform the Personnel Elder with the results of their investigation. The Personnel Elder will take whatever actions are appropriate, whether this involves counseling a Guide or removing them from the program.

4.2.5 In cases where the program releases a staff member, either the Senior or Elder will notify Verant Interactive, copying the investigating staff member. Verant Interactive will then have the character removed. After the character is removed, the investigating staff member will seek out the individual, and inform them of their removal from the program. It is imperative that the released staff member not be communicated with prior to the removal, as they represent a threat to the program. It is also important that they be communicated with as soon after their removal as possible, and as discretely as possible, to ensure a clean removal with as few hard feelings as possible. Verant will be notified of routine (e.g. resignations, MIA) personnel releases via the weekly Personnel Reports.

4.2.6 To reiterate, once Verant Interactive has removed the staff member, it is the responsibility of that staff member’s immediate superior (The Senior for dismissed Apprentices and Guides, the Elder for dismissed Seniors) to locate the person and communicate their change in status as quickly and professionally as possible to reduce the shock and potential hard feelings.

4.2.7 Appealing an Involuntary Release

4.2.7.1 Sometimes circumstances arise that require the removal of a guide from the program. Should it be felt that this removal is unjust and unwarranted, the following procedures should be followed to make an appeal:

An email with the subject of "Appeal of Involuntary Release - GuideName" should be emailed to the Elder Guide(s) and the Guide Liaison. This email should contain all of the following information:

• Your Guide Name
• Your Station Name
• A brief explanation of the event(s) which led to the removal. Only the facts should be concentrated on this should include dates (if possible) and names.
• An explanation why it is felt this is an unjust removal. (Phrases like "a guide friend told me" or "a senior friend told me" are unacceptable.)

4.2.7.2 An Elder and the Guide Liaison will check records (removal emails and guide database entries) and talk with the Server Management Team (Server GM-Admin and Senior Guides) about the appeal from the removed guide. They will also gather any further information about the events that led to the removal if possible.

4.2.7.3 An Elder and the Guide Liaison will reach a decision based on the facts presented and inform both the removed and server management teams of their decision.

5. Rules and Regulations

5.1 Information Dissemination

5.1.1 Questions regarding material available in the manual/.TXT file. The EverQuest Manual and EQNews.TXT file contain a great deal of information. CS Personnel should encourage people to read it by not answering questions that are answered in these documents. Should a significant number of questions be generated about something that is not in the documentation, effort should be made to have the files updated with the additional information.

5.1.2 Questions about game specific information. In their travels, CS Personnel learn a lot of details and gain insight about Norrath. They see spells and items that will only be accessible through the most difficult quests in the game. They see the bottoms of dungeons and the loot of monsters that may not be generally accessible yet in the game. And they tell NO ONE. This information is part of the mystery of the game. We do not divulge information of this nature to any player for any reason anywhere. If the customer wishes to know, they can go find out on their own. Divulging this information to anyone other than a Guide or Verant Interactive employee is a violation of policy and one of the more serious offenses a CS member can commit.

5.1.3 Questions regarding other CS representatives. CS representatives are not always on duty. When they are off duty, they should continue to play as much as possible on servers where they are not representing the program to ensure that they don’t lose contact with the player’s perspective of the game. At no time does any CS representative. reveal the identity of one of these player characters to anyone outside the program. Additionally, a CS representative will not identify his player character(s) on any message board in which he speaks in an official capacity. This protects the CS Representative in question from many things (accusations of favoritism, excessive /tells from people that know they are a CS representative, etc) as well as allows us to travel the zones with impunity to investigate exploit reports or evaluate potential CS Representative candidates. The primary reason for this regulation is to allow us some peace and quiet to enjoy the game when they are not on duty. (ref section 3.5 CS Representatives Posting to Public Boards)

5.2 Interacting In-Game

5.2.1 Intra-zone Communications and Question Handling. CS Representatives may use /shout and /ooc to address a zone when pertaining to official duties such as zone warnings for profanity, naming ceremonies, or as directed by your Server Management Team. Questions may be addressed via Answer Circles and /tell, but we do not answer questions in /shout or /ooc. The more populated zones are currently overrun with this chatter, and we will not contribute to it. Customer service representatives will set a precedent by not answering questions that are delivered in such a manner, asking the customer to use a more appropriate method for communicating with them.

5.2.2 In-game Character Services. We are not in Norrath to interfere with the economy in any way. That means we do not provide services that can be provided by other PC’s. These services include, but are not limited to: Binding, Curing, Healing, Enchanting, Tailoring, Smithing, or Scribing. Any service that can be provided by a PC should be, even if that PC is charging a fee for that service.

5.2.3 In-game Character Protection. No matter what degree of danger customers may find themselves in, the Customer Service representatives are not to intervene. We watch, but do not act. Should customers come to us for aid, we should immediately remove ourselves from the situation. This means "question and answer sessions" should be formed in safe areas such as around guards, not in public adventure zones.

5.2.3.1 This includes PvP combat in all its myriad forms. If a customer we are speaking with is suddenly attacked by another player, we must not intervene, no matter the situation. If the attacker is utilizing an exploit or abuse in the attack, then use the Exploitation or Abuse Incident procedures documented below. The best solution, for both the customer and the CS Rep, is to only do “question and answer sessions” in a guarded area.

5.2.4 Pseudo-Nepotism. Customer Service Representatives should, at all costs, avoid any interaction with Guildmates while on duty. This includes, but is not limited too:

• Taking /petitions from Guildmates
• Escalating issues to Guildmates that are also part of the Customer Service program.
• Referencing or speaking of the Guild or Guild references while on duty.
• Having the Guild advertise that a CS Rep is a member

5.2.4.1 Essentially, if a Customer Service Rep’s player character is a member of a Guild, they should have nothing to do with anyone anywhere, while they are on duty, that is also a member of that Guild, even if that person is also in the program. This prevents the perception that, because a guild has a CS Rep within it, members of that Guild gets preferential treatment.

5.2.5 No d3wDzP3aK (Doodspeak). As Guides, we communicate with our customers 100% via the written word. As such, it is very important that we deliver our responses in a professional and literate fashion. There is no quicker way to offend or “put off” a customer than communicating in a manner that sounds ignorant or overly informal. Few people will complain or notice if our communications are concise, clean, and professional, but MANY will notice should they be sloppy, erroneous, and illiterate. Consequently, Guides will not use the style of communication generally referred to as Doodspeak. This includes words such as:

• 'u' instead of you
• 'ur' instead of you're/your
• 'sup' as a greeting
• Etc.

5.2.5.1 Communicating in a “role playing” manner is acceptable, as long as it’s consistent with EverQuest’s genre, so “thee” and “thou” are allowed. However you choose to communicate, remember the primary goal is to communicate effectively. Once you’re doing that, the role playing can be added for colour.

5.3 Discretion and Professionalism

5.3.1 Set an example. Both to the customers and to the rest of the CS team, it is imperative that all CS personnel maintain an air of professionalism and integrity. Personally, out of character, and “off the clock”, they can behave how they wish as long as there is no connection between who they are and their Guide persona. But on duty, even in the /private channel, we speak of and to the customer with kind regard and consideration, even when telling them “No”.

5.3.2 Tempers. No matter how frustrating the situation, no matter how angry the customer, no matter how personal the insults, a Guide should never lose their temper. Should a Guide feel that they are losing their temper, they should escalate the call immediately to a member of the Server Management Team if possible or another Guide if a senior member is not available. This is not personal, and the Guides are here to help.

5.3.3 Ignoring customers. No matter how frustrating a customer can be, we never /ignore them. If a CS Rep is having a difficult time with a customer, they should escalate it to another team member, if possible. If no one else is available, the CS Rep must simply handle it as quickly and efficiently as possible, then disengage from the customer.

5.3.4 Guide and GM “friends.” The end goal of the Customer Service program is to have representatives spread across multiple servers to allow them to not have to play on the same servers as their friends. However, friends will go where they will, so the program must endeavor to avoid the stigma of favoritism.

5.3.4.1 CS Representatives do not take a /petition from a friend unless there is no one else to take it. If no other team members are available he CS Rep must take the /petition, doing only the minimum amount of work required to close the call, even if it means leaving the problem only partially fixed. Better to be accused of giving poor service to friends than better-than-normal service to them.

5.3.4.2 No CS Representative shall request 'favors' of a player, either for themselves or on behalf of another customer. In such cases where it is deemed that player assistance is needed, the GM or Senior Guide shall be the contacting person.

5.3.5 Controlling customer perception. No matter the intentions, no matter how pure the motives, no matter how well meaning the representative, the specter of favoritism can rear its ugly head if we are not diligent and consistent in our actions. All it takes is for the belief to be propagated to cause a problem, even if it is completely untrue. This must be avoided at all costs, as it not only damages the individual’s reputation and that of the program, but undermines EQ overall.

5.3.5.1 We do not stay in zones where our friends are playing – the further away the better. We do not associate with friends while we are on duty, even if the friend is aware of our role in the Customer Service program. Seeing a CS Rep in the same zone with the same characters consistently, especially if it the identity of the representative’s alternate character becomes known, is simply asking to be accused of favoritism.

5.3.5.2 Under no circumstances whatsoever should any CS Rep “help themselves”, such as answering a /petition put in by their player character or that character’s party or doing a CR on their player character or members of that character’s party.

5.3.6 Twinking. Customer Service Representatives have the ability to test and explore dungeons and zones at their leisure. We do not adventure and do not give things to other players, no matter the circumstances. This includes giving items to our player characters. We are observers, not participants.

5.4 On The Job

5.4.1 Off Duty = Off Duty. When we are off duty, we are not a Customer Service Rep, Guide or GM. Our player characters have no authority whatsoever, and are essentially another customer. Consequently a CS Rep in their player character should never approach a customer in an official capacity, nor should they ever imply they have more power or authority than that of a normal customer. Likewise, our player characters should not call on other CS Representatives for any special considerations—the rules apply to all characters and there will be no favoritism within the Program. This means off duty CS Representatives do not identify themselves, in any way, shape or form, as CS Representatives on their play server, particularly when requesting assistance via the petition system or direct tells to the CS staff on the server. Off duty = normal player.

5.4.1.1 CS Representatives that find their play characters embroiled in the middle of a questionable situation should extricate their selves from it as quickly and quietly as possible to avoid any potential issues arising from their presence. Representatives that allow their player characters to initiate questionable situations will find themselves subject to discipline, as the Customer Service staff is held to the highest standard of behavior, on or off duty.

5.4.2 Threats of banishment. Regular Customer Service staff cannot ban players, ever. When investigating a call, no matter how severe, the investigating representative should never insinuate, threaten, or otherwise imply that they have the power or ability to banish a player. The CS Rep is there to gather the necessary information and report it to according to the procedures. GM-Mgmt then makes the final decision.

5.4.2.1 A CS Rep threatening a player with banishment creates two problems. First, it implies a level of authority they do not possess, creating hostility in the customer base. Secondly, if the player is not banned, it reduces the credibility of the program overall as it gives the impression that we make threats that they either cannot or will not follow through with.

5.4.3 No Looting. During a CR, the player in question (or his designate) must come to the spot of his corpse (or as close as possible). Customer Service personnel do not go in, get things, and carry them out. If the customer wants their possessions, they can come get them. This is to prevent people going in to a place; getting killed by a bug, and having us carry their inventory out when they should not have been there in the first place. If the customer got in there once, they can get a CR party and do it again.

5.4.3.1 Under no circumstances do we loot the bodies of players for any reason. If the body is not lootable by the customer, then the customer needs to find a friend to loot it for them. CS Representatives also do not negotiate with other players to loot bodies. Retrieval of the customer’s possessions is solely the responsibility of the customer. Our only role is to ensure that the customer’s body is reachable by the customer via normal means.

5.4.4 Summoning characters. Summoning normal players (not GM’s or Guides) is only used in the following cases:

• To unstick stuck players
• To bring customers to their body in the event that they died due to a bug (the bug directly killed them, see below)
• To shuttle characters across a sea zone in the event that the boats are non-functional
• To move people back to their bind point, should an affinity reset occur for that person
• To remove a disruptive player from an area he refuses to leave; player will be placed in the nearest safe zone
• To prevent a player from running away while being warned for detrimental behavior

5.4.4.1 Summoning is not used in the following cases:

• To shuttle characters to their body because they did not bind closer
• To shuttle characters from place to place for “casual” reasons
• To shuttle characters to their body because they got into a situation that was over their head and recovering their body on their own is simply “too hard”
• To provide transportation for, during, or after Player and GM events

5.4.5 /Anonymous Guides Guides will remain visible at all times except when required to perform investigations requiring the use of /anon, or when directed to by their Senior. A visible Guide is someone the customers can ask questions of and expect an answer from if they can see one online. A Guide that is on a project (such as investigating an exploit report) or a developer that is working on a problem that does not wish to be disturbed should be /anonymous to avoid confusion and frustration to the customer. Apprentices may use /anonymous during the camping process in order to be anonymous when they login later. This is to alleviate being the target of a large number of /tells when they are checking for a full Guide upon logging in. Depending on if a full Guide is available, the apprentice will immediately become visible or log out.

5.4.6 /Toggle To prevent the reception of unsolicited /tells while anonymous, the CS Representative may use /toggle to turn incoming /tells off. Whenever a CS Representative is not anonymous, their incoming /tells will be on. This, and Quest Actors using /roleplay, are the only two circumstances in which this command can be used. (ref: 5.4.5 /Anonymous Guides)

5.4.7 No Hunting/Questing/Crafting/Shopping/Begging/etc. The Guide characters are provided to make sure we have the resources we need to do our jobs. They are not toys nor are they for play. Consequently, unless it is explicitly covered by another procedure in this document (i.e. verifying loot levels), Guides do not kill monsters in any other manner but /kill. They do not use spells, pets, weapons, skills, their hands, or in any other way interact with an NPC in any manner that produces a corpse or an item. In addition, /kill is only used in conjunction with "Stuck Monster" calls, and only as described in that procedure. Guides do not do NPC Quests, unless verifying that the quest is functioning, and again only done in accordance with the documented procedure. Guides do not fight players, no matter the circumstances, outside of scripted quests and may only fight other Guides inside the Arena of the Sunset Home.

5.4.7.1 Under no circumstances will a Guide accept any items given to them by a player. As well, a Guide will leave any loot found on the ground in place, except when verifying a reported bug/loot anomaly.

5.4.7.2 Guides do not have money, outside of the money given to them by the NPCs in the Guide Hall. Guides have no need to purchase anything apart from the Guide tools available from the Guide Hall NPCs. If a Guide feels they need a tool or resource they do not posses, then they should contact their Senior and ask for it. If it's already been approved for use in the program, the Senior will provide it. If it's not, and the Guide can convince the Senior it's required, the Senior can request it of the Elders.

5.4.7.3 The Elder(s) collect such requests and process them with Verant Interactive to prevent every Guide in the program from asking every GM they see for things they feel they need. This allows the Program to work most efficiently with Verant Interactive. Unless there are special circumstances involved, when the program requests things from Verant Interactive we batch these request and schedule them. Guides are NOT to approach GMs or other Verant Interactive employees to request names, items, levels, or anything else. These requests are handled uniformly across the Guide program, according to established practices.

Note: This does not include Exploring. Guides need to know their way around, the lay out of the zones, and in general where things are. With the exception of the Apprentice restriction to higher level zones (reference Section 1.3.3) and the customer-service limited zones (reference Section 5.6), Guides can and should go everywhere possible and be comfortable navigating any zone in the game.

5.4.8 /Broadcast As using the broadcast command can instigate increased server load, the one using it should weigh the benefits of using the command with the drawbacks. Non-urgent announcements should be made only when the server load is lower; not at prime time if at all possible. The one using the command should also refrain from using it excessively, and only use the command enough to communicate the necessary information.

Use of the /broadcast command will be restricted to the following:

• Issues of immediate concern for the majority of players online at the time (such as server maintenance).
• Positive changes in staffing on the Server Management Team level (Senior promotion, departure or arrival of a Senior or GM in good standing, promotions to the Server Management Team)
• The awarding of a Medal of Service 1 Year Announcements approved by Verant Management and above of unique accomplishments by players (such as recognition of the first player to obtain a fiery avenger)

5.5 Account Security

5.5.1 Account Sharing Per the EverQuest License Agreement, item one, which reads: “You may not transfer or share your Account with anyone, except that if you are a parent or guardian, you may permit one child to use the Account instead of you (in which case you may not use that Account),” CS Representatives will not share their account with anyone, to include other members of the EverQuest CS Program.

5.5.2 Passwords As all CS accounts are privileged, it is strongly recommended that you change your password periodically; at least every 90 days, and keeping the “strong” password model in mind when creating them. Do not share your password with ANYONE. Passwords are considered strong if they fit the following criteria:

• Minimum of 6 characters in length, 8 characters recommended
• Is alpha-numeric
• Contains at least 1 special character (e.g. @#$?%^&*)
• Varying case (if the system is case-sensitive)

5.5.3 Compromised Accounts. If for any reason you believe your CS account has been accessed by anyone other that yourself, do the following steps immediately:

• Change your password
• Notify one of your Senior Guides
• Send an email to the Verant Interactive Security Manager at ging@verant.com , CC:-ing your Server Management Team (yourservername@eqguide.org)and the Guide Liaison at mbutler@verant.com

5.6 Customer Service Limited Zones

Some zones in EQ have been designed with extreme rewards and risks. Because of design and tuning issues, Customer Service intervention in these zones is restricted.

5.6.1 List of Customer Service Limited Zones

The Plane of Fear (fearplane) 
The Plane of Hate (hateplane) 
The Plane of Sky (airplane) 
Veeshan’s Peak (veeshan)

5.6.2 Acceptable CSRep Presence in Customer Service Limited Zones The presence of Customer Service Representatives in Customer Service Limited Zones creates two undesired situations. First, players are more likely to ask for assistance in gameplay issues from the CS staff if a CS Rep is in the zone. Second, players are more likely to blame CS Representatives for any inconvenience they may experience if a CS Rep is in the zone. For these reasons mentioned above CS Reps must not be in Customer Service Limited Zones except under the following conditions:

• They are investigating a possible Exception Incident (Abuse, Disruption, or Exploitation) at the request of a player.
• They are investigating a possible bug at the request of a player for documentation purposes.
• They are removing a corpse from an object such as the ground, a wall, a tree, etc. according to Corpse Recovery Procedure (See 7.3 Corpse Recovery)
• They are unsticking a player stuck on the geometry (in an object, in a wall, etc). The player should be moved the minimum amount of distance necessary to unstick them from the geometry.
• They are summoning a corpse from a verified inaccessible area listed in 5.6.2.1 to a position of the player's choice within the zone.
• They are summoning a player from a verified inaccessible area listed in 5.6.2.1 in the Customer Service Limited Zone to a non-PvP area of Arena and then back to either the zone-in point of the Customer Service Limited Zone or to another player of the player’s choice in the Customer Service Limited Zone.
• They are following Policy and Procedures concerning an Under the World Case. (See 7.13)

5.6.2.1 Inaccessible Areas in Customer Service Limited Zones Currently the only verified inaccessible area in a CS Limited zone is caused through an anomaly that often occurs when a player has gone linkdead in the Plane of Hate. When this anomaly happens a player can become stuck in an inaccessible area of the second floor of the Plane of Hate. As mobs can also sometimes become stuck in the area, players can also die here. This area can be verified by using the /loc command. The z coordinate of this area is approximately 110.

5.6.2.1.1 Retrieving Players in Inaccessible Areas of Customer Service Limited Zones A player character in an inaccessible area of a Customer Service Limited Zone can inadvertently become added to the hate-lists of mobs in the zone. Therefore, to retrieve players from these areas without indirectly causing the deaths of players the following procedure should be followed:

• Confirm that the Player Character is in an inaccessible area of a Customer Service Limited Zone (see 5.6.2.1)
• Summon the player to the zone named Arena
• Summon the player to a player character of their choice in the zone in which they were stuck, to a Player zone-in point of the zone in which they were stuck, or to the Customer Service /zone-in point.

5.6.2.1.2 Corpse Recoveries in Inaccessible Areas of Customer Service Limited Zones If a player has a corpse stuck in the inaccessible area of a Customer Service Limited Zone, summon the corpse to a player of their choice who is in the zone or to any other location of their choice in the zone.

5.6.3 General Customer Service Limited Zone Policies

5.6.3.1 Exploring and Adventuring CSReps should not use their CS characters to explore Customer Service Limited Zones. If a CSRep is in one of these zones for a reason approved above (see 5.6.2), they should leave immediately after addressing the issue they are there for and should not stay in the zone any longer than necessary.

5.6.3.2 Reporting CS Actions Taken in Customer Service Limited Zones A GM+ should report any action they take in a Customer Service Limited Zone to their direct superior. Senior Guides should report any action they take in a Customer Service Limited Zone to the rest of the Server Management Team, including the GM of the server or the Lead GM of the server if the server is not currently assigned a GM, and include a detailed account of any Customer Service action taken in a Customer Service Limited Zone on their server in the server’s weekly server report. Any Full Guide or Apprentice Guide who takes Customer Service action in a Customer Service Limited Zone should report a detailed account of it in their Daily Status Report and/or in a designated section of their server board.

5.6.3.3 Resurrections in Customer Service Limited Zones CSReps are not to provide resurrections in Customer Service Limited Zones under any circumstances without specific authorization from a GM+ as directed by Verant Management.

5.6.3.4 /Kill Restraint in Customer Service Limited Zones The killing of any mob in Customer Service Limited Zones (see 5.6.1) is considered to cause a significant change in game play. Therefore CS Reps should not /kill in these zones without specific authorization from a GM+ as directed by Verant Management. (This Policy can also be found at 7.10.7.6)

6. General Customer Service

6.1 General Customer Service Policy

6.1.1 It is the policy of the Customer Service Program to answer every /petition that comes to in, regardless of whether the problem can be solved or not. Even an “I’m sorry, but we are unable to help you” is better than no response at all.

6.2 General Customer Service Procedures

6.2.1 Apprentices should be the first to answer any incoming call. This not only gives them the experience needed to be able to manage large call volumes, but it also allows other members of the team the time they need to handle escalations or special projects. If a Guide (Apprentice, Guide, or Senior) does not know the answer to a question, it behooves them to find out the answer to make sure they can answer the question if it arises again. Avoiding a question, simply because they do not know it, creates a “blind spot” in their knowledge base. In addition, it is the responsibility of the ones that do know the answers to provide those answers to those that do not know.

6.2.2 Time Limits – During peak times, or times of low staffing and moderate /petition load, it is recommended that a CS Rep not take longer than 2 minutes to answer any non-travel /petition. In other words, if the solution can be answered via /tell, then it should not take longer than 2 minutes to resolve.

6.2.2.1 The idea behind this is to prevent us from spending 30 minutes resolving a problem and pacifying a customer while the other representatives become overwhelmed with the load. No customer deserves more of our time than any other, and all customers deserve our attention when they need it. This is more a recommendation than a mandate, as not every problem can be resolved in 60 seconds. But it is imperative that we Guide spend as little time resolving the problem as possible to be available for the next call.

6.2.2.2 Obviously, during periods of low load, we are not under as much pressure, but it is best to maintain the same sense of discipline when handling calls regardless of the load.

7. General Incident Procedures

7.1 Account and Billing Problems

7.1.1 Players with problems regarding customer accounts and billing should be requested to use the website, http://www.station.sony.com to resolve their problem. Those unable to handle their problem through the web site can call 1-888-station.

7.2 Special Procedures

Note: A few types of problems are common enough that specific guidelines have been created for dealing with them.

7.2.1 Boat Zoning Anomalies

7.2.1.1 There is a special procedure for customers who have problems sailing on the ships in the game and find themselves swimming in the ocean due to technical reasons.

7.2.1.2 Whenever you receive a petition that a customer has had a boat related death or accident:

• /goto the customer
• Verify their location (if they are in the middle of the ocean, then the call is likely valid; if they are just off the shore of an island, then the call is likely not)
• If the customer died, perform a Corpse Retrieval as documented then continue with this procedure
• If the customer is alive, ask them their desired destination
• /zone to the destination zone and travel to the docks
• /summon the player to that location

7.2.1.3 This procedure is not used if:

• The player was fleeing a monster into the water and died, either drowned or killed
• The player was swimming from island to island and drowned
• The player was fleeing another player by jumping off the boat and drowned

7.2.2. Binding Death Loops

7.2.2.1 This section applies when a player finds themselves bound next to a stationary monster that is KOS (kill on sight) to them, so they repeatedly die, respawn, and die again with no way to escape or to solve the problem in-game. (The only way out of such a loop is to disconnect from EverQuest; the player will usually then log in as another character and ask for help.)

7.2.2.2 This is not a bug, and it’s a predicament that the players got themselves into, so a strict reading of the guidelines would forbid the Guide from intervening. However, since it makes the game completely unplayable for that character, and requires out-of-game manipulation to even try to arrange a rescue, we have made this an exception.

7.2.2.3 On receiving a petition about a binding death loop, you should /zone to the area where the deaths occurred and verify the situation. (A pile of corpses next to a stationary guard, for example.) Then find a spot in that zone or a neighboring zone that will be safe for the player. Set up a hotkey of /summon <playername>. Then ask the player to log out and log back in as the endangered character, while repeatedly pressing the hotkey. As soon as the player arrives, use the Binding Stone to bind them to this new location.

7.2.2.4 The corpses should be left alone; they will decay in a few minutes, since they are empty. The player will not be reimbursed for experience lost due to these deaths.

7.3 Corpse Recovery

7.3.1 When a customer calls indicating they have lost their corpse:

• Ask them where and how they died.
• Go to the zone where the corpse is located.
• Find the corpse (/find <playername>’s corpse#-- the "‘s" is required, and the # is replaced by a numeral, starting at 0, to differentiate between multiple corpses) and make note of the xx, yy, zz coordinates of the corpse.
• As long as the player did not die by falling into lava or through the bottom of the ground (if the latter is the case, the zz coordinate will be negative a large number), /goto the corpse and investigate it.

7.3.1.2 If the corpse is clearly visible (i.e. not embedded in a hillside or a tree) and accessible through normal travel (i.e. not under the ground, in the air, or hanging off of a cliff) then summoning the corpse should not be necessary. If not, then find the closest patch of land to the corpse and summon the corpse to it. Inform the customer that their corpse is now available for retrieval and end the call.

7.3.1.3 If the corpse is underwater, near a dangerous monster, or anywhere else accessible at risk to the customer, it is left there for the customer to attempt to retrieve. These are hazards of the game and the CS Program is not here to circumvent them.

7.3.1.4 All corpses in lava will be considered irretrievable, and upon /petition will be pulled to the nearest spot of dry land, regardless of other dangers in that area.

7.3.2 Verifiable Bug Deaths

Note: The only exception to the above procedure is if the cause of death was a directly due to a verifiable bug.

7.3.2.1 Some examples of causes of death that are considered verifiable bugs:

• Falling through the world for massive damage
• Flying through the air and falling for massive damage
• Player zoned into lava when entering Lavastorm (where the corpse will appear at the zone safe point)
• Drowning in a bugged patch of water that, once a character enters they are unable to leave and drowns again
• Being crushed by a ship
• Falling off the boat while zoning, being lost at sea, and drowning

7.3.2.2 Some examples of causes of death that are not considered verifiable bugs:

• Falling into lava after becoming linkdead
• Being knocked into lava by a monster
• Falling off a cliff
• Being killed by a monster
• Dying while under the influence of a monster’s spell, except where noted above (i.e. falling through the world)
• Dying while linkdead, except where noted above (i.e. falling through the world)

7.3.2.3 If the cause of death was a verifiable bug, then the corpse retrieval process is different.

• Ask them where and how they died.
• Go to the zone where the corpse is located.
• /summon <playername> to a safe spot in the zone, usually the zone entrance.
• /summon <playername>’s <corpse#> to that spot then use the cloak of Vashaar on the targeted corpse to resurrect the player, thus reversing the loss of experience points accrued due to the erroneous death.

7.3.3 This is a courtesy service provided by the Guide Program in an attempt to compensate for the loss of experience and inconvenience caused by the character dying to an anomaly in the game, which is not something they could have possibly avoided.

7.3.4 Link death is caused by client or network issues that will exist well after release and can not be compensated for by programming. Link death can never be proven and can actually be used by customers to purposely avoid dire consequences of their actions in the game. Consequently, dying while linkdead will never be considered death by a bug, unless it causes the player to crash off of a boat and die. This is covered under Boat Zoning Anomalies.

7.4 Loss of Items or Experience Due to a Verifiable Bug

7.4.1 Reimbursals will be handled in the game by Verant Interactive’s GM staff. When there is a petition for a reimbursal due to a bug death, the Guide should record the following information about the customer:

• Character name
• Station name
• Station ID#
• Server Name
• Player’s email address
• Full description of the incident leading up to the loss of the possessions
• General list of the possessions lost

7.4.2 This information should be placed on your Server Board at http://guide.everquest.com with a copy emailed to the Server Team at their option. If this is the first reimbursal report for the day, it is posted as a reply to the day’s first status report with the subject “Reimbursal: <Station Name>” where <Station Name> is the account name of the player in question. Each successive reimbursal report should be posted as a reply to the first one, with the same subject format.

7.4.3 The Verant Interactive GMs assigned to the server will check the web site frequently to pick up these requests. They will then review the customer’s accounts, inventory and bank accounts to determine if reimbursal is warranted. If so, the GM will contact the customer and arrange to reimburse their items. We are attempting to have people reimbursed within 48 hours of petitioning. This delay is necessary for the GMs to verify the customer’s account.

7.5 Minor Bug Reporting

7.5.1 Players will report minor (non-emergency) bugs through the use of /petition. The proper response to these types of petitions, as documented above, is to gather as much information as possible and log the call as a bug.

7.5.2 CS staff should include zone of any location dependent bug or NPC having a problem. Faction problems should be reported with complete information on the player’s race, class and religion, along with the name and location of the NPC involved and the text of the NPCs speech.

7.6 Major Bug Reporting

7.6.1 If the bug is of a disruptive, or imbalancing nature, further action may be required. Examples of such bugs:

• Loot given in an area of the world is excessive to the extreme – A CS Rep should move to the area as quickly as possible to verify the bug. If the bug is indeed correct, the representative should attempt to minimize the exposure by killing or removing the NPCs involved, warning other players away, and attempting to immediately escalate the problem to a Verant Interactive GM for further resolution. If no GM is available, the Guide should attempt to find a Senior, Elder, or a GM in the chat server to notify them of the problem. Email Verant Interactive Customer Service (currently eqcs@verant.com). Until Verant Interactive fixes the exploit, a representative should remain in the area of its occurrence until their shift is over, notifying the rest of the staff when they are leaving so that another team member may come and take up the post. This ensures that a minimum of damage is done from the bug.
• Buggy NPC pathing causing an NPC to run into a wall (corner) and not respond normally to attack or player presence – The problem should be logged into the bug database with /loc, /zone, NPC name and the circumstances that led to the pathing problem. The first course of action to use on the NPC is the Guide’s “Wand of Memory”, which will cause the NPC to forget why they are doing what they are doing and return to their static location or patrol. If this does not work, then the next course of action is to kill the NPC to allow it to respawn in its normal spawn point. In either case, ensure all information has been gathered prior to any action being taken.
• A specific area is generating more than average calls, such as a gate in Neriak or a hallway in Befallen – A member of the staff should be dispatched to be near that area and camp there to assist players that are inconvenienced by this as quickly as possible. The issue should be included in detail in the nightly status report. As with the excessive loot problem above, we should make sure that the area is guarded on each shift.

7.6.1.2 Major bugs such as the above require direct intervention to prevent them from becoming disastrous ones. This does not necessarily require a dedicated CS Rep in all cases, but the longer we are present on the scene, the faster the response time that can be provided in the event of a customer issue.

7.7 Quest/Event Administration

7.7.1 Quests are defined as any in-character occurrence involving characters played by Guides or GMs. This can be as simple as an invasion or as complex as a murder mystery. Some quests have rewards for the player(s) who successfully complete them, but a reward is not mandatory.

7.7.2 Events are defined as any occurrence initiated or controlled by players. Auctions, treasure hunts, weddings, and music concerts are all examples of player events.

7.7.3 The Backstage message board on the Guide web site is for discussion of quest ideas and policy, and generally anything relating to quests. Quest-specific announcements will appear on that board.

7.7.4 Creation of a Quest

7.7.4.1 Any CS Representative may submit a quest idea for review through the EverQuest Guide web site. Submitted ideas go into a queue of unapproved quest ideas where they wait to be reviewed and revised by the quest team (composed of Guides, Senior Guides, and Verant GM members) who ensure that it meets the following criteria:

• Well thought-out and defined - no loose ends or unexplained plot elements
• Complete - all information needed to run the quest is specified, including detailed actor information, specific places, and complete sequence of events
• Consistent or non-conflicting with the existing history of Norrath
• Appropriate challenge and reward for the intended player audience
• Appearance of historical NPCs of Norrath, significant NPCs (dragons for example), gods or explanations of known landmarks (dragon skeleton of Steamfont for example) are restricted for use in historical quests, they may not be used in non-historical quests. Non-historical quests may not require changes in a zone or ownership of a zone (dark elves take over Freeport for example).
• Quests should not be identical or extremely similar to other quests that are or have been in the approved quest queue.

7.7.4.2 Each quest is classified into seven categories based on its intended frequency:

• Class A Quests of this type may only be run once per week. The same quest may not be repeated for one month.
• Class B Quests of this type may be run once per week. The same quest may not be repeated for at least two weeks.
• Class C No more than two of these quests may be run in a week. The same quest may not be repeated for at least one week.
• Class D Quests of this type may be run once per day. The same quest may not be repeated for at least three days.
• Class E Quests of this type may be run once per day. The same quest may be repeated after one day. Template types may be run in different zones within the same day.
• Class X Quests of this type may only be performed as often as stated within the quest.
• Class H This category is for Historical Quests. Unless otherwise specified in the quest's description, these quests may only be run once.

7.7.5 Quest Scheduling

7.7.5.1 Once a quest has been approved by the Quest Team, it appears in the Approved Quest Pool on the Guide web site. Each Server Management Team (comprising Senior Guides and GM-Admins) is cooperatively responsible for scheduling quests on their server.

7.7.5.2 Class A, B, and C quests must be scheduled at least two days in advance using the tool on the Guide web site. The Server Management Team should arrange resources such as character buffing and item creation in advance, preferably on a fixed schedule.

7.7.5.3 Class D and E quests do not need to be scheduled in advance. Class D and E quests may be performed at any time when the petition queue is deemed low enough at the discretion of the server’s management team and when there are enough Guides online to cover the queue while the quest occurs. Senior Guides and GMs who wish to run a class D or E quest should consult with all other Senior Guides and GMs who are online at the time and make the decision. Members of the Server Management Team may coordinate resources such as character buffing and item creation for quest classes D and E as necessary.

7.7.5.4 Some quests will be identified by the quest team as “Historic,” (H) indicating quests that are part of a larger plot in the evolving history of Norrath. Historic quests must be run once and only once on each server (unless otherwise specified in the quest’s description) and will often have deadlines. If the server’s management team is unable to meet the deadline for a historic quest, they should contact the Quest or SWAT Teams or their Lead GM to arrange for substitutes to perform the quest on their server.

7.7.5.5 CS Representatives participating in class A, B, and C quests must do so during times they are not scheduled to be on-duty. CS Representatives may participate in class D and E quests during their scheduled duty hours at the discretion of their Server Management Team. Apprentice Guides may not participate in quests.

7.7.6 Quest Performance

7.7.6.1 Dynamic quests should be executed as closely to their written specification as possible. Do not add characters, spawn extra monsters, change zones, or otherwise change the quest from its definition. If a quest is inadequate as written for whatever reason, provide feedback to the quest team on the Backstage message board.

7.7.6.2 Actor characters should be created, buffed, and equipped in advance of the quest, according to a schedule defined by the server’s management team. When creating an actor character, the race and class should be carefully chosen based on that character’s role. If the character will not be casting spells but will be using weapons, choose a troll warrior for its regeneration and weapon skills. If the character will not be casting spells and will not have any weapons (animals, werewolves, etc.), choose a human monk for its unarmed combat ability. If the character is a spellcaster, choose the most resilient race possible. The actual race chosen has no bearing on the appearance of the character after it is transformed into its quest role. Characters in historical quests will generally not require character creation (any exceptions will be noted in the quest document). These characters are created by Verant GMs and copied to the account of the guide who will play them.

7.7.6.3 Care should be taken not to use CS Representative privileges such as /goto and /summon unless specifically required by the quest’s definition or unless it is done in such a way that the “realness” of the quest is not compromised. At the beginning of a quest all quest actors should use the /tog off command to block tells from players. Communication for the quest may be done via the /pr channel or by creation of a temporary guild to which the quest actors are invited. No quest actor shall speak out of character or respond to /ooc communications.

7.7.6.4 Once a quest has been completed, actors must delete the quest character from their account. Actor characters are for use only in the dynamic quest for which they were created. Using a buffed actor character for any other purpose is grounds for dismissal from the Guide Program.

7.7.7 Persistent Characters

7.7.7.1 Occasionally in the course of advancing a plot or furthering a storyline within Norrath, the quest team will define a persistent character. A persistent character is a Guide or GM actor character who, instead of appearing for the short duration of a quest and then vanishing, stays in-character for extended periods of time to interact with players. Guides or GMs playing persistent characters are encouraged to log in the persistent character whenever they have a chance and interact with the player citizens of Norrath. It is important that persistent characters remain strictly in-character. Out of character comments or questions from players should either be ignored or deflected in character. /tell should not be used.

7.7.7.2 Each persistent character will have a predefined history - a description of things that character knows and can therefore share with players. Some persistent characters will also be authorized to grant class E quests to players as they see fit - these will be defined in the history document as well.

7.7.7.3 Playing a persistent character does not count toward the 10 hour Guiding requirement at this time.

7.7.8 Events

7.7.8.1 CS Representatives may not supply any powers, money, or items to player-run events. They may participate with their presence and words at their Server Management Team’s discretion.

7.7.9 PvP Quests

7.7.9.1 Players with PvP status will often petition asking to have the PvP flag removed. This can be done via a PvP quest. These quests are given out by a GM or Guide playing the role of the Priest(ess) of Order, rather than by a static NPC. They are customized for the class and level of the player. Each server should set a time and place where the Priest(ess) of Order may be contacted; players who petition about the quest should be given this information.

7.7.10 Quest Disclosure

7.7.10.1 Under no circumstance may the details of a dynamic quest be disclosed without the tacit approval of the Communications and Quest Teams. CS Representatives found using quest information to their or their friends personal advantage can result in dismissal from the Program and banning from EverQuest.

7.8 Questions about Becoming a Guide

7.8.1 Players who show an interest in becoming a Guide should be referred to the http://www.everquest.com site under the topic “GM Guide FAQ.” This page has information about the program and a link to an online questionnaire.

7.8.2 Players who have previously applied but have gained enough knowledge and experience that they wish to reapply, and players who started to apply but accidentally submitted the application before it was complete, may reapply using their station name followed by an X (i.e. if original application was johnsmith, they would reapply as johnsmithX).

7.8.3 For a candidate to be seriously considered there are a number of things that must be true:

• *They must be 18 years of age or older. The Guides will be required to sign a legally binding contract to provide accountability for their actions within the game, as poor judgment or abuse can result in monetary loss to Verant Interactive.*
• They must not appear on the abuse report more than once for a confirmed exception of any type.
• They must not work for a competitor of Verant Interactive in the MMORPG (Massively Multiplayer Online Role Playing Game) market.
• They must not run or staff a spoiler site, an exploit site, or any site that supports the dissemination of information that is in violation of these policies.

7.8.4 Questions pertaining to the status of applications that have been submitted may be directed to appadmin@verant.com

7.9 Questions about Game Mechanics

7.9.1 Customer Service staff should not generally answer questions that are also answered in the EverQuest manual. These questions should be handled politely and the first one or two may be answered generally, after which the customer should be referred to the EverQuest manual. Players may ask questions about game mechanics in order to determine if they have encountered a bug. For example, a player may ask the intended effect of a spell because they are not seeing any result from casting it. Rather than telling the player specifics on the effects of the spell, it is better to ask a key question or two and determine whether the spell is working correctly. If it is, inform the player of that. If it is not, then the customer service representative should follow normal problem reporting procedures.

7.10 Stuck NPCs

7.10.1 During the course of play, players periodically run into NPCs that are "stuck". Stuck is defined as:

• Running in place
• Hung on geometry (stuck in a gate, behind a barrel, immobile but trying to

move)

• Someplace they should not be (a Hill Giant inside the entrance to Befallen, unable to get further in or out)

7.10.2 When a stuck NPC call comes in, the investigating Guide has a very clear process to follow. Apprentice Guides are not to attempt to free a stuck NPC.

7.10.3 Stuck NPC Procedure

• Use the Wand of Memory on the NPC - This will clear its memory, or "hate list" and hopefully cause it to go about its normal route.
• If that does not work, use /kill on it. This will remove the monster, without leaving a corpse, and allow it to respawn again.

7.10.4 Alternate method (only for the bravest of Guides). Sometimes, attacking a monster will cause it to turn and dislodge itself. This is effective on NPCs that are crucial to quests or other functions and should not be /killed if it can be avoided. The process for this requires a delicate touch and good timing. Attack the monster ONCE with the Guidestaff, then back away QUICKLY. If the NPC follows, QUICKLY use the Wand of Memory on it. The monster, now dislodged from its location will return to its normal route.

NOTE: UNDER NO CIRCUMSTANCES should this be used when there is a danger of training the NPC onto a player. Rather than risk the lives of the players’ characters, the Guide should either /zone away or allow the NPC to kill them.

7.10.5 Guides will not attempt to unstick NPCs residing on any of the planes unless instructed to do so by a GM-Admin+.

7.10.6 No matter which resolution is used, the incident must be reported as a bug. Add any additional information to the petition, especially the correct name of the NPC and the location of the incident, then Log it as a Bug in the queuing tool.

7.10.7 /Kill Restraint

7.10.7.1 As it is one of the most powerful commands of CS Representatives, CS Reps should not use /kill on mobs that will cause a significant change in game play.

7.10.7.2 Mobs of higher levels often have long spawn times. Therefore CSReps should not /kill mobs that are level 50 and above. The CS Rep may /con a mob to determine its level. The killing of mobs in the planes, and the killing of dragons is strictly forbidden unless the CS Rep has been specifically authorized to do so by a Verant Employee (GM+).

7.10.7.3 Some mobs such as Brother Zephyl and Hasten Bootstrutter are on 'spawn-tables'. When one mob is killed, the other has a chance of spawning. As spawn-tables are intended game mechanics, CS Reps should not /kill NPCs on such spawn tables if one of the spawns is involved in a quest. As no CS Rep can be expected to know all of the spawn tables, it is a good idea for them to check with their fellow CS Reps who are online before killing a non-merchant NPC. Stuck merchants can almost always be safely killed without seriously altering the natural game-mechanics of players.

7.10.7.4 As Verant GMs have access to tools that allow them to address the game-mechanics issues caused by the /killing of rare, high level, and quest NPC mobs, and they are ultimately responsible for maintaining the server, they may /kill such mobs when they have determined it to be necessary. Other CS Reps may also /kill such mobs when acting on the explicit and specific instructions of a Verant GM.

7.10.7.5 A CS Rep may /kill mobs as necessary to allow players to obtain their corpses if a Senior Guide or Verant GM has determined that the zone in which the mob is located has crashed. Verant Management may also authorize the /kill-ing of mobs such as Lord Nagafen when it has been determined that the zone crashed as the direct result of the actions of players.

7.10.7.6 /Kill Restraint in Customer Service Limited Zones The killing of any mob in Customer Service Limited Zones (see 5.6.1) is considered to cause a significant change in game play. Therefore CS Reps should not /kill in these zones without specific authorization from a GM+ as directed by Verant Management. (This Policy can also be found at 5.6.4)

7.11 Questions about Game Secrets

7.11.1 Customer Service Representatives must never answer questions that give away the game’s secrets. These include, but are not limited to, questions about quests, armor, spells, weapons, and locations of objects or NPCs.

7.12 Technical Problems

7.12.1 Technical problems may include problems staying connected, problems with incorrect graphics, game response time or performance, and sound problems. Technical problems originate in one or more of the following places: The EverQuest servers or network, the EverQuest client, the player’s own PC, or the network connection between the player and EverQuest.

7.12.2 The online customer service staff is not required to handle support for technical problems, but may do so at their discretion. Technical problems not handled by the online staff should be referred to the technical support staff.

7.12.3 Known Problems:

7.12.3.1 All customer service personnel should check the GM discussion board daily and read the highlight reports to find out the current “hot problem” list. Players submitting known problems should be informed that the problem is already known, but the customer service staff should submit a problem report if they have additional information needed to solve the problem.

7.12.4 Determining the source of unknown problems: Determining the circumstances when the problem occurs and the circumstances when the problem does NOT occur can pinpoint the source of a technical problem.

7.12.4.1 Examples: If the problem occurs for more than a few players, the player’s own PC is not likely to be the problem, assuming they have met the basic requirements to run the game.

7.12.4.2 The four known exceptions to this are:

• If the player does not have at least 300M free space on their swap drive (usually C: )
• If the player has a number of files in C:\windows\temp or C:\Temp
• If the player does not have the most recent video drivers or version of DirectX from the EverQuest web page. Often these are not the same drivers as listed by the manufacturer.
• The player has 32 meg of RAM, P-233 or slower computer and/or an older graphics card.

7.12.4.3 If the problem occurs in one zone and not another, then factors such as the player’s PC configuration, and network connection can generally be ruled out.

7.12.4.4 If a problem occurs under a player’s new PC configuration, but not under the old one, and no other players are having the problem, it is likely to be a configuration or hardware problem with that player’s PC. Assuming the player’s PC meets the minimum requirements, then request that the player submit a /bug on the problem. Players experiencing problems with new hardware or software configurations can also be encouraged to check established message boards to find other players with matching system configurations. These can then be compared to provide the player with information on how to customize his system to run EverQuest successfully.

7.12.4.5 Many players misdiagnose all system response problems as lag. Many players assume that lag is the fault of Verant Interactive’s network. If a response time problem occurs for a player, or a small number of players, chances are good that it is not a Verant Interactive-performance problem with either the servers or the network. (A server or network problem would affect all the players, or all players in one zone or on one server.)

7.12.5 Undetermined technical problems: If a technical problem is not resolved by the customer service staff, the player should be asked to obtain technical support by emailing eqtech@verant.com or by calling Technical Support at (858) 537-0898.

7.13 Under the World

Through an anomaly players and corpses can sometimes become stuck Under the World.

7.13.1 Verification of Under the World Something can be confirmed to be below the world by targeting it with /find and then using the /goto command. Please note that often when something is under the world it will appear to be on the surface at the ‘safe coordinates’ of the zone. It is confirmed that something is under the world if:

• the CS Rep receives a message that they are Under the World and/or that they are being teleported to safe coordinates when they attempt to use /goto on the player/corpse

OR

• when they use /goto successfully they see sky below them.

7.13.2 General Procedure for Player Characters Under the World

• Confirm that the Player Character is Under the World (see 7.13.1)
• Summon the Player Character to the /zone-in coordinates of the zone.

7.13.3 Procedure for Player Characters Under the World in Dangerous Areas A player character under the world can inadvertently become added to the hate-lists of mobs in the zone. In dangerous areas such as a Customer Service Limited Zones, Dungeons, or areas where the mobs are relatively high level compared to the player following the General Procedure for Player Characters Under the World can result in mob trains. Therefore, to retrieve players from these areas without indirectly causing the deaths of players the following procedure should be followed:

• Confirm that the Player Character is Under the World (see 7.13.1)
• Summon the player to the zone named Arena
• Summon the player to a player character of their choice in the zone in which they were stuck, to a Player zone-in point of the zone in which they were stuck, or to the Customer Service /zone-in point.

7.13.4 Under the World Corpse Recoveries If a player has a corpse stuck under the world, summon the corpse to a player of their choice who is in the zone or to any other location of their choice in the zone.

8. Exception Incident Procedures

8.1 Abuse

8.1.1 Abuse is defined as any activity that is exercised with the intent of disrupting the over all play environment of one or more players.

8.1.1.1 Things that are Abuse:

• Hate Mongering – participation in or propagation of Hate literature, behavior, or propaganda related to real –world characteristics.
• Sexual Abuse or Harassment – untoward and unwelcome advances of a graphic and sexual nature. This includes virtual rape, overt sexual overtures, and stalking of a sexual nature.
• Attempting to Defraud a CS Representative - Petitioning with untrue information with the intention of receiving benefits as a result. This includes reporting bug deaths, experience or item loss, or accusing other players of wrongdoing without basis for it.
• Impersonating a Customer Service Representative – falsely representing yourself to another player as a Guide or a Verant Interactive employee.
• CS Personnel Abuse - sending excessive /tells to a CS Representative, excessively using say or other channels to communicate to a CS Representative, making physical threats, or using abusive language against a CS Representative.
• Using Threats of Retribution by GM Friends – attempting to convince another player that they have no recourse in a disagreement because favoritism is shown to one of the parties by the Verant Interactive or Guide staff.
• Fraud - falsely representing one’s intentions to make a gain at another’s expense
• Ninja-looting - when a player, disregarding the players or player who killed a mob, loots an item that is generally regarded as significant or valuable from the mob they did not kill.

8.1.1.2 Things that are not Abuse:

• Contextual Swearing – players that swear in character, or use racial terms that are appropriate to the genre.
• Contextual Racism – behaving poorly or with hostility towards other characters of a race that is hated by the character’s race generally.

8.1.2 Abuse Procedures

8.1.2.1 Abuse is one of those “soft” issues that are the hardest to identify and punish. What two players call fun, two others will call abuse. The key to enforcing the abuse policies in EverQuest is consistency. The goal of EverQuest is to create a world where as many people as possible can come and enjoy an immersive role-playing experience.

8.1.2.2 When a player is accused of abuse, the process is as follows:

• Gather all of the information on ALL parties involved. Get the character name, race, level, and account name of both the accusers and the accused, as well as the zone and situation and document it.
• Locate the situation and go there, invisible and /anon, being sure not to tell the petitioner you are coming.
• Attempt to ascertain the nature of the problem without interacting with either party

8.1.2.3 If the situation is visible and questionable:

• Do not intervene.
• Contact the accuser, explain that the accused is behaving within acceptable limits of the genre and if the accuser does not like it, they should use the /ignore function or leave the area.
• The call is closed.

8.1.2.4 If the situation is visible and obviously abuse:

• Escalate to a member of the Server Management Team immediately if possible.
• If a member of the Server Management Team is not available, attempt to have a fellow Guide present as quickly as possible.
• Engage the accused, explain that their behavior is abusive, and that they have been escalated for review. Tell the accused to stop the behavior, then disengage from the incident.
• Do NOT argue or debate the incident with the accused. Do not discuss the incident past what is required to explain the nature of the abuse to them.

8.1.2.5 Take note of everything said by the accused and add it to the documentation. File a report in the abuse database and in the customer's soulmark (using the /warn command) for review by Senior Customer Service staff.

8.1.2.6 If this is the first incident for the accused, they will be suspended from the EverQuest servers for one week. If this is the second or later incident, the player will be banned from EverQuest.

Note: See Banning under Exploitation for further information

8.1.3 The /report command

8.1.3.1 Often abuse goes on through /tell, or only when a GM/Guide isn’t there to listen. Players who report such abuse should be told to use the /report command the next time it occurs. This command captures the last ten lines of visible text from the player’s text window, sending it to a file on the server. These files can only be accessed by Verant Interactive staff, so they can be used as evidence (unlike screenshots, which are easily forged).

8.1.3.2 Customers should be informed that if they are the subject of harassing language, to use the /report command to send the last ten visible lines of chat text to Verant, and given the format of the command. They should also /petition after they /report, to alert the CS staff.

8.1.4 Reports of Fraud

Fraud in all transactions between players will result in disciplinary action when confirmed by a Verant GM. Examples of this activity include, but are not limited to, offering to recover possessions from the corpse of another player and refusing to return that property to its owner, as well as using flaws in a secure trade window to deprive someone of one of their items. When petitions reporting fraud are received, they are to be escalated to a GM for resolution.

8.1.5 Reports of Ninja-Looting

If confirmed by a Verant GM, ninja-looting will result in disciplinary action up to and including player suspension or banning. Ninja-Looting is when a player, disregarding the players or player who killed a mob, loots an item that is generally regarded as significant or valuable from the mob they did not kill.

When a CS Rep receives a petition reporting ninja-looting, they are to contact the petitioner, gather preliminary information, and escalate to a GM for resolution. Determination of whether or not an item is ‘generally regarded as significant or valuable’ is left to the GM’s discretion as directed by Verant Management.

8.2 Disruption

8.2.1 Disruption is defined as any activity that is disruptive to the game play of others, though not necessarily with the intent to do so. Disruption has been sub-categorized into major and minor types.

8.2.1.1 Examples of Minor Disruption:

• Non-Fantasy Names – Names that are not appropriate for the fantasy genre of EverQuest
• Excessive Spam – Continued overuse of /ooc, /shout, or /auction over time such that many players complain
• Offensive Names – Names that are profanity in some form, including homonyms and anagrams
• Kill Stealing – The killing of a mob for any reason that is already aggravated onto another player.

8.2.1.2 Examples of Major Disruption

• Foul Language – excessive use of foul language in an inappropriate context, including swear words, real–world racial slurs, and other language that is not consistent with the fantasy environment and designed to hurt.
• Harassment – targeting another player, or group of players, to harm or inconvenience them
• Zone/Area Disruption – monopolizing most or all of the kills in an area rather than stealing from a specific player or group of players, deliberately blocking a doorway or narrow area so other players can’t get past, refusing to cooperate with the other parties at a contested spawn site after having been instructed to do so by a CS Representative

8.2.2 Disruption Procedures

8.2.2.1 Disruption is the most difficult problem to deal with, as the accused are frequently not doing it with the intention of disrupting, but simply having fun or behaving as they wish. The key to dealing with Disruption situations is to defuse them with as little customer aggravation as possible.

8.2.2.2 When a Disruption call comes in, the process is as follows:

• Identify the complainer and the suspected antagonist. Document their character name, level, zone, and account name.
• Go to the zone in question, remaining invisible and anonymous, being sure not to tell the petitioner you are coming.
• Bring a fellow Guide if possible, preferably invisible and /anon.
• Observe the behavior in question and that of those complaining.
• If there is no problem with the behavior as you and your fellow Guide see it, then explain this to the complainer and close the call.

8.2.2.3 If it is not possible to distinguish which behavior is worse, the accuser or the accused, engage both groups.

8.2.2.4 If it appears that the accused is being intentionally disruptive,

• Gather information.
• Engage the accused, explain that their behavior is disruptive, and issue a warning. Tell the accused to stop the behavior, then disengage from the incident.
• Do NOT argue or debate the incident with the accused. Do not discuss the incident past what is required to explain the nature of the disruption to them.
• Take note of everything said by the accused and add it to the documentation.
• Record the incident in the abuse database and in the customer's soulmark (using the /warn command) for further review by Senior Customer Service staff.

8.2.2.5 If the accused is obviously being disruptive, but not necessarily intentionally,

• Engage the accused.
• Attempt to convince the accused to cease the activity, explaining that it is disruptive.

8.2.2.6 If the customer becomes confrontational, treat the issue as if it were intentional, described above.

8.2.2.7 For minor disruptions, three warnings will be issued. The perpetrator will then be suspended for a minimum period of three days. For major disruptions, two warnings will be issued, followed by suspension for a discretionary period with a one-week minimum. The next major disruption offense following suspension for major disruption will result in the player being banned.

8.2.3 Contested Spawn Complaints

When a complaint is received indicating that a spawn or kill is contested, a disruption investigation should first be initiated according to the procedures of section 8.2.2 to determine if harassment or Zone/Area disruption is occurring. After following those procedures and issuing warnings as necessary, instruct the parties involved in the contested spawn situation to work out a compromise. Then leave the scene.

If another complaint is received involving the same spawn site, another disruption investigation should be initiated. After following those procedures and issuing warnings as necessary, if any of the parties involved were involved in the initial situation, establish a compromise for the parties to which the parties are required to abide. The compromise should be as described in section 8.2.3.1. Any party refusing to abide by the compromise established by the CS Representative should be issued a warning for disruption.

On PvP servers, where players can reach a solution to the contested spawn situation, the CS Representative does not need to require the players to share the spawn.

8.2.3.1 The compromise will require all parties to take turns killing the spawn(s). All parties involved in the contested spawn should be instructed to use /random 0 100 to choose a number. The CS Representative then uses /random 0 100. The individual with the closest number to the CS Representative’s number will be next in the rotation. The CS Representative then bases the rest of the rotation order on how close the other parties’ numbers were to theirs. The compromise established by a CS Representative must be objective and not require the CS Representative to choose one customer over another based on subjective criteria. The CS Representative is the arbiter in any disputes in establishing the compromise.

8.2.4 Kill Stealing

When a kill stealing scenario involves a single spawn, or only a few specific spawns, the procedures in section 8.2.3 (Contested Spawn Complaints) should be followed. However, should kill stealing as defined in section 8.2.1.1 be witnessed during the execution of that procedure, the CS Representative should issue a warning for disruption.

When investigating other reports of kill stealing, the CS Representative should be anonymous and hidden. If the CS Representative observes one player steal a kill as defined in section 8.2.1.1, the CS Representative should issue a warning. The CS Representative should use their best judgment in determining whether a kill was stolen or if more than one player/group simply engaged the mob at roughly the same time. As it is a minor disruption, if the CS Representative believes the customer did not intend to disrupt, they may refrain from issuing a warning. The CS Representative’s decisions in these cases are final.

8.3 The EverQuest Name Policy

8.3.1 Character names in EverQuest should reflect the genre of the game. Original, high-fantasy names are desired. These guidelines apply both to first names and to surnames, and also to the combination of first name and surname. (For example, Luke and Skywalker are acceptable names, but Luke Skywalker is not.)

8.3.2 The following types of names are unacceptable and are listed in order from the worst to the least offensive:

• Vile, profane, rude, or racist names including common swear words, anatomical references, racial slurs, and homonyms of these words.
• Combinations of words that produce an offensive result (e.g. Hugeaz, TugMcgroin).
• Names of religious, occult, or significant historic origin (e.g. Jesus, Allah, Satan, Stalin).
• Copyrighted or trademarked names of products, characters, services, or concepts (e.g. Drizzt, Marlboro, Sony).
• Non-fantasy names from popular media (e.g. Rambo, Darthvader).
• Common words and phrases that would not be found in the place and time setting of the game (e.g. Switchblade, Phaser, Toaster, Cannabis, Sloegin).
• Proper names from EverQuest (e.g. Rathe, Karana). This also includes any name of a significant EverQuest NPC (e.g. Dorn, Trumpy, Karn).
• The names of senior Customer Support Representatives or employees of Verant Interactive, 989Studios, or Sony Entertainment (e.g. Ifurita, Solist, Rhystan)
• Names chosen with the intent or possessed with the effect of harming the reputation of a player or Customer Service Representative.
• Names containing titles within them, such as, but not limited to: The, Lord, Lady, Master, King, Knight, Sir, Father (e.g. Sirtallon, Lordeagle, Mothermaggy).
• Names that contain sentences, phrases, or more than two words. (Ikillorcs, Ontop, and Petcarbob, Diediedie) Descriptive compound words are allowed, especially in surnames (e.g. Treehugger, Giantslayer)
• Popular and easily recognized names from existing media (e.g. Merlin, Gandalf, Belgerath, Tanis).

8.3.3 For all of the above, misspellings and alternative spellings of the word or words are also unacceptable.

8.3.4 In the event of improper names, the CS representative should collect the character’s name and account name and escalate the call to a Senior or Elder Guide or GM.

8.3.4.1 The member of the Server Management Team will then use the following process:

• For category 1-2 offenses, the name will be changed immediately. The Senior Staff person will then contact the customer and discuss the change.
• For categories 3-10, the Senior staff member will contact the customer and initiate a discussion about the name change. When the customer has chosen a new name and looted any outstanding corpses, the CS representative will perform the name change using the “b” parameter to load the old name into the name filter.
• In addition to the bullet above, Category 8 names will be changed as soon as possible after discussing the situation with the customer if the Customer Support Representative is universally flagged. Otherwise, non-universally flagged Customer Support Representatives will select a new name upon transferring if their current name is not available. The Guide Liaison and Elder(s) will be notified via email whenever a Customer Service Representative's name is changed.
• If the name is a category 12 name, or the call doesn’t fit into one of these categories but is the subject of a petition, the Senior staff person handling the call will poll the current CS staff online to assist with obtaining a judgment. If the name is decided to be illegal, then the same procedures are followed as for categories 3-11.

8.3.4.2 If a senior staff member is not available for a category 1-2 name change, or if the player is not cooperating with the name change process after a member of the Server Management team has notified them, the CS Rep should follow the established procedure for handling exception incidents, and log the incident to the abuse database.

8.4 Name and Surname Changes

8.4.1 Players often petition to have their name or surname changed, or to ask for a surname that the /surname command won’t allow. A first name will only be changed if it violates the Naming Policy. A Surname can be changed by any Senior Guide or higher, under the following guidelines:

Surnames are protected by a Grandfather Clause: If a surname currently exists with spaces, double capitals, or accents, but does not violate the naming policy rules, they will remain unchanged.

Conditions under which surnames are modified:

• The player is level 20+ and…
• Either the surname, or the combination of the first name and surname violate the Naming Policy
• Is getting married or divorced
• Is entering or leaving a guild or family that shares a common surname.
• Doesn’t have a surname yet, or wishes their current surname to contain double capitals (e.g. McGregor, GaFennix, XacLevir)
• Doesn’t have a surname yet, or wishes their current surname to contain an accent ( ` ) (e.g. Ka`Trevx, Doli`k, Jan`frik)
• Doesn’t have a surname yet and the surname they are trying to give themselves is not being granted even though it does not violate the Naming Policy.
• Surnames will not be modified for any other reason.

Surname Guidance:

• Surnames may not contain spaces
• Surnames may contain double capitals provided one of the divisions of the name is not a word, it does not create a title or a sentence, or breaks up a real word.
• Surnames may contain an accent ( ` ) provided one of the divisions of the name is not a word, it does not create a title or a sentence, or breaks up a real word. Do not use apostrophes ( ‘ ) in names as they can cause a corruption of a character. This accent is the only non-alpha character that is allowed in surnames.
• Any number of players may have the same surname. Players wishing to use a surname that’s rejected by the name filter as already in use do not need to seek out the original user of that surname to obtain permission.

Note: Non-words like--D, Da, De, Di, El, Z, Za, Ze, Zi, L, Le, La, Li are unacceptable in cases where the name contains a normal word, as they are referrences to "The" and implicate a title, in both cases (e.g. D`Kval is acceptable where D`Basher is not).

8.5 Exploitation

8.5.1 Exploitation is defined as abusing weaknesses in the game system to the advantage of one or more players with the intention of profiting from them in some manner.

8.5.2 Examples of Exploitation:

• Duping – creation of money or items from nothing.
• Farming – using broken spells or spell effects to kill monsters, thus gaining experience from them.
• Safe Zones – using areas of bad data in the game that have monsters behaving erratically (such as running in place, running around, standing still, or any other behavior that has the monster not defending itself) to kill said monsters with minimal danger to the attacker.
• Price Gouging – finding items that have anomalous pricing and abusing them, such as items that sell for more than they cost to buy.
• PvP Switch Avoidance – Using in-game methods to work around the PvP switch and allowing non-PvP players to kill other players, such as hall blocking, dumping of monsters, or spell effects that cross that boundary due to a bug.

8.5.3 Things that are not Exploitation:

• Twinking – giving money or items from one character to another is not an exploitation, unless the money is derived from one of the above activities. This activity will exist and is not controllable by any reasonable means. (Twinking in beta is not allowed and should be handled as an exploitation)
• Camping – sitting in one spot to await the spawn of a monster or item.
• Slumming – hanging around in lower level areas and killing monsters there.
• Vulching – “stealing” kills from other players

8.5.4 Warning Procedures for Exploitation

8.5.4.1 When a player is accused of exploitation, the process is as follows:

• Locate the player.
• Make note of the player’s account name, the character name, level, and the zone of the character and the accuser.
• Inform any member of the Server Management Team that may be online at the time of the report.
• Travel to the zone (if possible) while /anon and invisible and attempt to determine the nature of the exploit. Do not contact the accusing player before investigating, as the news that an investigation is underway might find its way back to the exploiter.
• Study the activity, make note of the other players involved, and make sure that the accusation appears sound (i.e. they are doing what they are accused of doing)
• If this is the first incident with this customer, explain that they are exploiting, and ask them to stop. Do not defend your position, do not argue, and do not attempt to reform them. State the accusation and tell them that the incident has been recorded. Warn them of the consequences of a second offense. No further interaction is required past this point. Record the incident by filing a report in the abuse database, and use the /warn command to add a warning to the customer's soulmark. Verant Interactive Customer Service Management will review these records.
• If the CS rep is aware that this is the second incident with this customer, they should remain invisible and anonymous and not engage the customer in conversation. Follow all the above steps to gather as much information as possible. If a member of the Server Management Team is online, call them to verify the incident. When a second incident has been verified, the senior staff member will speak to the offender, informing them that a second incident of exploitation has been recorded. The senior staff member who handled the call will document all the gathered information and record the incident into the abuse database.
• If the CS representative is aware that this is the third incident with this customer, they will remain invisible and anonymous and will not engage the customer in conversation. Follow all the above steps to gather as much information as possible. If a member of the Server Management Team is online, call them to verify the incident. In these cases, the senior staff member will also remain invisible and anonymous and will not engage the customer in conversation. The senior staff member who handled the call will document all the gathered information and log an incident into the abuse database. These incidents will be reviewed by the Verant Interactive escalation review board, which will meet on a regular basis for this purpose. If the incident passes review, a player will be banned as a result of the third incident. Results of third incidents will be posted by Customer Service Management and appear in the daily report on the GM board.

8.5.4.2 The key to determining whether a person is exploiting is not in the activity, but in the intent. A player that is using a rain spell to kill masses of monsters may not know it’s an exploit, but instead believe that this is simply the function of the spell. It is the responsibility of the Guide to educate the player and ensure that the intention to exploit is present.

8.6 Banning

8.6.1 Once an account has been deleted/suspended, GM-Mgmt notifies the GM group that this particular account was banned/suspended. The GM-Admin collects the names of all of the characters played by the account that has been banned/suspend and will at least weekly publish this list in the MOTD for his server.

8.6.2 This serves two purposes. First, it lets everyone that has ever played with any one of the characters know the disposition of the character. Second, it creates a larger list, making a larger example, and offering a greater intimidation factor to those that might consider exploiting. This list should also appear as a cumulative “Banned to Date” list that is available via the News button. Again, this is to provide a tangible reminder of Verant Interactive’s dedication to providing an enjoyable environment.

8.6.3 The official customer service response to the banning of players is one of regret, as we regret any actions resulting in loss of customers. It is unfortunate that actions like these must occur to keep EverQuest enjoyable for the majority of the players. Details of official actions taken against a player are between Customer Service and that player and will not be discussed with anyone but that player.

8.7 Loot Anomalies

8.7.1 NPCs in EverQuest are supposed to possess loot appropriate to their level. The word is appropriate because there is no documented list of what level NPC should have what loot. However, it should be consistent with all other monsters of that level, within reason.

8.7.2 Examples of Loot Level Anomalies:

• Low level monsters with items as loot that sell for large amounts of money.
• NPCs with loot far in excess of peer-level monsters

8.7.3 Loot Anomaly Procedures

8.7.3.1 When a call comes in about a potential NPC Loot Level Anomaly, the process is as follows:

• A full Guide or higher must be immediately dispatched to the zone in question.
• The Guide finds and kills two of the monsters conventionally to determine if the loot level is incorrect as reported, then deletes any loot found.
• If the anomaly does in fact exist, the Guide immediately escalates the issue to a member of the Server Management Team.
• If no member of the Server Management Team is present, the Guide logs off of the server and checks the chat room. If a Senior, Elder or GM is present there, the escalation is handed off.
• If no Senior, Elder, or GM is present in chat, the Guide exits EQ and sends an email or ICQ to their Server Management Team to apprise them of the situation.
• After escalating the issue, the Guide returns to the zone and announces it off-limits to all players in the zone, /shouting that all players should leave it immediately.

Note: Any players caught killing the NPC after the announcement should be treated as Exploiters (documented above).

• If available, the Guide can summon an Apprentice to "baby-sit" the zone while the Guide handles other escalations (corpse retrievals, etc.).
• Each successive shift of Guides is notified by the prior one and the zone or NPC is "baby-sat" until Verant Interactive can resolve the issue.

8.8 The Chat Room

8.8.1 In addition to the game itself, EverQuest offers a set of chat rooms. CS Representatives who are present in these rooms who are Guides or Senior Guides have their names flagged in blue, while Verant Interactive staff members are flagged in red. Since the name color is highly visible, anyone with a colored name is “on duty” any time they are present in a chat room, and should conduct themselves accordingly.

8.8.2 A number of commands are available to deal with players who become disruptive in chat rooms. A full list of chat commands is available by typing #help in the chat room. These commands are not available to Apprentice Guides. Here are the commands that are most important to know:

/<name> <message>	Send a private message to the player with the specified name. Note: this works across channels. You can also click a name in the list at the right of the window and then type a message to send the message privately.
#shutup <name>	Stops a player from speaking in chat for 3 minutes or until logging out and back in again. The player receives a message informing him or her of this. Use this if a player is spamming or using offensive language.
#unshutup <name>	Turns off the “shutup” command for a player without waiting for 3 minutes to pass.
#lookup <name>	Gives the station name and station ID for a player in chat. Use this to get the player info for the abuse report if you issue a warning for disruption.
#kick <name>	Disconnects player from the Chat server
#lock <name>	Kicks a player off the chat server and locks them out for one hour. Note that this will prevent the player from logging into EverQuest at all. Use this command as a last resort and only after several warnings to the player.
#moderate on	Puts the channel into moderated mode, so only GM’s, Guides, and specifically chosen players can talk. Use this only in emergencies.
#moderate off	Returns the channel to normal, unmoderated mode
#talkon <name>	Allows a player to talk in a moderated channel
#talkoff <name>	Stops a player from talking again in a moderated channel
#talk	Lists all players currently allowed to talk in a moderated channel.

9. Behavior Guidelines

9.1 Professionalism

The Customer Service staff is expected to behave professionally at all times. This does not mean “stiffly and formally”, but consistently, ethically, and with integrity. Being that we are in Norrath to enhance the game, there is a code of conduct that all Guides and GM’s must follow whenever dealing with customers in any capacity.

9.1.1 Courteous. The Customer Service staff is polite, always. No matter how angry the customer, no matter how bad the complaint, no matter how personal the insult, we are always polite.

9.1.2 Empathetic. We care, always. Even when we can not help, or when the customer is abusive, the CS Rep always remembers what it was like to be in the customer’s position and understands how they feel.

9.1.3 Patient. Things go wrong, often. Things do not work out or fall apart, and take customers with them. No matter how wild the chaos, the Customer Service personnel are a rock that the customers depend upon in the storm.

9.1.4 Decisive. When a critical problem occurs that requires immediate action, that action must be rational, logical, and consistent with the program policies. A CS Rep being able to keep their head, contacting the proper escalation points, and executing consistent damage control can keep a minor emergency from becoming a disaster.

9.1.5 Humble. We are not above the customers. We support them, and they are the reason the program exists. The hierarchy of Guides is a measurement of the trust earned from other Guides and Verant Interactive, not necessarily an indicator of experience, knowledge, or ability. The Senior Guides are there because they excel at the requirements listed here, not because they have been in the program the longest.

9.1.6 Consistent. The actions of any individual representative directly impact the expectations on all of the others. Anyone who steps outside of the policy, no matter how "necessary" the violation, immediately causes other customers to ask why that exception was not granted to them in their own time of need. Policies exist for a reason, no matter how unfair they sometimes seem.

9.1.7 Committed. We are committed to the success of EverQuest. This is above personal gain within the game, making friends, and ego. Our commitment to our mission statement drives this.

9.1.8 Honest. The Guide program is where it is by earning the trust of Verant Interactive and its customers. Any betrayal of that trust hurts the other Guides, the customers, Verant Interactive, and EverQuest. Any short-term gain from being dishonest is FAR overshadowed by the long-term damage.

9.1.9 Creative. This is a roleplaying game. As such, most of the fun is mental and spontaneous. The more creative a CS Rep is, the more fun everyone can have with each encounter and situation.

9.1.10 Tolerant. People do not come to us happy. They only call when something has gone wrong, and they are often angry. It is not personal. We smile, listen, and fix it to the best of their ability, no matter how they are treated by the customer. A Customer Service representative should not carry any negative feelings about a customer encounter—into the next customer encounter. The CS staff on a server should develop a level of teamwork that will allow the team members to support each other, avoiding passing on our frustration to the customers.

9.2 Program Escalations

9.2.1 Links of the same chain Whenever a CS Representative has an issue with Verant Interactive, the Guide Program, EverQuest Customer Service, or any of their composite teams, divisions, or members, the CS Rep should address the issue using this escalation chain:

• The CS Representative should first contact their Server Management Team for them to address the issue. If unsatisfied with the response or lack thereof from the Server Management Team the CS Rep may then take the issue to the next step in the escalation chain after informing their Server Management Team that they are doing so.
• If the issue is not covered by one of the Teams the CS Representative may take the issue to the next step in the Escalation chain after notifying their Server Management Team. If CS Representative has contacted the team and is unsatisfied with their response or lack thereof, the CS Representative may take the issue to the next step after notifying the Team which covers the issue as well as their Server Management Team.
• If the issue is an one of Policy the CS Representative may contact the Policy and Procedures Team via policies@verant.com
• If the issue is a Dynamic Quest issue the CS Representative may contact the Quest Team via quests@verant.com
• If the issue is a Personnel or Training issue the CS Representative may contact the Personnel and Training Team via personnel@verant.com
• If the issue is a Communications matter, the CS Representative may contact the eqcomm@verant.com
• If the previous two steps have been exhausted, the CS Representative may take the issue to the Elder(s) and Guide Liaison via eqcs@verant.com after informing their Server Team.

9.2.2 Customer Service Morale Protection Maintaining positive attitudes in a cooperative organization such as the EverQuest Customer Service Program is vital to its success. Therefore, all CS Representatives should refrain from intentionally and unintentionally damaging the morale of anyone in the EverQuest Customer Service Program. To ensure that this does not happen, the escalation chain defined in section 9.2.1 should be used to handle issues and problems that address Verant Interactive, the Guide Program, EverQuest Customer Service, or any of their composite teams, divisions, or members.

9.2.3 Issues that can damage the Program’s morale in any way should never be posted to the message boards or expressed in any forum outside of the escalation chain established in section 9.2.1. Anyone who such damages the morale of the EverQuest Customer Service Program shall be subject to disciplinary action up to and including dismissal from the Program.

Appendix A – Vacations and Leaves of Absence

Absences

Members of the Guide Program should show up for their scheduled shifts.

Apprentices should at least make an attempt to Guide 5 days a week and should do their best to put in 10 hours or more on their server. An Apprentice that has not put in at least 10 hours in a two week period is considered to be MIA and should be put on Leave Of Absence if they do not put in at least 2 hours on server in the next 3 days. An Apprentice that remains on Leave Of Absence for 14 days will be removed from the Program and will need to contact personnel@verant.com to re-join the Program.

Guides should schedule themselves to work on their server for 10 hours a week. Should a Guide need to miss a scheduled shift, the Guide needs to post a message to their Server Board stating the reason for the absence. The Guide is expected to make-up for the lost time as soon as possible. If a Guide misses a week of shifts without posting the reason for the absences, they will be put on Leave Of Absence and then removed from the program within six days of being placed on the Leave of Absence.

Any period of absence from the Program will be tracked in the member’s database record and the weekly server report.

MIA (Missing In Action)

Candidates who do not respond to their Invitation E-mail within 14 days of it being sent, should be removed from the Program.

An Apprentice that does not attempt to Guide for 6 days is considered to be MIA and will be removed from the Program 6 days after their last shift on their server.

A Guide that misses a week of shifts without posting the reason for the absences is MIA and should be immediately placed on Leave Of Absence and then removed from the program within six days.

LOA (Leave Of Absence)

Prior to approving a Leave of Absence, the approver must have a return date that is within one month. When a Leave Of Absence is taken, the Guide Program Member temporarily loses Guide Board access and their GM Flag. Guides, Seniors, and Elders retain their free account status. Leave of Absences are granted at the discretion of the authorities that are authorized to grant them Leave.

Apprentices and Guides are granted Leave by their Server Management Team.

Seniors are granted Leave by the Elder(s) and the Guide Liaison.

Elders are granted Leave by Aikbach, Thom Terrazas.

An Apprentice should not be placed on Leave for any longer than 14 days. An Apprentice that is on Leave for more than 14 days should be removed from the Program. After having been so removed the Apprentice should contact personnel@verant.com to re-join the Program.

If any member of the program does not return within 5 days of their expected return date, they will then be removed from the program.

Vacation

When a Vacation is taken, the Program Member retains Guide Board access, their GM Flag, their GM Character(s), and their free account status. Vacations are granted at the discretion of the authorities that are authorized to grant them a Vacation.

Apprentices may not be granted Vacation time.

Guides are granted Vacation time by their Server Management Team.

Seniors are granted Vacation time by the Elder(s) and the Guide Liaison.

Elders are granted Vacation time by Aikbach, Thom Terrazas.

Because the Guide Program member retains access to confidential information and their Guide powers, as a security precaution Vacation time is limited in duration and quantity.

Guides may not take any more Vacation time than 14 days in a 3 month period.

Seniors and Elders may not take any more Vacation time than 14 days in a 3 month period.

If granted by the Elder and Guide Liaison, a Guide may exceed 14 days Vacation time in a 3 month period. However, this will rarely happen even in extreme circumstances.

If granted by Aikbach, Thom Terrazas, a Senior or Elder may exceed 14 days Vacation time in a 3 month period. However, this will rarely happen even in extreme circumstances.

All vacations/leaves will be tracked with a beginning and end date annotated in the member's record in the Guide Database by the approval authority. Weekly server reports will also contain the name and expected return dates of anyone on vacation/leave.

Emergency Leave

For instances of hardware failures or medical emergencies, a member of the CS Program may elect to enter Emergency Leave status. During Emergency Leave, the member will retain full access as if on vacation for a period of 7 days. If the situation exceeds this time frame, the member will be placed in LOA status by his approval authority.

Emergency Leave will not count against normal vacations allotted, nor will it be used in lieu of a normal vacation.

As with any other absence from the program, Emergency Leave will be tracked via the member's record in the Guide Database and in the weekly server report.

Appendix B – Recognition Programs

1. Server Management Team Programs

1.1 Server Reward Initiative

For actions above and beyond what is asked of them, the Server Management Team may bestow an in-game reward upon the deserving Guide+ member of their staff. These rewards are the only circumstance in which a Customer Support Representative may carry anything outside of the tools and items purchased from the Guide Vendors.

1.1.1 Eligibility

All Customer Support Representatives assigned to that server who are Guide+ are eligible to receive a Server Management Team in-game reward. Any Guide+ member of the EverQuest Customer Support Program may nominate a candidate for receipt of a reward. The nomination must be accompanied by a citation of the deed or actions witnessed that merit the reward.

1.1.2 Nominations

On-Server: If you are assigned to the same server as the candidate, your nomination should go directly to the Server Management Team. The nomination will include a citation of the event you witnessed to include date, approximate time, and a summary of the event.

Off-Server: If you are assigned to a different server than the candidate (e.g. You’re on your play character), you may nominate a candidate anonymously through your own Server Management Team. Once passed to your own Team, they will forward it to the candidate’s Team after stripping any mention of your identity. Again, the nomination will include a summary of the event you witnessed to add merit to the reward.

Examples:

On-Server: “I would like to nominate Guide Galn for a Server Management Team reward. On Sunday, January 2nd, 2000, Guide Galn single-handedly performed 142 resurrections following a server crash during an off hour. Guide Galn was not scheduled to perform this shift, and as a matter of fact had been on his play server when the servers crashed. It is this kind of dedication that reflects well on the Program.”

Off-Server: “I would like to nominate Guide Galn for a Server Management Team reward. I witnessed him perform an answer-circle to 40 players in which he recanted Norrathian history, in prose, to entertain the mass. As a player, I can appreciate the time it took him to prepare such an intriguing lesson. It is this kind of event that enriches the world in which we thrive, and serves to soften the ill-begotten image that Customer Service is a group of nay-saying automatons.

1.1.3 Determining the Reward

Upon receiving a nomination, the Server Management Team will review the event cited and determine a reward that is suitable to match the deed. It is imperative that all members of the Team agree upon the reward. Items will be specifically made for this purpose. A list of items will be provided in a category form to choose from.

1.1.4 Bestowing the Reward

Once the reward is determined, the Server Management Team is responsible for seeing that it is given in a manner that reflects the honor the candidate has earned. A small recognition ceremony in front of the candidate’s peers will usually suffice. The event should be cited, the award justified, and the reward given at this ceremony by the Server Management Team.

1.1.5 Tracking

Once the ceremony is complete, the Server Management Team will be responsible for updating the candidate’s soulmark to reflect that he has been given this reward. As well, the Team may wish to update the candidate’s database notes with mention of the reward as well.

Appendix C - Zone Listing

This is a list of all of the zones in the game by zone name to facilitate /zone and /goto.

TOWNS

Ak'Anon		akanon
Cabilis	East Cabilis	cabeast (Kunark)
	West Cabilis	cabwest (Kunark)
Erudin	Erudin Docks	erudnext
	Erudin Palace	erudnint
Felwithe	North Felwithe	felwithea
	South Felwithe	felwitheb
Freeport	East Freeport	freporte
	West Freeport	freportw
	North Freeport	freportn
Grobb		grobb
Halas		halas
Kaladim	North Kaladim	kaladima
	South Kaladim	kaladimb
Neriak	Foreign Quarter	neriaka
	Neriak Commons	neriakb
	Neriak 3rd Gate	neriakc
Oggok		oggok
Paineel		paineel
Rivervale		rivervale
Surefall Glade		qrg
Qeynos	North Qeynos	qeynos2
	South Qeynos	qeynos
	Qeynos Catacombs	qcat

WORLD ZONES

Burning Wood	burningwood (Kunark)
Butcherblock Mtn	butcher
City of Mist	citymist (Kunark)
Dagnor's Cauldron	cauldron
Dreadlands	dreadlands (Kunark)
East Commons	ecommons
EastKarana	eastkarana
Emerald Jungle	emeraldjungle (Kunark)
Erud's Crossing	erudsxing
Everfrost	everfrost
Feerrott	feerrott
Field of Bone	fieldofbone (Kunark)
Firiona Vie	firiona (Kunark)
Frontier Mountains	frontiermtns (Kunark)
Greater Faydark	gfaydark
High Hold Keep	highkeep
High Pass	highpass
Innothule	innothule
KerraRidge	kerraridge
King Xorbb’s Maze	beholder
Kithicor Forest	kithicor
Lake of Ill Omen	lakeofillomen (Kunark)
LakeRatheTear	lakerathe
Lavastorm	lavastorm
Lesser Faydark	lfaydark
Misty Thicket	misty
Nektulos	nektulos
NorthKarana	northkarana
North Ro	nro
Oasis of Marr	oasis
Ocean of Tears	oot
The Overthere	overthere (Kunark)
Qeynos Hills	qeytoqrg
RatheMountains	rathemtn
Skyfire Mountains	skyfire (Kunark)
SouthKarana	southkarana
South Ro	sro
Steamfont	steamfont
Swamp of No Hope	swampofnohope (Kunark)
Temple of Solusek Ro	soltemple (Optional)
Timorous Deep	timorous (Kunark)
Toxxullia Forest	tox
Trakanon’s Teeth	trakanon (Kunark)
Warslik’s Wood	warslikswood (Kunark)
West Commons	commons
WestKarana	qey2hh1

DUNGEONS

Arena		arena
Befallen		befallen
Blackburrow		blackburrow
Cazic-Thule		cazicthule
Chardok		chardok (Kunark)
Crushbone		crushbone
Dalnir		dalnir (Kunark)
Droga		droga (Kunark)
Guk	Guktop	guktop
	Gukbottom	gukbottom
Howling Stones		charasis (Kunark)
Kaesora		kaesora (Kunark)
Karnor’s Castle		karnor (Kunark)
Kedge Keep		kedge
Kurn’s Tower		kurn (Kunark)
Mistmoore		mistmoore
Najena		najena
Nurga		nurga (Kunark)
Old Sebilis		sebilis (Kunark)
Plane of Air		airplane
Plane of Fear		fearplane
Plane of Hate		hateplane
PermafrostCaverns		permafrost
Runnyeye		runnyeye
Solusek	Solusek’s Eye	soldunga
	Lord Nagafen’s Lair	soldungb
SplitPaw		paw
Unrest		unrest
Veeshan’s Peak		veeshan (Kunark)

Appendix D - Changes to this Document

This is a working document and will change to meet the needs of the program. Requests for changes to this document may be sent to policies@verant.com. Normal, non-emergency change requests will be batched and handled as time allows, while change requests flagged as urgent will be processed as they arrive. Requests for all other changes will be discussed among the senior guides, and representatives of Verant Interactive Studios. If the change is approved, the document will be modified and a new copy sent to all customer service personnel.