NA server still with issues

Ayewen

Same problem here. Has there been any word that they are even aware of this problem?

zept0sec

Ayewen wrote: »

Same problem here. Has there been any word that they are even aware of this problem?

Nope. And if they follow protocol, there should be a message up top shortly saying login issues have been resolved. :P

Ayewen

Finally able to login after half an hour of trying... I guess I just needed to vent it on the forums.

Pendrillion

Also no connection and error 200

Iskrasfemme

...

UrQuan

After the server went boom earlier this morning I was able to log in later, but now once again I can't. I'll bet this is like the last time when they thought they fixed the issue but didn't actually fix it, and then everyone went home and stopped paying attention to all the people reporting that they still couldn't log in.

If ZOS had a professional automated CS ticket system that met industry standards, they wouldn't find themselves in situations like this where they don't even know that there are still problems. All it takes is algorithms monitoring for unusual spikes in tickets submitted in order to generate an alert for technical support staff to check out urgently.

Weeks ago because of failures in their CS ticket system I sent ZOS the following to explain how a professional CS ticket system works:

For the record, here's how a professional automated CS ticket system is set up:

• Provide multiple channels to submit a ticket (I think this part is probably fine, as you can submit a ticket in-game, or via the website and you’re unlikely to need other channels – I’m unsure of whether it’s possible to submit a ticket if you’re having login issues for both the game and the website, and if not there should be a channel that allows this).
• The channels to submit a ticket should have categories/sub-categories that are as clear as possible (so there should never be any confusion regarding which category/sub-category a person should select), while also being as specific as possible, with the understanding that there will always be tickets that do not fall into any of the categories/sub-categories and provisions to allow for users to submit tickets classified as “other” (it typically makes most sense to include a sub-category for “other” under each category, as this usually allows for better data collection/analysis without encouraging users to just select “other” as a main category without considering the specific categories and sub-categories first –analysis of the tickets submitted under “other” should occur in an iterative process to refine the categories and sub-categories available over time).
• All categories/sub-categories should have fields available where users can input data relevant to the nature of tickets in that category/sub-category (care must be taken when deciding which fields should be mandatory input and which fields should be optional input, as well as whether there’s any validation on the form for the format of what was entered), as well as a free format text field. The fields meant for specific pieces of data should be designed with an eye towards what data is relevant for a CS specialist dealing with the ticket (especially data that can delay resolution of a problem if it is not included in a ticket), as well as with consideration for what type of data would be useful for analysis and aggregation purposes.
• Create algorithms for monitoring all ticket submissions. The algorithms should, at a minimum, watch for unusual spikes in overall ticket submission, unusual spikes in tickets of any given category/sub-category, and unusually high ticket submission from any given user. The alerts generated by these algorithms should vary depending on what type of unusual activity is detected – in some cases it should simply be a flag for a CS specialist or supervisor to investigate, and in other cases it should generate an emergency alert for the 24/7 support teams to investigate server issues. It is vitally important that these algorithms run continually in real time so that emergency alerts can be generated in a timely manner. This is an ideal area for machine learning to be implemented, but of course that’s optional and for a CS ticket system the effort/cost involved may outweigh the benefits unless regular ticket volumes are very high. If desired, ticket submissions may also be monitored for the type of user submitting the ticket. This would allow for certain users to get ticket priority, and would typically only be desirable if different service standards for ticket resolution times were desired for different classes of users (the only potential example that comes to mind here is if there was a desire to ensure that ESO+ members get priority, but there may be other ways of classifying priority users that are relevant).
• Create algorithms for scanning the contents of tickets for key pieces of data and keywords. This is to be used to generate automatic responses that are likely to provide answers/resolution for the majority of common issues reported in tickets. This is also an ideal area for machine learning to be implemented in order to continually improve the usefulness of the automatic responses generated. In this area machine learning is almost guaranteed to be worth the effort/cost involved, as in the long run it will significantly reduce the number of tickets that require human intervention of some sort. Ideally these algorithms should run continually in real time so that automated responses can be generated quickly (this reduces the overall time to resolve tickets for cases in which the user must reply and have a response from a CS specialist, which provides a better customer experience), but having some down time for this process is acceptable. Tickets for which the algorithms cannot find a suitable automated response should be placed into a queue immediately.
• Allow users to update tickets by giving them the option of either replying to the initial automated response, or of going through one or more of the regular ticket submission channels and viewing their recent tickets. The automated responses should include a link to the channel through which users can update their tickets (the link would take them to a page that requires account login) if they prefer not to update via email. Tickets can be set to be locked down after a certain period of time, or after a CS specialist has manually locked them down, and to not allow further user updates after that lockdown event (this ensures that users don’t necro old tickets when a new ticket would be more appropriate, and consideration needs to be given to what rules are appropriate for locking down a ticket).
• Tickets requiring intervention by a CS specialist (this would typically be defined as tickets that have been flagged for intervention by the algorithms monitoring ticket submissions, or tickets for which the content scanning algorithms were unable to find an appropriate automated response, or tickets for which an automated response was generated but which have been updated by the user subsequent to the automated response to indicate that the automated response did not resolve the issue) should be placed in queues based on the categories/sub-categories (and potentially into priority queues if certain user classes are intended to have priority as mentioned above). CS specialists can then be assigned to work on different queues depending on factors such as areas of expertise, how many tickets are in a given queue, or how critical tickets of a particular category/sub-category are usually considered (ie. login issues may be a queue which is considered to be higher priority than a queue for quest-related issues).
• Monitoring should be in place to track all tickets as they go through the entire system using metrics such as number of touch points required to resolve the ticket, length of time to resolve, etc. This, combined with analysis of ticket volumes by category/sub-category and of various pieces of data captured in the ticket submission forms, is how you measure CS team performance, how you determine appropriate staffing levels, how you identify parts of the overall CS process that could be improved, how you identify bugs that should be candidates for immediate attention from developers, how you identify game elements that are confusing for users, etc. Typically this means that all pieces of available data from the automated CS ticket system should feed into a data warehouse in order to enable analysis.
• When a ticket is considered to be resolved (this would typically be based on a specific period of time passing after a CS reply, whether an automated reply or a reply from a human, without any update to the ticket from the user), an automated satisfaction survey should be sent to the user (usually this would be an automated email with a link to the survey). This survey should include questions where the user can answer certain specific questions (often yes/no questions such as “was your issue resolved”), rate satisfaction in different broad categories (ratings should be based on clicking radio buttons or some other system that allows for easy data collection and analysis – categories would usually include things such as how quickly the issue was resolved, the quality of CS responses, etc), and provide free-format feedback.

That’s how you set up a professional automated CS system. Anything less than the above, and your automated system should be considered to be broken, as it acts to prevent good support rather than enabling it. Obviously there’s more that can be done above and beyond what I’ve laid out there (and some of the things mentioned aren’t mandatory, but I’ve called those out as optional where they were mentioned), but that should be considered the minimum that’s acceptable. If those standards aren’t met, then your automated CS system should be considered to be an operational risk, and that risk should be raised with senior management and/or your board of directors.

This is not rocket science, it's a relatively basic IT project that's fairly self-contained. The only places where interfaces with external systems are likely to be required are an interface with the game itself (this can be simply passing information in one direction and is only needed because in-game reporting is one of the ticket submission channels), an interface with the account system (again, this can be one-way, as it's simply consuming data from the account system to ensure that the current login and contact information from the account system is what the ticket system is also using for validating the customer), and an interface with the data warehouse (or whatever other solution is being used - again this can be one-way, as data will simply be loaded from the automated CS system).

I'm still waiting to hear back from the CS manager.

newtinmpls

Was okay for a bit, now acting up again...

thefaeriewench

Two hours now without being able to log in - tried closing/reopening client, client repair, system restart, etc, etc, etc, ad nauseum. It'd be nice to be able to play the game when I actually had time to.

(NE Ohio, Spectrum)

Kiralyn2000

Huh. Must not be a consistent problem, because I was able to log in for two ~1hr sessions this afternoon. No errors, and I saw others questing along. Wonder if there's some root cause (a particular ISP or section of Net, or....?)

(Western PA, Comcast)

static_recharge

still can't log in...

Jemcrystal

still cannot log in

Epona222

I was in using a VPN, but am now locked out again - cannot retrieve announcements, error 200

Xexpo

try this :
https://forums.elderscrollsonline.com/en/discussion/327297/if-you-cant-get-announcement-and-cant-login-this-maybe-the-solution-atm

Robbie529

I was able to get back in a little over 8 hrs. ago. I logged about 1/2 an hour ago & now I can't log back in.

SteveCampsOut

Guess I'll go back to watching movies.....

SBB

8 hours later, still can't log in. F me.

WldKarde

Switched from PTS (working fine) to live to help out a friend AND....

No Can DO

Sorry bud, the great live server on PC NA seems to hate me right now

zept0sec

Unable to login/retrieve announcements for going on 8 hours. Honestly, at what point does not implementing proper network infrastructure like ddos prevention/mitigation or failover become negligence?

Jemcrystal

Sometimes I can log in and sometimes I cannot. Still consider this an issue. It's the weekend zos boost the power.