01.09.07
Customer Support Fun with Academic Journals
I’ve been spending most of today catching up on a huge backlog of journal citation alerts and downloading the relevant articles to read before I start writing the “other work” section of my dissertation in the next week or two. So I’ve been noticing a few things about the websites of various journal publishers.
One of the things that I’ve noticed is how different websites handle feedback from their customers—and, in particular, bug reports (and feature requests).
For example, the American Institute of Physics has direct links to an online “submit query” form directly off their help page, and also has a prominently-featured email address—which was quite useful, since I got a server error when I tried to use the online form. We’ll see how quickly they reply (if they do; bug reports don’t really need replies), but in my opinion, that page is pretty much how things should be. It would be nice if they had an explicit mention of “bug reports go here”, but “Technical Support Query Form” is close enough.
Contrast this with the Wiley “Contact Us” page, which I’ve been dealing with for the past fifteen minutes or so. Why have I been dealing with it for fifteen minutes, for what started out as a trivial feature request? Well, first off, at the bottom of the How To Contact Customer Support page (yes, that’s a different page, which you get to by clicking a link on the “Contact Us” page), it says, “We regret that Wiley InterScience Customer Support does not accept queries by email.” That, of course, means that the only option to actually say anything to them is through their web system, regardless of whether or not it happens to be broken.
So, consider the web form. That “Contact Us” page has a couple of links to customer support: one labeled “Online Customer Support” promising FAQs and so forth, and one labeled “Contact Customer Support” and noting that one should use it if “unable to log in”. Despite the appearance of being different things, they both go to the same page, which is a login form, with a place to register an account in the fine print at the bottom. Now, I don’t have a personal account here, since I’m using a university site license for the content, so it looks like they’re asking me to go through the whole process of creating an account on the site just to file a simple bug report.
Eventually I noticed, down at the fine print on the bottom of that page, the link for “if you don’t want to register, click here”. Good. No, I don’t want to register; I want to file a bug report and be done with that.
That gets me to the main customer service web page, which then has a link to “Ask A Question”. It does not have a link to “File a Bug Report”, or to “Make a Feature Request”, or to anything at all which would be an appropriate phrasing for any problem that would require them to do anything whatsoever about it, but that sort of implicit assumption that it’s the customer’s problem seems to be the style these days, so I dutifully clicked on the “Ask A Question” link, and got presented with a web form.
This web form has a fair bit of clever Javascript to make my life “easier”, so that depending on which options I click for my problem, different subcategory boxes appear. Once I’ve got them all filled in, a box pops up for me to select my regional location and enter my institution. (Apparently it’s a barter system; I have to trade demographic information to them before they’ll answer my “question”.) Except that this doesn’t actually work in the version of Opera that I use, so the “Location” box never appears, which means that the “Error: You didn’t enter a location” message that I got when I tried to submit the form was really quite cryptic. And rather hard to work around, too, until I decoded it to “Error: We don’t support your browser,” and tried Mozilla, in which the Javascript works a little better.
Once I entered the question and clicked submit, I still wasn’t done. First, there was the little matter that since I hadn’t registered before, they wanted me to do so now, and were presenting me with the registration form to fill out. I gave in and gave them a password to associate with my email address and the other information they wanted, and again clicked submit.
And, again, I still wasn’t done, because that gave me a page along the lines of “We’ve selected five answers from our FAQ that our pigeons think may have something to do with your question. Do any of them answer it? If not, please scroll down a screen and click the ‘No, these don’t answer my question’ link at the bottom of the page.” Of course the FAQ answers don’t answer my question; it’s a bug report, and it needs someone on your end to do something about it. (This is why I am annoyed with customer service websites that phrase things as “ask a question” rather than “contact customer support”; it seems that it’s a short jump from there to setting up the whole process as if the only things the site has to deal with are questions.)
At this point, it finally accepted the question, gave me a tracking number, and told me that I should expect a reply in 24 hours. We shall see.
So, let’s recap on why this matters (beyond the obvious bug report). A good-sized chunk of my dissertation is going to get reworked into a journal paper or two, and both AIP and Wiley publish journals that would be good places to submit it. One publisher’s customer-service site is a clear, simple, single-page website with a no-javascript online form and a prominently-placed email address. The other publisher’s customer service site comes with its own 650kb(!) user manual in PDF form and makes it a 15-minute complicated web maze to file a trivial bug report. So, whose paper-submission process would I be likely to want to deal with?
Edited to add: I got an emailed reply to all three messages to Wiley, within four hours of submitting the questions. It was polite and clearly from a human being, and made it clear that my initial feature request was noted and relates to things they are currently working on. It was slightly off-putting that the response to my bug report about the web form was essentially “We’ve tested this on all current browser versions, and recommend upgrading your browser” (rather than something like “Sorry about that; I’ll let our web team know, though it may be low-priority for them since it’s not an up-to-date browser”), but other than that, the message was responsive and prompt, and seemed to involve at least as much thought and consideration as I’d put into the messages I’d sent. There’s more to customer service than just the website!