Behind the scenes at the AO3: A day in the life of a Support staffer

As part of our series giving an insight into what goes on behind the scenes at the Archive of Our Own, Support staffer Sam has written up a day in the life of an AO3 Support staffer! Sam started out volunteering with the AO3 as a tag wrangler, and joined the Support team at the beginning of the July Ticket Blitz. He has degrees in journalism, English literature, and cognitive and discourse linguistics. He’s taught skills-based computer classes for near a decade, so Support was a natural fit. Sam tends to jump on tickets involving CSS code and the skins; downloads, especially ePUBs; and all things Tag, as he’s currently the liaison (read: troublemaker) between Support and Tag Wrangling.

By and large, Support is all about answering all the tickets that come in. To do this involves a whole lot of trying to break the Archive in new and creative ways, keeping a light eye on what the Coders are up to under the hood, and generally trying to divine what the users need and want.

There are a whole bunch of resources we use to do so (some of these resources are only accessible to staffers – we’ve linked the public ones):

  • 16bugs – This is our main ticket tracker where we keep information on each ticket that comes in, and any communication with the user or other committees. This will soon (hopefully) be replaced with the Support Board.
  • Campfire – The chat interface all AO3 committees use. Support has its own room where we’ll request betas and comment on tickets, life, and fic; and we’re often lurking in the Coders room, checking for surprise!bugs and fixes.
  • Both the “Beta” Archive (the real one) and the Test Archive (where we test new code) – Sometimes we have to track down to see what a reported bug is doing and possibly see if it’s already been fixed on the next release.
  • The wiki “Knowledge Base” – One of our Support reps has been collating the answers to commonly answered questions into a massive internal reference source. This is awesome, because it helps ensure that knowledge gets passed on and we don’t have to duplicate work.
  • Google code otwarchive issues – The list of things-to-do for the Coders, to see if a bug is known or a feature planned (and occasionally provide all the information).
  • Squee! – This internal squee page is where we keep all records that we’re doing something right (700+ and counting). It helps us track what’s working and also provides a nice place for people to go when they need a boost!

I pop open my email to see if anyone sent beta requests to the list or if any tickets have come in. (Most responses to users are beta-read by a second support member, for accuracy, clarity, and something resembling UK/US/CA/AU English.) I’ll also log into Campfire and check the Support room, since several staff will leave their beta requests in there.

Both 16bugs and the Support form send an email to each Support staff when a ticket comes in. I tend to not read the emails themselves, but use them as a sign to go check 16bugs and see what new tickets are there.

Certain tickets we immediately assign to another committee (Legal, Abuse, Tag Wranglers) and wait for a response from that committee before contacting the user. Some committees will contact the user directly, some don’t.

Since every ticket is different, I’m going to give examples of two recent tickets. (All confidential details are removed, but hi, users, if you recognize your questions!)


A ticket comes in from a user asking about a problem logging in with hir OpenID. I open the ticket in 16Bugs, and in the ticket set my name for “Assigned to” and “Status” to “Solving”.

I’ve heard some talk about the discontinuance of OpenID, so I poke my head into the Coders chatroom in Campfire and ask if anyone has more specific information. I luck out and one of our Coders knows of two open code tickets regarding OpenID, which saves me the time. I open the tickets in GCode and skim them, seeing the current development status for OpenID (we’re planning to phase it out).

To make sure the code is still working as intended, I use my own account as a guinea pig, setting up my own OpenID login, logging out and testing it. It all works, so I assume that the problem comes from improper configuration. I step back through the process involved and make detailed notes to set up OpenID. I add those to our Knowledge Base on the wiki so next time we have a question like this, the info is easy to find.

I then compose a reply to the user as a comment to the ticket in 16bugs. I also copy in the links to the GCode tickets into 16bugs for reference. After coming up with the response, I poke my head into Support chat in Campfire. Fortunately, one of the other Support staffers is on, so I ask hir to beta my response. Sie reads it over, we discuss and revise a few lines, and sie comments in the thread that it looks good. I copy the response from 16bugs.

In my email, already set to forward through the official email, I search and find the ticket email that came in and reply to it, using the copied text from 16bugs.

After sending the email, in 16bugs I set the status to “Solved”. If the user responds, I can find the ticket in 16Bugs and reopen it as needed. When the user responds that sie doesn’t actually have an account, I send back a betaed response on how to get an invite, either through the queue or through a friend.


Another ticket has come in regarding a tag that’s misfiled – in this case, a fictional football team that has somehow been wrangled into the “Football RPF” fandom. Since this relates to wrangling policy, I’ll mark the ticket to watch it and assign it to the “Tag Wranglers” and wait for a response from one of the Wrangling committee members before I send a response to the user. In this case, it’s an easy fix by the wranglers, and I’m able to quickly notify the user that the tag has been re-wrangled.


There. My two tickets for the day – with the new influx of staff we’ve had, and a fairly slow inflow of tickets lately, sometimes I don’t even get the option to do that many! (However, different times of year or new lots of code can produce a sudden uptick, so we take the rest while we can!)

Sometimes tickets aren’t nearly as straightforward. Sometimes it takes time to track down the bug – while I’m doing so, I’ll set the status to “Testing”. If the response requests additional information from the user, I’ll leave it as “Solving” until I can get a response from the user. If I find other bugs in 16Bugs or code issues in GCode, I’ll leave links in the comment leading to them, as well as leave links to the active ticket elsewhere. If the ticket contains a feature request, I’ll make a note on our wiki’s Feature Requests page and if it continues praise, I make a note on the Squee page.

Let it be said: us Support minions are human. There are tickets that have us staring at our monitors in awe, wondering “how did they do that?” There are tickets where we realize we’ve answered the same thing frequently, and therefore need better documentation and/or to prioritize a bug fix. There are times that we look at a ticket and mentally draw straws about who gets to tell the Coders that the recently-fixed feature isn’t so fixed.

All that said? It’s all worth it. It’s worth it, helping the users better interact with the Archive. It’s worth it, seeing the feature requests and ideas. It’s worth it, feeling like I’m contributing to the development of the Archive. It’s worth it.

I’ve now knocked out a couple tickets, updated a page on the wiki, updated a bug on GCode, and tripped over a work I want to read. Never let it be said I can’t take a sign! Off to read!

Mirrored from an original post on the Archive of Our Own.

Spotlight on Support

When you fill in the AO3 support form and press ‘Send feedback’, your message wends its way to our trusty Support team, who answer questions from users of the Archive of Our Own. They provide help and support on all aspects of using the Archive, and provide a bridge between Archive users and our coders so that bugs get fixed and new features get coded! They are an awesome and dedicated team who love making sure that users have a good experience on the AO3.

What questions do Support answer?

All kinds of things relating to the AO3! If users discover that something is broken, or they want help figuring out how something works, or they’d like to ask for a new feature, all those questions come to Support. Sometimes users will send in broader questions about the OTW as a whole, or about fannish issues in general, and Support will also answer those or pass them on to someone who can (if you have questions that are not AO3-specific, you can also ask those via the OTW Communications webform).

What do Support do when they get a ticket?

The first thing a Support member does when a ticket arrives is to take a look and figure out what kind of question it is. Some kinds of questions are common – for example, we are often asked why they can only view 1000 works in a fandom (answer: to save our servers, but we’re working on a better solution that will make it unnecessary) – and in these cases Support can quickly send out a reply. If it’s not such a common question, the Support member might do a bit of testing to see if they can reproduce a bug, or consult with other teams: for example, they work with Coders and Accessibility, Design and Technology for technical bugs and feature requests, Tag Wrangling for tag questions, Content for issues about what kind of things can be posted on the Archive, and Legal for questions relating to the legality of fanworks.

This sounds like a lot! Do Support members have some kind of special skills?

They have the skill of beng awesome! But other than that, there are not too many specific qualifications for being a Support staffer. Most importantly, Support need to enjoy problem-solving and be able to communicate clearly and effectively. At present, we only do Support in English (this is something we hope to expand as the Archive grows), but you don’t need to be a native English speaker, as long as you are fluent in English – one of our most longstanding and dedicated staffers, Anne-Li, is a native Swedish speaker. Support staffers also need to know the Archive pretty well, although they tend to pick up some of the nitty-gritty as they gain experience. Several Support staffers also serve on other committees, so they can contribute additional knowledge to the team, and thanks to the efforts of staffer Yshyn, Support are also building up an awesome knowledge base on our internal wiki.

What does the future hold for Support?

This is an exciting time for Support – they’ve just taken on some new staff members and are now working and planning for the transition to a Support Board integrated into the Archive. This will be a public-facing board where users as well as staffers can offer advice (along the lines of LJ or DW) – we think this will be great for transparency and for helping more people get involved in a more informal manner. However, it will be quite a radical change, so Support are now beginning work on some of the policies and strategies which will be needed to make that a success.

This all sounds awesome – can I join?!

Support aren’t recruiting right now, as they have just taken on a bunch of new people and are readying themselves for a new model of working. However, the OTW does welcome volunteers across other projects – if you’d like to try tag wrangling or testing, or some other area of the OTW, get in touch with our Volunteers Committee. And of course, when the new Support Board becomes a reality, you’ll be able to contribute more informally. Once we make this switch, there’ll be more Support staffer opportunities in future, so watch this space!